mapserver and XML status?

[Kralidis,Tom [Burlington]]

> -----Original Message-----
> From: UMN MapServer Developers List 
> [mailto:MAPSERVER-DEV at LISTS.UMN.EDU] On Behalf Of Steve Lime
> Sent: Wednesday, 17 November, 2004 19:12
> To: MAPSERVER-DEV at LISTS.UMN.EDU
> Subject: Re: [UMN_MAPSERVER-DEV] mapserver and XML status?
> 
> 
> Hi Terry: I have been meaning to reply, just kept slipping my mind.
> 
> I don't think more dependencies nor the C++ agurment are 
> major impediments. I think the most often used argument for 
> not doing pure XML mapfiles is that what we have now works 
> well so why bother. That and it would be a large (unfunded) 
> undertaking to switch.
>

I agree with Steve here in terms of something that works so well.  In my
testing, I've always found a ~3:1 ratio of writing a generic parser
against an XML document vs. a plan text type file.  So there's obvious
overhead.

The one place where I would see XML being great is for management of
mapfiles as XML, i.e. the ability to easily insert/update/delete objects
as XML chunks.  Mind you, mapscript's object model probably does this in
a similar fashion.
 
> So, in truth there is nothing happening with XML and 
> mapfiles. It keeps being bantered about from time-to-time, 
> but never goes anywhere. Eventually it will but when is 
> anyone's guess. That said, your idea sounds like a neat one 
> and one that I would welcome. There are immediate benefits 
> and if a schema were kept up-to-date, long term as well.
> 
> (I started the DTD as a documentation tool out of curiosity 
> way back and you're right, it's way out of date and should 
> probably be removed from the distribution.)
> 
> Steve
> 
> >>> Terry Brown <tbrown at NRRI.UMN.EDU> 11/12/2004 10:51:14 AM >>>
> What the status of mapserver vis-a-vis XML technologies?
> 
> Particularly for the mapfile end of things - I see the 
> mapfile.dtd in the source tree, but that seems incomplete.
> 
> I saw some comment about not wanting to introduce XML-Schemas 
> because the only open source tools to handle them require C++ 
> (or Java), and you don't want to add more dependencies to mapserver.
> 
> But it seems to me that XML components could be developed 
> along side mapserver without making mapserver dependent on 
> them - e.g. a schema for writing map files in XML with an 
> XSLT translation to the current ascii mapfile format in the 
> mean time, so those who wanted could use it.  I know it's 
> difficult once you let XML get its toe in the door, where to 
> draw the line, do you fold a lot of documentation into the 
> schema, etc. etc.
> 
> Does this sound like something that might be useful?  I'd be 
> up for writing a draft XML-Schema with an automatic 
> translation to a DTD as a starting point.
>

There must be a way to translate the object model to XML Schema (or
anything really) without doing things by hand.  Mind you, if we had the
mapfile object model as UML, we could (literally) convert to XML Schema,
Java, C++, etc. with tools.
 
> Out of curiosity and strictly as an aside, do the cross 
> server interchange protocols (WMS?) use web services / SOAP 
> type technologies at all?
> 

As of now, OGC:WMS doesn't use SOAP.  It's pure HTTP GET or POST for the
moment.  I know that OGC has had some experimentation with using
WSDL/SOAP.

For me (I'm a REST type of guy), even if one uses SOAP, you still have
to decode SOAP-ENV:Body, which is just like parsing anything out of
OGC:WMS currently.  The SOAP-ENV:Envelope is certainly useful for
transporting, but still.  WSDL would be useful, as it defines input and
output content models, so one can really bind on the fly.

..Tom


> Cheers -Terry
> 
> --------------------------------------------------------------
> ---------
> Terry Brown               Natural Resources Research Institute
> Research Associate        5013 Miller Trunk Highway
> tbrown at nrri.umn.edu       University of Minnesota, Duluth
> Ph. 218 720 4345          Duluth, Minnesota 55811
> Fax 218 720 4328          http://beaver.nrri.umn.edu/~tbrown/
>