XML Mapfiles... are we looking to far?
Tom.Kralidis at EC.GC.CA
Wed Jul 19 13:44:51 EDT 2006
Good points. As well, we should also consider speed of processing by comparing a mapfile Flex-ish parse to a mapfile XML-ish parse. I've roughly (roughly) seen a 3:1 ratio in my days on parsing XML vs. plain text.
And we'll need to have a validating parser for sure, i.e. not just scanning the instance document.
From: UMN MapServer Developers List [mailto:MAPSERVER-DEV at LISTS.UMN.EDU] On Behalf Of Ned Harding
Sent: Wednesday, July 19, 2006 1:16 PM
To: MAPSERVER-DEV at LISTS.UMN.EDU
Subject: Re: [UMN_MAPSERVER-DEV] XML Mapfiles... are we looking to far?
Just to throw my 2 cents into this debate: although I would prefer an XML interface over the existing interface, I worry that if there are 2 different interfaces that they will quickly get out of sync, make development of new features more difficult and generally cause more bugs than they solve.
From: UMN MapServer Developers List [mailto:MAPSERVER-DEV at LISTS.UMN.EDU] On Behalf Of Julien, Heryk
Sent: Tuesday, July 18, 2006 7:45 AM
To: MAPSERVER-DEV at LISTS.UMN.EDU
Subject: [UMN_MAPSERVER-DEV] XML Mapfiles... are we looking to far?
I think there are many advantages in using xml. First, XML files are easy to create and schema validation can check document structure while you are writing it. Schema aware editors can also give you hints and do automatic inputs of required tags while writing mapfile document. Yes Mapserver validates mapfiles, but I think the addition of a mapfile structure validator like xsd would facilitate mapfile creation and debugging.
Schemas can help newbie's to create there first config files and advanced users and developers visualise, communicate and work on the current mapfile format. I also think that it would be easier to extend the mapfile structure in future Mapserver versions if we where using an xml format... for example adding new OGC tags to mapfiles would be very easy.
Plus with all the new xml editing tools out there, schema creation, visualisation and validation has become a child's play (hmmm.... well almost!).
Just as you said earlier, automating map config creation would be another great benefit. And if Mapserver could read non static mapfiles (via URL's), xml would be a great way to create dynamically generated mapfiles. If we consider mapfiles as being a kind of database (or database pointer), wouldn't it be great to be able to easily process it on the fly? XML coupled with xsl, xpath and databases would be one great way to do that kind of manipulation. A little like OGC WMC layers that are pointing to different data layers (wms layers), we could have dynamically generated mapfiles instead of one huge static file containing all data layers.
Xml being rapidly more and more widespread, ways for developers to input serialization data into Mapserver would be much greater and flexible. Mapfile management would be more open and greatly enhanced with the use of xml. For example a url fetched xml mapfile would enable us to easily modify a mapfile service according to certain parameter like language. We could thus have an automated multilingual mapfile. Currently we have to save a static mapfile for every language. They all point to the same data but containing language specific titles and metadata.
Being an OGC fan, I think there decision to use xml to disseminate data and ease interop has been a good choice. In that same line of thought, I think an xml mapfiles format to serialize Mapserver would be a logical next step.
Natural Resources Canada
490 rue de la Couronne
More information about the mapserver-dev