<!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>

<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>

<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>

<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?
<BR>

<BR>
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;.
<BR>

<BR>
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; 
<BR>

<BR>
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.
<BR>

<BR>
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?
<BR>

<BR>
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>

<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>