[mapserver-users] XML mapfile?

[imap at chesapeake.net]

yah.. *please* dont break the native mapfile format... 
upgrades are painful enough without completely overhauling
the mapfile to a new format.  Some backward compatibilty
would be apprecitated.

Regards,

Chris Stuber (mapsurfer)
Silicon Mapping Solutions, Inc.

Steve Lime wrote:
> 
> Ok, you're a whiner. <g>
> 
> This is being looked into. There are other competing priorities at the
> moment so it's down
> the list a bit right now. My plan would be to support both native and
> XML-based configuration
> in the short term until some of the performance issues could be dealt
> with. One could actually
> make MapServer read XML with just a few tweaks of the lexer, and since
> you wouldn't validate
> at that point anyway...
> 
> I'd like to see the conversation continue, perhaps off list with a
> smaller group. Some practical
> demonstrations of the benefits of an XML-based config file might also
> help those of us not
> experienced with XML see the light.
> 
> Steve
> 
> Stephen Lime
> Data & Applications Manager
> 
> Minnesota DNR
> 500 Lafayette Road
> St. Paul, MN 55155
> 651-297-2937
> 
> >>> "C F" <gis_consultant at hotmail.com> 05/22/02 10:51AM >>>
> I hear you on the performance concerns.  However, I think we could get
> 
> around that by serializing the XML DOM object into a file (that's how
> ArcIMS
> does it.... which probably hurts my case more than anything).  Then the
> only
> time the XML file would be parsed is in the first request after a
> change to
> it is made (done by using file's timestamps).  Who knows, it might even
> be
> fast than the current implementation.  I don't really know if that's
> true as
> I have not actually used serialized DOM files in my own apps... but it
> makes
> sense to me that it could possibly alleviate your performance
> concerns.
> Now, assuming that performance wasn't an issue, I still hear concerns
> about
> simplicity.  In raw text-edit mode, there's nothing that can be done
> about
> that.  I consider it a very minor difference... but that's just a
> matter of
> taste and there will never be a consensus on that.  All I can say about
> that
> is that XML would make it tremendously easier for people to write
> mapfile
> generation/editing tools.... also for people writing tools to batch
> update
> their mapfiles, etc.  In other words, with maybe the very minor
> exception of
> manual text editing, it would make them much easier to handle.... again
> a
> maybe matter of taste :)
> MapScript is a solution... but may not be a solution for everyone if
> they
> want to build a more of a single, cross-platform solution with minimum
> 
> modification and customization to the servers involved.  Also, the fact
> that
> we'd gain access to this important mapfile information without the need
> for
> "programming" would be nice.  I envision this would be set up in much
> the
> same way it is now, only with XSLT templates replacing the current form
> of
> templates.
> 
> Well those are my thoughts.... but I haven't really received any
> positive
> feedback since my original post so it looks I'm all alone :)  People
> seem to
> be comfortable with the current format.  Or maybe I'm just looking at
> it for
> use in different uses than it has traditionally been used for.  I think
> 
> everybody that's worked on it has done an *awesome* job.  I think the
> product is great, just call me a whiner if you'd like :)  Paul Ramsey's
> idea
> of out we could have it both ways is something I might do for myself
> anyway.
>   If there is ever enough interest in it maybe that's somewhere I can
> contribute to the project.
> 
> >From: Daniel Morissette <morissette at dmsolutions.ca>
> >To: C F <gis_consultant at hotmail.com>
> >CC: mapserver-users at lists.gis.umn.edu
> >Subject: Re: [mapserver-users] XML mapfile?
> >Date: Wed, 22 May 2002 08:19:31 -0400
> >
> >I think that Steve has been considering a switch to XML eventually,
> but
> >I don't think there is any formal plan.
> >
> >I agree that XML might give more flexibility to the user by allowing
> him
> >to read the mapfile from external tools, but it would be at the cost
> of
> >performance (i.e. speed) when parsing the mapfile for every request.
> >Combine this loss of performance with the fact that XML would be
> harder
> >to edit manually than the current format, and you know where I stand
> >personally.
> >
> >I'm not saying that if we were redesigning from scratch I wouldn't
> >consider XML (we use it a lot in other apps), but since we've already
> >got a very good (fast and simple) mapfile format then I won't be the
> one
> >initiating a switch to XML mapfiles.
> >
> >Note that MapScript already gives you access to almost every piece of
> >information from the mapfile, so when the CGI cannot do what you need
> >then the logic path is to switch to MapScript, and then sky is the
> >limit.
> >
> >My 0.02$
> >--
> >------------------------------------------------------------
> >  Daniel Morissette               morissette at dmsolutions.ca
> >  DM Solutions Group              http://www.dmsolutions.ca/
> >------------------------------------------------------------
> >   Don't put for tomorrow what you can do today, because if
> >       you enjoy it today you can do it again tomorrow.
> 
> _________________________________________________________________
> MSN Photos is the easiest way to share and print your photos:
> http://photos.msn.com/support/worldwide.aspx