[mapserver-users] mapserver-dev list? (was: XML mapfile?)

23 May 2002 20:44:46 -0500

--=-SAfMYLq49bW67nxp2C+H
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

"Former" Lurker Here Again,

You know, I've thought a lot about an 'XML-ified' version of Mapserver,
and I've concluded that its a darn good idea to make it work that way
(see my previous long-winded post to the list).  I have also concluded
that we can't efficiently do it purely in parallel with the existing
mapfile format.  To be really useful, the efforts will eventually need a
lot of coordination.  I think it might work to have the existing file
format be the input for a program (mapserv) that internally uses code
objects that may also be manufactured with XML files.  Sort of a special
case of Steve Lime's "Option 2".  Here goes...

In my dreams, I envision a way that the mapserver handles the march of
revisions elegantly, in a manner similar to the way web browsers handle
HTML. OK, maybe even better than web browsers handle HTML <wink>. A
proper set of mapserver-related object classes would be terrific, and
code that traverses DOM trees is an easy way to handle all this stuff. 
Furthermore, don't stop with web pages -- it is probably just as easy to
implement and document classes (I prefer python or C++) that are
populated by XML files and may be used for all sorts of things. For me,
this is the real power of the XML mapfile strategy, and it seems to me
that a natural way to make progress is to leverage the mapscript
library.

May I propose wrapper classes that manufacture mapscript objects from
XML?  I think python would be a dynamite way to start, since it does
pretty darn good OO, it's easy to learn, it has nice XML processing
tools, it's very productive to code in, and mapscript/python exists. 
The wrapper would read an XML file ("MapservML"?), and traverse the DOM
tree, using mapscript methods to populate the internal data structures,
do rendering/queries, etc.  The constructor would then return an object
that could be used for lots of other things, e.g., adding layers made
from local data, rendering to a bitmap/ps/pdf/vrml and then allowing
mark-up with "draw line", "draw circle", "draw arrow", "draw text", and
so forth, even allowing drawing in world coordinates!  Also (in python
for example), we could readily make COM/DCOM objects on Windows, so you
could plug the objects into VB/VBA/Office (or make CORBA components). 
It's a functional step toward the ESRI GIS Objects stuff, but it's open
and cross-platform.  Can mapscript make GML or is that a mapserv
function?

For performance reasons, the wrapper might eventually be written in C or
C++ and linked to python/php/perl/[I can't resist saying Scheme for some
reason] for application development. I'd propose prototyping in python
and converting to C modules later to satisfy performance needs and link
to all those other languages that I don't use <grin>.

Here's the potentially controversial part, and I apologize in advance
for being so presumptuous.  Over time, the mapscript library would
become the base implementation for all the programmatic rendering
innards of mapserver and mapserv would simply be a CGI front-end which
reads the current format and has mapscript objects and an HTML template
generator built into the back-end (incidentally, you could make an
"xml-mapserv" by using an XML file instead of the current format in a
jiffy!).  I suspect it would require decoupling the QUERY stuff from the
LAYER objects (or else put some programmatic glue in mapserv), since the
query template, etc. has no real meaning in a non-mapserv context.  I
apologize because I haven't looked closely at the code -- is it already
done this way?  

To my uneducated eye, it looks like a "reasonably" short trip
(especially if I don't have to write it, HOHO!) from the current
mapserver and mapscript to a set of components that could do so much
more than web sites...  However, it is only realistic to do so if the
effort can eventually be coordinated with mapserver development. 
Eventually it could mean making mapscript expose all the necessary
features of mapserv, and new rendering features, etc. would need to be
in mapscript first, then means to activate them added to mapserv.

Anyone want to try a prototype using the current mapscript?  I'd be
willing to assist with design and python prototyping if we can get a few
folks together (and we'd especially need someone from the "inside" to do
a good job on the DTD)...  Or is this a waste of time?

BTW, hope I don't sound like I think I have all the answers!  I LOVE
Mapserver and its brethren, and I owe a debt of gratitude to everyone
who's worked on it!  I'm also not ignoring PHP or PHP mapscript; they
are both nifty hacks and I use them.  I focusing on python, C++, and
Java (please don't ask me to think about C#, it makes my brain explode),
because they have more robust object-oriented features and are better
suited for general-purpose programming.   Although you can now use PHP
"outside" of web servers, I wouldn't use it that way.  Python saves me
time.  YMMV.

Bye-bye.
Vic

On Thu, 2002-05-23 at 14:33, Steve Lime wrote:

    ESRI's not stupid, there are many a thing to learn from their
    implementations, and those of other vendors. I personally take it as a
    compliment when compared favorably with ArcIMS. Moving forward without
    looking at others are doing would be foolish on our part.

    The most compelling argument for the use of XML in my mind is
    simplification of the mainentenance of map files. If I understand this
    right you have 2 options (please correct me where I stray from
    reality):

      1: parse XML or current map file syntax into the current C structures
    and proceed as normal
      2: load XML directly to a DOM structure and pass that around in place
    of the mapObj

    Option 1 is what can be looked at short term as there are some benefits
    to using external XML tools, as alluded to in an earlier message. This
    option doesn't make maintanence any more palatable. Option 2 is where
    it's at. To add functionality you do it by having functions recognize
    new parameters. Nothing to do on the input end, since the parameters are
    all held in a neutral format and read by standard tools. I guess you'd
    just have to edit a schema or whatever so that defaults are properly
    handled. In that enviroment MapScript would be greatly simplified and
    would largely consist of: (1) a few methods to get/set portions of the
    DOM, and (2) the wealth of methods to actually DO something with it.
    Losing the lexer, at least for file parsing (expressions are another
    matter), would be a good thing (thread-wise). 

    I do think it's worth looking at, and yes showing is always better than
    telling...

    Steve

    Stephen Lime
    Data & Applications Manager

    Minnesota DNR
    500 Lafayette Road
    St. Paul, MN 55155
    651-297-2937

    >>> "C F" <gis_consultant@hotmail.com> 05/23/02 01:59PM >>>
    I knew that despite my disclaimers, by mentioning IMS, people would
    assume 
    that's what I'm shooting for.  All I can say is that is much farther
    off the 
    mark than I can possibly tell you.  If you want to have an offline 
    discussion about that, I'd be happy to.  This gist of the story is that
    just 
    because a product we don't like uses a particular kind of technology
    for one 
    piece of it's puzzle, doesn't mean we can't benefit from using the same

    technology for our own benefit.  If that was the rule, then I guess 
    MapServer wouldn't be a web-base map server... serving up map images
    using a 
    CGI server component and using web browsers as clients.
    It seems like a good portion of the conflict comes between people like
    me 
    who are interested in building more dynamic, integrated *applications*
    vs. 
    people who mostly use MapServer as a simple, install-and-go map
    server....  
    That's oversimplifying and not a catch-all, but I'm just trying to
    focus the 
    conversation.  A lot of stuff has been thrown into the mix and is
    confusing 
    and scaring some people off.
    I think for starters, maybe we could throw out the performance issue
    for 
    now.  Because, to me, it is something that is very debatable but will
    not be 
    need to be resolved unless we convince people that XML is the way to go

    based on functionality.... if the guys with authority think it's worth
    a 
    shot, THEN we test the feasibility of doing so without losing
    performance.  
    To answer people's concern about serializing XML DOM objects to a
    file.... 
    think of it as compiling your C program.  Are interpreted languages
    faster 
    than compiled languages?  No.  And in as sense it should simplify the 
    MapServer code.  It would be harder at first because MapServer is
    already 
    written for the current MapFile structure... but the result would be
    getting 
    rid of custom mapfile parsing classes and use standard XML parsers 
    instead... less code... less maintenance.  As additional functionality
    is 
    brought into MapServer that requires additional MapFile structures....
    piece 
    of cake with XML.  That's progress.
    Oops.... I'm straying again... back to the other kind of MapServer
    users... 
    as people have mentioned before, it's certainly possible to still keep
    the 
    existing mapfile format, so that shouldn't be your primary concern. 
    We're 
    simply looking at the possibilty of switching (or adding) a technology
    that 
    is more standardized and flexible rather than continuing to invent 
    proprietary methods.
    Okay, I keep promising myself I'm not going to be able to convince
    anybody 
    by talking... I need to come up with real, working examples, which I
    can't 
    do if I'm typing email all day.  If I can stay out of here long enough
    maybe 
    I'll come up with something in a few weeks :)

    >From: Richard Greenwood <Rich@GreenwoodMap.com>
    >To: mapserver-users@lists.gis.umn.edu 
    >Subject: Re: [mapserver-users] mapserver-dev list? (was: XML
    mapfile?)
    >Date: Thu, 23 May 2002 12:09:35 -0600
    >
    >Daniel Morissette wrote:
    >
    >>How about a mapserver-dev list where all new development questions
    are
    >>discussed without disturbing regular users?
    >
    >Sounds like a good idea, but not being a developer,  my vote shouldn't

    >carry a lot of weight.
    >
    >Regarding all the hoopla over XML; I've got some questions, or maybe 
    >reservations. I'm pretty ignorant of XML, but sometimes a little
    ignorance 
    >enhances ones objectivity, so here goes. It seems generally accepted
    that 
    >XML is probably slower than the current map file format and that you
    need 
    >to serialize the DOM. A CGI program can't hold this serialized object
    in 
    >memory, so you're going to have to write it out as a new map file, or

    >abandon CGI in favor of JSP or a similar technology, no?
    >
    >In either case the disadvantages would seem to out weight the
    advantages: 
    >if you write out a new map file, then all you done is written a 
    >preprocessor for XML. Why not write one for French, too? <g> If you
    abandon 
    >CGI in favor of JSP, then you end up with A**IMS, which you can
    already buy 
    >off the shelf.
    >
    >And for all of that, what have you really gained in terms of
    functionality? 
    >The existing CGI mapserver is fast, flexible, portable and easy to 
    >configure. Before someone suggests that it be remolded in the image of

    >A**IMS, they should take time to get to know mapserver. If it still
    doesn't 
    >meet their needs, or if CGI is just entirely too retro, then go with 
    >mapscript, where, as was stated previously, "the sky is the limit".
    >
    >Of all the arguments in favor of XML that have been throw out in the
    last 
    >couple days, the only one that hold any water in my bucket is the 
    >possibility of enhanced WMS compatibility. The rest of it sounds like
    a 
    >desire to push a stolid work horse into a trendy new wrapper.
    >
    >Rich
    >
    >
    >Richard W. Greenwood, PLS
    >Greenwood Mapping, Inc.
    >Rich@GreenwoodMap.com 
    >(307) 733-0203
    >http://www.GreenwoodMap.com 

    _________________________________________________________________
    Chat with friends online, try MSN Messenger: http://messenger.msn.com 

--=-SAfMYLq49bW67nxp2C+H
Content-Type: text/html; charset=utf-8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/1.0.3">
</HEAD>
<BODY>
&quot;Former&quot; Lurker Here Again,
<BR>

You know, I've thought a lot about an 'XML-ified' version of Mapserver, and I've concluded that its a darn good idea to make it work that way (see my previous long-winded post to the list).&nbsp; I have also concluded that we can't efficiently do it purely in parallel with the existing mapfile format.&nbsp; To be really useful, the efforts will eventually need a lot of coordination.&nbsp; I think it might work to have the existing file format be the input for a program (mapserv) that internally uses code objects that may also be manufactured with XML files.&nbsp; Sort of a special case of Steve Lime's &quot;Option 2&quot;.&nbsp; Here goes...

<BR>
In my dreams, I envision a way that the mapserver handles the march of revisions elegantly, in a manner similar to the way web browsers handle HTML.&nbsp; OK, maybe even better than web browsers handle HTML &lt;wink&gt;.&nbsp; A proper set of mapserver-related object classes would be terrific, and code that traverses DOM trees is an easy way to handle all this stuff.&nbsp; Furthermore, don't stop with web pages -- it is probably just as easy to implement and document classes (I prefer python or C++) that are populated by XML files and may be used for all sorts of things.&nbsp; For me, this is the real power of the XML mapfile strategy, and it seems to me that a natural way to make progress is to leverage the mapscript library.&nbsp; 
<BR>

May I propose wrapper classes that manufacture mapscript objects from XML?&nbsp; I think python would be a dynamite way to start, since it does pretty darn good OO, it's easy to learn, it has nice XML processing tools, it's very productive to code in, and mapscript/python exists.&nbsp; The wrapper would read an XML file (&quot;MapservML&quot;?), and traverse the DOM tree, using mapscript methods to populate the internal data structures, do rendering/queries, etc.&nbsp; The constructor would then return an object that could be used for lots of other things, e.g., adding layers made from local data, rendering to a bitmap/ps/pdf/vrml and then allowing mark-up with &quot;draw line&quot;, &quot;draw circle&quot;, &quot;draw arrow&quot;, &quot;draw text&quot;, and so forth, even allowing drawing in world coordinates!&nbsp; Also (in python for example), we could readily make COM/DCOM objects on Windows, so you could plug the objects into VB/VBA/Office (or make CORBA components).&nb!
sp; It's a functional step toward the ESRI GIS Objects stuff, but it's open and cross-platform.&nbsp; Can mapscript make GML or is that a mapserv function?

For performance reasons, the wrapper might eventually be written in C or C++ and linked to python/php/perl/[I can't resist saying Scheme for some reason] for application development.&nbsp; I'd propose prototyping in python and converting to C modules later to satisfy performance needs and link to all those other languages that I don't use &lt;grin&gt;.

Here's the potentially controversial part, and I apologize in advance for being so presumptuous.&nbsp; Over time, the mapscript library would become the base implementation for all the programmatic rendering innards of mapserver and mapserv would simply be a CGI front-end which reads the current format and has mapscript objects and an HTML template generator built into the back-end (incidentally, you could make an &quot;xml-mapserv&quot; by using an XML file instead of the current format in a jiffy!).&nbsp; I suspect it would require decoupling the QUERY stuff from the LAYER objects (or else put some programmatic glue in mapserv), since the query template, etc. has no real meaning in a non-mapserv context.&nbsp; I apologize because I haven't looked closely at the code -- is it already done this way?&nbsp;

To my uneducated eye, it looks like a &quot;reasonably&quot; short trip (especially if I don't have to write it, HOHO!) from the current mapserver and mapscript to a set of components that could do so much more than web sites...&nbsp; However, it is only realistic to do so if the effort can eventually be coordinated with mapserver development.&nbsp; Eventually it could mean making mapscript expose all the necessary features of mapserv, and new rendering features, etc. would need to be in mapscript first, then means to activate them added to mapserv.

Anyone want to try a prototype using the current mapscript?&nbsp; I'd be willing to assist with design and python prototyping if we can get a few folks together (and we'd especially need someone from the &quot;inside&quot; to do a good job on the DTD)...&nbsp; Or is this a waste of time?

BTW, hope I don't sound like I think I have all the answers!&nbsp; I LOVE Mapserver and its brethren, and I owe a debt of gratitude to everyone who's worked on it!&nbsp; I'm also not ignoring PHP or PHP mapscript; they are both nifty hacks and I use them.&nbsp; I focusing on python, C++, and Java (please don't ask me to think about C#, it makes my brain explode), because they have more robust object-oriented features and are better suited for general-purpose programming.&nbsp;&nbsp; Although you can now use PHP &quot;outside&quot; of web servers, I wouldn't use it that way.&nbsp; Python saves me time.&nbsp; YMMV.

<BR>
Bye-bye.
<BR>
Vic
<BR>

<BR>
On Thu, 2002-05-23 at 14:33, Steve Lime wrote:
    <BLOCKQUOTE>
<PRE><FONT COLOR="#737373"><FONT SIZE="3"><I>ESRI's not stupid, there are many a thing to learn from their</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>implementations, and those of other vendors. I personally take it as a</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>compliment when compared favorably with ArcIMS. Moving forward without</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>looking at others are doing would be foolish on our part.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>The most compelling argument for the use of XML in my mind is</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>simplification of the mainentenance of map files. If I understand this</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>right you have 2 options (please correct me where I stray from</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>reality):</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>  1: parse XML or current map file syntax into the current C structures</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>and proceed as normal</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>  2: load XML directly to a DOM structure and pass that around in place</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>of the mapObj</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>Option 1 is what can be looked at short term as there are some benefits</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>to using external XML tools, as alluded to in an earlier message. This</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>option doesn't make maintanence any more palatable. Option 2 is where</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>it's at. To add functionality you do it by having functions recognize</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>new parameters. Nothing to do on the input end, since the parameters are</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>all held in a neutral format and read by standard tools. I guess you'd</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>just have to edit a schema or whatever so that defaults are properly</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>handled. In that enviroment MapScript would be greatly simplified and</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>would largely consist of: (1) a few methods to get/set portions of the</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>DOM, and (2) the wealth of methods to actually DO something with it.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>Losing the lexer, at least for file parsing (expressions are another</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>matter), would be a good thing (thread-wise). </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>I do think it's worth looking at, and yes showing is always better than</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>telling...</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>Steve</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>Stephen Lime</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>Data &amp; Applications Manager</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>Minnesota DNR</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>500 Lafayette Road</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>St. Paul, MN 55155</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>651-297-2937</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;&gt;&gt; &quot;C F&quot; &lt;gis_consultant@hotmail.com&gt; 05/23/02 01:59PM &gt;&gt;&gt;</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>I knew that despite my disclaimers, by mentioning IMS, people would</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>assume </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>that's what I'm shooting for.  All I can say is that is much farther</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>off the </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>mark than I can possibly tell you.  If you want to have an offline </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>discussion about that, I'd be happy to.  This gist of the story is that</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>just </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>because a product we don't like uses a particular kind of technology</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>for one </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>piece of it's puzzle, doesn't mean we can't benefit from using the same</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>technology for our own benefit.  If that was the rule, then I guess </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>MapServer wouldn't be a web-base map server... serving up map images</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>using a </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>CGI server component and using web browsers as clients.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>It seems like a good portion of the conflict comes between people like</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>me </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>who are interested in building more dynamic, integrated *applications*</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>vs. </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>people who mostly use MapServer as a simple, install-and-go map</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>server....  </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>That's oversimplifying and not a catch-all, but I'm just trying to</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>focus the </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>conversation.  A lot of stuff has been thrown into the mix and is</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>confusing </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>and scaring some people off.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>I think for starters, maybe we could throw out the performance issue</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>for </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>now.  Because, to me, it is something that is very debatable but will</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>not be </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>need to be resolved unless we convince people that XML is the way to go</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>based on functionality.... if the guys with authority think it's worth</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>a </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>shot, THEN we test the feasibility of doing so without losing</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>performance.  </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>To answer people's concern about serializing XML DOM objects to a</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>file.... </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>think of it as compiling your C program.  Are interpreted languages</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>faster </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>than compiled languages?  No.  And in as sense it should simplify the </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>MapServer code.  It would be harder at first because MapServer is</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>already </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>written for the current MapFile structure... but the result would be</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>getting </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>rid of custom mapfile parsing classes and use standard XML parsers </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>instead... less code... less maintenance.  As additional functionality</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>is </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>brought into MapServer that requires additional MapFile structures....</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>piece </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>of cake with XML.  That's progress.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>Oops.... I'm straying again... back to the other kind of MapServer</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>users... </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>as people have mentioned before, it's certainly possible to still keep</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>the </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>existing mapfile format, so that shouldn't be your primary concern. </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>We're </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>simply looking at the possibilty of switching (or adding) a technology</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>that </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>is more standardized and flexible rather than continuing to invent </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>proprietary methods.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>Okay, I keep promising myself I'm not going to be able to convince</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>anybody </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>by talking... I need to come up with real, working examples, which I</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>can't </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>do if I'm typing email all day.  If I can stay out of here long enough</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>maybe </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>I'll come up with something in a few weeks :)</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;From: Richard Greenwood &lt;Rich@GreenwoodMap.com&gt;</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;To: mapserver-users@lists.gis.umn.edu </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;Subject: Re: [mapserver-users] mapserver-dev list? (was: XML</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>mapfile?)</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;Date: Thu, 23 May 2002 12:09:35 -0600</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;Daniel Morissette wrote:</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;&gt;How about a mapserver-dev list where all new development questions</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>are</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;&gt;discussed without disturbing regular users?</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;Sounds like a good idea, but not being a developer,  my vote shouldn't</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;carry a lot of weight.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;Regarding all the hoopla over XML; I've got some questions, or maybe </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;reservations. I'm pretty ignorant of XML, but sometimes a little</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>ignorance </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;enhances ones objectivity, so here goes. It seems generally accepted</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>that </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;XML is probably slower than the current map file format and that you</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>need </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;to serialize the DOM. A CGI program can't hold this serialized object</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>in </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;memory, so you're going to have to write it out as a new map file, or</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;abandon CGI in favor of JSP or a similar technology, no?</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;In either case the disadvantages would seem to out weight the</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>advantages: </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;if you write out a new map file, then all you done is written a </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;preprocessor for XML. Why not write one for French, too? &lt;g&gt; If you</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>abandon </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;CGI in favor of JSP, then you end up with A**IMS, which you can</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>already buy </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;off the shelf.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;And for all of that, what have you really gained in terms of</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>functionality? </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;The existing CGI mapserver is fast, flexible, portable and easy to </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;configure. Before someone suggests that it be remolded in the image of</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;A**IMS, they should take time to get to know mapserver. If it still</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>doesn't </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;meet their needs, or if CGI is just entirely too retro, then go with </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;mapscript, where, as was stated previously, &quot;the sky is the limit&quot;.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;Of all the arguments in favor of XML that have been throw out in the</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>last </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;couple days, the only one that hold any water in my bucket is the </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;possibility of enhanced WMS compatibility. The rest of it sounds like</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>a </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;desire to push a stolid work horse into a trendy new wrapper.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;Rich</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;Richard W. Greenwood, PLS</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;Greenwood Mapping, Inc.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;Rich@GreenwoodMap.com </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;(307) 733-0203</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>&gt;http://www.GreenwoodMap.com </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>_________________________________________________________________</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>Chat with friends online, try MSN Messenger: http://messenger.msn.com </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
</PRE>
    </BLOCKQUOTE>
</BODY>
</HTML>

--=-SAfMYLq49bW67nxp2C+H--