[OpenLayers-Dev] XPATH library to support GML parsing

[Christopher Schmidt]

On Fri, Nov 10, 2006 at 02:43:30PM +1100, Cameron Shorter wrote:
> Mapbuilder has GML, WMC, SLD parsers which could be ported over 
> OpenLayers. In particular, I'm considering porting the GML parser over 
> to OpenLayers to provide a GML Layer.
> 
> In Mapbuilder we use XPATH for a lot of our parsing.
> At other times, we use XSLT.
> Xpath syntax looks something like:
> selectSingleNode("//ows:BoundingBox/@crs")

I've been pondering this for a couple days, and here are my thoughts on
the matter.

1. It is going to be practically impossible for OpenLayers to support
every flavor of WFS/GML out there. The contortions that are allowable
under the GML specification are simply too broad to try to cover every
use case, so this should not be a design goal.

2. There are a couple open source implementations of WFS servers which
are in wide deployment, and are the most likely use cases for loading
GML/SLD in OpenLayers. Therefore, the content which these servers spit
out (and probably ArcIMS, as much as it pains me to say) should be the
ones that we should put the most effort forth on.

3. These 2/3 implementations implement a relatively regular style of
WFS: regular enough that parsing it using standard DOM implementations
available in browsers should be 'good enough' for most use cases. 

4. For the users for whom 'good enough' isn't good enough, additional
libraries for parsing can be made available *outside* the main
OpenLayers build. This means that there could be a basic GML parser
which is DOM-based, and a more complex one which is Sarissa-based, but
not included in the main tree.

Therefore:

We should not at any point in the forseeable future plan on including 
any additional XML implementation which is written in Javascript in the
OpenLayers core. This functionality should be made as simple as possible
to include for people who are interested in such a thing without it
being the default for users of the OpenLayers library. 

We should determine how best to support parsing the 2-3 most common
WFS/GML output implementations in core WFS/GML parsing libraries. If
this determination requires that we add regularized wrappers around
differing JS DOM APIs between the browsers (similar to the existing
OpenLayers.Ajax.getElementsByTagNameNS() function), then these wrappers
for the ease of cross-browser development should be made available.

We should keep in mind that parsing any GML should not be a goal for the
core library, and that instead we should make it as simple as possible
for people to extend the parsing for their own particular needs. 

I feel that the result of this will be best for everyone using the
project. The majority of the OpenLayers users do not need to be saddled
with a complex GML parsing framework just to work with Mapserver WFS.

Much of the same things which can be said about GML here can be said
about KML. It is infinitely flexible, and OpenLayers should target
serving the maximum number of people with the minimum amount of code.
When we get round to that type of parsing, it should be looked into what
commonalities there are between different KML sources, and then an
attempt to hit that target as well as possible. 

I'm open to discussion on this, but it seems after a lot of thinking
that this is probably the path which is most likely to achieve success
in the shortest timeframe for the greatest number of people now and in
the future.

Regards,
-- 
Christopher Schmidt
MetaCarta