XML Mapfiles... are we looking to far?

[Sean Gillies]

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.

cheers,
Sean

On Jul 19, 2006, at 10:40 AM, Tamas Szekeres wrote:

> Hi,
>
> 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.
>
>
> Tamas
>
>
>
> 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=
>  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 mapfi=
> le
>> format. I also think that it would be easier to extend the mapfile  
>> struct=
> ure
>> in future Mapserver versions if we where using an xml format...  
>> for examp=
> le
>> 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 coup=
> led
>> 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 o=
> f
>> xml. For example a url fetched xml mapfile would enable us to  
>> easily modi=
> fy
>> 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 a=
> nd
>> ease interop has been a good choice. In that same line of thought,  
>> I thin=
> k
>> an xml mapfiles format to serialize Mapserver would be a logical  
>> next ste=
> p.
>>
>>
>>
>> Cheers
>>
>> H=E9ryk
>>
>>
>>
>>
>>
>> _____________________________
>>
>> H=E9ryk Julien
>>
>> Research Officer
>>
>> Natural Resources Canada
>>
>> 490 rue de la Couronne
>>
>> Qu=E9bec, Canada
>>
>>

---
Sean Gillies
http://zcologia.com