MapserverXML?

[Bill Binko]

On Fri, 16 Dec 2005, Lester Caine wrote:

> Larry Shaffer wrote:
> 
> > This is a continuation of the 'Foundation and Mapserver MAP file manag e
> > tool' thread ...
> > 
> > Being a new guy to Mapserver, but not XML, I was somewhat shocked that
> > such a Web-centric application didn't have an XML format for its base (or
> > transfer) document by now - so excuse me if this has been ranted about
> > before. But, at the risk of opening a can of whoop-ass on myself...
> 
> Which came first ;)
> Changing every working system *TO* XML is never going to happen and I 
> can give you a few examples of where attempts to 'enforce' it's use just 
> aren't happening.
> That is not to say that it should not be available, but to be honest I 
> just don't see much advantage in taking the effort to 'built it in'. A 
> MAP file is nice and 'concise', the XML equivalent will always be 
> somewhat larger and the information contained no different.

I have thought about this since my first experiment with adding something 
to Mapserver (ColorRamps/Gradients).  I believe a switch to XML would 
provide two very separate benefits, neither one of which is significant 
enough to stand on its own.  

The first is what Lester was discussing: there are tools (XMLSpy, etc)  
that can effectively edit XML while enforcing a schema.  Even those who
edit directly could validate the files before trying to run them, and 
separate a "I screwed up my Mapfile" problem from a "I screwed up my data" 
problem.  With a modern XML parser, some of the old lingering Mapfile 
problems go away (Quoting, Including other Files, Defining Constants, 
etc.)  

This is all very good and can be accomplished "on top of" the Mapfile 
format (as suggested).  However, if it does remain "on top" as a 
pre-processor of some sort, it will be a nightmare to maintain with each 
change to the Mapfile format.

The second major benefit involves the code itself.  The fact is that its
already a nightmare to add new features to the Mapfile format.  When I 
added the ColorRamp support, I needed to edit the lexer, the parser, the 
"mapfile.c" logic, the data structures, and THEN I could add the 12 lines 
needed to add the feature I wanted.  And with all of that, Sean G had to 
cover my ass and fix the save/restore code that I had broken (I had no 
idea it was there).

If an XML format was used, and we chose to use the DOM approach (we might 
not), this would be a schema change, and adding the feature.  All of the 
things I mentioned above would be handled by the parser.  If we got 
ambitious, most of the Mapscript interfaces (all the ones regarding 
manipulating the Mapfile structure) could be relegated to the XML 
interface of our target language.

The problem with this, of course, is that it is not backwards compatible, 
it is a major code refactoring, and by itself, it doesn't provide enough 
benefit to justify the cost.

Now, personally, I think that the two benefits together are worth doing, 
but then, I'm not the one that's going to be hurt: my projects are recent, 
and I have under a dozen Mapfiles that I really care about.

However, if someone wants to spearhead this, I would be happy to help.

Bill