We started to upgrade all our old mapfiles to the new 5.2 standard because
first its about time and now that we are starting to do a non-trivial amount of
Mapserver consulting, we felt it important to keep informed.
In doing so we started to develop a cheat sheet to help guide us on what's possible in Mapserver Mapfile 5.2.
The cheat sheet can be found here -- keep in mind its still a work in progress so
please refrain from laughing. In the middle of making this -- all the mapserver document links changed. I guess Mapserver documentors were busy too. I must say the new documenation
is much better than the old. It has some nice examples all nicely color coded. So I want to thank Steve Lime, Jeff Mckenna, Jean-François Doyon and the others in Mapserver doc group for a job well done.
In mapping this cheat sheet out, the first thing slapping me on the side of the head is
Mapserver really needs an XML defined schema. Yes I know I sound like a hypocrite and
one who has been smoking XSLT a tad too long for my own good. Yes I was on the side of the
group of people who thought What is it with these XML idiot lovers. What is to love in such a monstrously verbose
unforgiving format? Mapfile format is wonderful, easy to
read, fast to parse, and write THANK YOU very much.
Now it appears I am switching camps. Wait a minute though - the truth is
I could care less if the Mapserver engine can understand XML. I just want to write my map file in XML and
am happy to XSLT it to a format Mapserver can deal with. Why? Do I think XML is a beautiful language?
On the contrary -- I find the format stinks and I think it is inefficient in many use-cases. It is in fact the most abused language if there ever was one.
Our main frustration with XML is that in our line of work we do a lot of data loading, data scrubbing and so forth, and
we are usually on the side of the fence where some goof-ball gives you some blob
of XML with weird characters and other junk and just stuffs it in a CDATA tag and thinks that will solve all issues or
where some guy just took OO UML 101 and he has spent a great deal of time over-thinking his data model when time would have been better
spent getting loaded at the nearest bar. He has this wonderfully elaborate 30-level portable XML data file for his simple list of jobs complete with 200-pages describing every facet of it
for you to digest.
XML is bulky, unforgiving, and easily abused so why is it useful? The beauty of XML and XML XSDs is that a lot of software and development tools
support them.
- If I had an XSD for mapserver, my editor would immediately tell me what values are valid for each type that takes a fixed number of constants
- My editor would immediately tell me when I am stuffing something in a layer that is not valid
- I can XSLT my way to a standard mapserver file or god forbid some sort of tree thingy with links to documentation of that element. How many times
have you looked at the mapserver documentation and thought? Can I stuff this object in a layer group? Have no clue - the documentation doesn't really tell me that unless the
writer happened to remember and even then there is way too much reading involved for my 5-minute attention span to deal with.
- Nowadays XSLT joins the group of SQL as an embeddable language. Can you think of a modern language that can't deal with XML/XSLT? In PHP/.NET which
we program in predominately, both have XSLT classes that can take any xsl file and xml file and transform. My code editor has a built-in XSL processor.
- Mapserver mapfile format just lends itself to that - think nested groups, groups that can go in some groups but not others or can have at most x number of item z in it. Mapserver is far from a simple structure with simple rules, so demands
something designed for that kind of thing.
- I tend to think it would help the documentation effort immensely too, because right now as the documentation stands, there is not enough
cross-referencing going on or an easy way to visualize the natural flow of the map file. An XSLT of an XSD would solve that problem nicely I think.
Take for example LABEL. Do you have any clue what elements a label can be stuffed in
if you were just starting out?
So to me -- or at least with my understanding of things XML -> MapFile -- fairly trivial, XSD fairly trivial but torturous exercise,
MapFile --> XML not so trivial but less torturous exercise. I'm perfectly content with an XML -> MapFile route
and am actually thinking about creating such a thing for 5.2 if someone hasn't done it already, if only I could ever find the time,
but if things keep going as they are, I may just have to do that if nothing but to keep my sanity.
