MapServer and XML...

[Doug Nebert]

Stephen Lime wrote:

> Pretty straight forward I'd say. How does one make the decision between
> making a a parameter a new tag or just having it as an attribute of another
> tag? For example:
> 
>   <layer><name>water</name>  vs   <layer name="water">
> 

Some of it is justa  matter of style. I like to put things as properties 
on a line when they are almost always present, just to shorten the 
length of the file. I like the idea of knowing which named Layer block I 
am in expressly, rather than parsing it, though the other form of using 
only straight tags works well enough, too.





> Once a DTD is in place a conversion script should be a piece of cake.
> 

There are DTD generators that can use example XML markup to build the 
interpreted rules and values. I will look for one and pass the demo.xml 
through it. You will need to expland this to include all the various 
possibilities of terms within a given group, and other possible groups 
that may exist but were not expressed in the demo.map file. You can edit 
the DTD by hand to include these.





> Steve
> 
> Stephen Lime
> Internet Applications Analyst
> 
> Minnesota DNR
> 500 Lafayette Road
> St. Paul, MN 55155
> 651-297-2937
> 
> >>> Doug Nebert <ddnebert at usgs.gov> 05/16/00 08:24AM >>>
> imap at chesapeake.net wrote:
> 
> > 
> > Doug, Can you provide a URL reference to the OpenGIS XML topics?
> > I looked thru the list, but no mention of XML on the index page.
> > 
> 
> The Web Mapping Service specifies each server's "capabilities" using a 
> hierarchical markup in XML for the server and a repeating section for 
> each "layer" which is analogous to named layers in mapserv. This 
> capabilities.xml file can be placed at a WMS server site for harvest 
> into a services registry (so we know what map servers exist) or for 
> interrogation by middleware or a smart client to offer layer choices to 
> a user. See the WMS Get Capabilities interface specification.
> 
> Also, any day now, the Geography Markup Language (as Recommended Paper) 
> will be available for public review. It is not a specification, and 
> despite the apparent similarity to a W3C "Recommendation", this is only 
> a first step towards a future spec. GML has several flavors of 
> implementation, but essentially encapsulates mapped Features, their 0- 
> 1, and 2-D geometries, and attributes using XML markup. It is intended 
> for use where a client wishes to cache objects for display and query 
> without re-visiting the server and could be viewed as a type of export 
> format for extracted or full vector data. The next phase of Web Mapping 
> Testbed will take GML further towards a specification, but soon the 
> recommended paper will be available for you to experiment with.
> 
> 
> 
> 
> 
> > Moving to an XML config is probably the way to go, but guaranteed to
> > break the existing applications that use the old mapfiles.  That
> > would be painful to change all those mapfiles I have all over the place.
> > Maybe a mapfile->XML conversion tool would be the ticket... or some way
> > to accomodate either configuratoin as a stop-gap measure.
> > 
> 
> Supporting either might be a good idea.
> 
> 
> 
> 
> 
> > I dont know for sure, but I suspect that XML is versatile enought to support
> > all of the baggage we carry in the mapfile.  Maybe we can come up with some
> > concrete examples of how this might look?   What this boils down to, is nested
> > map objects (and the objects which make up a map) and if XML can support that,
> > it would make perfect sense to persue that goal.
> > 
> 
> XML most certainly stores hierarchies of information (think outline) 
> with repeated groups, most elements having a starting and ending tag. 
> The creation of a "rule" document, called a DTD, would help enforce or 
> validate the map file. One quirky thing, but some parsers are very case 
> sensitive, so the case of the tags you declare matters... See attached 
> example of the demo map file manually converted to XML. Don't 
> necessarily trust my assignments, but by defining these rules of 
> encapsulation it will make the composition and testing of map file 
> contents better.
> 
> Doug.
> 
> 
> 
> 
> 
> > Regards,
> > 
> > Chris Stuber (mapsurfer)
> > Silicon Mapping Solutions, Inc
> > 410.257.3187
> > 
> > 
> > 
> > Stephen Lime wrote:
> > > 
> > > Greetings all. I'd like to start a discussion concerning the relative merits of moving
> > > MapServer configuration files from the ad hoc formats they currently exist in to XML.
> > > Lot's of good reasons to do this, validation being one. Just thinking out loud and
> > > looking towards version 4.0. Comments appreciated.
> > > 
> > > Steve
> > > 
> > > Stephen Lime
> > > Internet Applications Analyst
> > > 
> > > Minnesota DNR
> > > 500 Lafayette Road
> > > St. Paul, MN 55155
> > > 651-297-2937
> > 
> > 
> > 
> 
> 
> 
> --
> Douglas D. Nebert
> Clearinghouse Coordinator
> FGDC Secretariat	Phone: +1 703 648 4151	Fax: +1 703 648-5755	
> Pager Messaging: 	http://clearinghouse3.fgdc.gov/dougmsg.html 
> 
> 
> 
> 



--
Douglas D. Nebert
Clearinghouse Coordinator
FGDC Secretariat	Phone: +1 703 648 4151	Fax: +1 703 648-5755	
Pager Messaging: 	http://clearinghouse3.fgdc.gov/dougmsg.html