XML Mapfiles... are we looking to far?
sgillies at FRII.COM
Wed Jul 19 13:06:42 EDT 2006
Keep this in mind: every time someone creates a new XML language, God
kills a kitten.
Yes, I used to advocate a bit for an XML config, but anymore I think
that somebody ought to just write some XSL that converts web map
context + OGR virtual files to a mapfile.
On Jul 19, 2006, at 10:40 AM, Tamas Szekeres wrote:
> There is no doubt about the usability and the wide audience of the
> XML/XSL technology in general. However in the mapserver's perspective
> it's just another format to persist the map configuration. At the
> developer's perspective another parser and writer is to be
> implemented. The parsed xml document object is to be immediately
> translated into the mapserver structures that can be handled
> regularly. If one would extend the schema at least the internal
> structures and conversion method should be modifyed accordingly, not
> easier than with the current implementation.
> At the user's perspective if the configuration is generated
> automatically using xml and xsl configuration templates creating xml
> or text base output seems to be equivalent in complexity.
> If the user creates the configuration by hand using xml is slightly
> more benefical due to the high number of the tools for editing the xml
> files. However in the mapserver's case making sure the file is
> syntactically correct is not too much. One would like to see the
> generated map immediately using a WYSWYG tool, so mapserver will come
> into the picture and ensures the validation of that file by the way.
> However in my opinion it would be benefical to provide support for
> multiple configuration formats in a provider based fashion controlled
> by compilation switches. It would be crucial to retain the
> compatibility with the existing map file format, and the user could
> decide to include a provider and all of the dependent libraries on
> demand. This approach could support the conversation between theese
> formats easily.
> Besides the file based configurations we should also consider to
> support other location types to read and write the configuration data.
> 2006/7/18, Julien, Heryk <hjulien at nrcan.gc.ca>:
>> Hi Tamas,
>> I think there are many advantages in using xml. First, XML files
>> are easy=
>> create and schema validation can check document structure while
>> you are
>> writing it. Schema aware editors can also give you hints and do
>> 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
>> users and developers visualise, communicate and work on the
>> current mapfi=
>> format. I also think that it would be easier to extend the mapfile
>> in future Mapserver versions if we where using an xml format...
>> for examp=
>> 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
>> Just as you said earlier, automating map config creation would be
>> 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 coup=
>> 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
>> data layers (wms layers), we could have dynamically generated
>> instead of one huge static file containing all data layers.
>> Xml being rapidly more and more widespread, ways for developers to
>> serialization data into Mapserver would be much greater and flexible.
>> Mapfile management would be more open and greatly enhanced with
>> the use o=
>> xml. For example a url fetched xml mapfile would enable us to
>> easily modi=
>> a mapfile service according to certain parameter like language. We
>> thus have an automated multilingual mapfile. Currently we have to
>> save a
>> static mapfile for every language. They all point to the same data
>> containing language specific titles and metadata.
>> Being an OGC fan, I think there decision to use xml to disseminate
>> data a=
>> ease interop has been a good choice. In that same line of thought,
>> I thin=
>> an xml mapfiles format to serialize Mapserver would be a logical
>> next ste=
>> H=E9ryk Julien
>> Research Officer
>> Natural Resources Canada
>> 490 rue de la Couronne
>> Qu=E9bec, Canada
More information about the mapserver-dev