XML Mapfiles... are we looking to far?

[Kralidis,Tom [Burlington]]

WMC can handle a lot of the layer block info, but there are bits of the
mapfile which aren't covered (imagetype, imagecolor, reference, legend,
etc.).

Maybe a new mapfile schema can incorporate already defined bits and put
MapServer-specific stuff into it's own namespace.  Before we go out and
define yet another language
(http://www.tbray.org/ongoing/When/200x/2006/01/08/No-New-XML-Languages)
, we should see what's out there already and come up with a skeleton.
Right away I can see OGC:WMC or the forthcoming OGC:OWSContext, as well
as the OWS Common schemas, as  building blocks.

..Tom


> -----Original Message-----
> From: UMN MapServer Developers List 
> [mailto:MAPSERVER-DEV at LISTS.UMN.EDU] On Behalf Of Sean Gillies
> Sent: Wednesday, July 19, 2006 1:07 PM
> To: MAPSERVER-DEV at LISTS.UMN.EDU
> Subject: Re: [UMN_MAPSERVER-DEV] XML Mapfiles... are we 
> looking to far?
> 
> 
> 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
>