[mapserver-users] XML mapfile?

Wed May 22 10:37:44 PDT 2002

All,

I think the group should think about an XML conversion a bit.  Functionality
and efficiency are important to consider before chasing down the latest XML
technologies.  If creating a mapfile becomes more difficult as a result of
XML, this may deter some.

..Tom

> -----Original Message-----
> From: Mike Haarman [mailto:mhaarma at socsci.umn.edu]
> Sent: Wednesday, May 22, 2002 12:49 PM
> To: C F
> Cc: mapserver-users at lists.gis.umn.edu
> Subject: Re: [mapserver-users] XML mapfile?
> 
> 
> 
> CF,
> 
> You are not alone.  I've had similar discussions off-list 
> with Steve and
> Daniel.  There is no consensus yet, but developments at OGC point in
> this direction also.  This is neither here nor there, but I 
> would like to
> address the two concerns raised here.
> 
> Performance.  I really feel this is a non-starter.  Your 
> solution is one
> method and there are others for optimization of XML parsing.  Its not
> trivial work, but it is perfectly feasible.
> 
> Editing.  XML is self-documenting, human-readable, plain-text 
> as we all
> know.  Where is the difficulty?
> 
> Your points about generation and transformation are right on,
> particularly in light of the opportunities for integration with other
> publishing or content delivery environments.
> 
> Mike
> 
> On Wed, 22 May 2002, C F wrote:
> 
> > 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
> >
> >
> 
> ----------------------------------------------------------------
> Mike Haarman                        Minnesota Population Center,
> mhaarma at socsci.umn.edu              University of Minnesota,
>                                     537 Heller Hall,
>                                     Minneapolis, MN 55455
> Co-Architect, Programmer,
>   National Historical GIS -- http://www.nhgis.org/
> Maintainer,
>   DDI Codebook DTD -- http://www.icpsr.umich.edu/DDI/
> 