XPATH library to support GML parsing

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

XPATH library to support GML parsing

Cameron Shorter
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")

The cross browser XPATH and XSLT functionality we use is provided by
http://sarissa.sf.net . I assume other ajax frameworks like Dojo and
Atom provide something similar.

While I'm not convinced that XSLT is required by OpenLayers yet, I think
XPATH would be very useful.

I suggest that OpenLayers considers including all, or part of a library
which supports XPATH. Sarissa is available under the LGPL, GPL and
Apache Software Licence.

--
Cameron Shorter
http://cameron.shorter.net
_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: XPATH library to support GML parsing

Paul Spencer-2
Isn't this the part that makes mapbuilder not work in Safari?

Paul

On 9-Nov-06, at 10:43 PM, 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")
>
> The cross browser XPATH and XSLT functionality we use is provided by
> http://sarissa.sf.net . I assume other ajax frameworks like Dojo and
> Atom provide something similar.
>
> While I'm not convinced that XSLT is required by OpenLayers yet, I  
> think
> XPATH would be very useful.
>
> I suggest that OpenLayers considers including all, or part of a  
> library
> which supports XPATH. Sarissa is available under the LGPL, GPL and
> Apache Software Licence.
>
> --
> Cameron Shorter
> http://cameron.shorter.net
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://openlayers.org/mailman/listinfo/dev

+-----------------------------------------------------------------+
|Paul Spencer                          [hidden email]    |
+-----------------------------------------------------------------+
|Chief Technology Officer                                         |
|DM Solutions Group Inc                http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+




_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: XPATH library to support GML parsing

Cameron Shorter
Yes Paul.
 From the Sarissa web site:
"Supported browsers are Mozilla - Firefox and family, Internet Explorer
with MSXML3.0 and up, Konqueror (KDE 3.3+ for sure), Safari and Opera.
Konq, Safari and Opera offer no XSLT/XPath scripting support AFAIK."

A quick trawl around the web found a recommendation for Google AjaXSLT:
 From memory, the reviews of this suggested XSLT performance was not so
good in browsers which didn't support XML natively. However, XPATH might
be ok as it should be easier to implement.

http://www.oreillynet.com/xml/blog/2006/02/callout_to_applemacsafari_comm.html
and
http://sourceforge.net/projects/goog-ajaxslt/

"AJAXSLT is an implementation of XSLT in JavaScript. Because XSLT uses
XPath, it is also an implementation of XPath that can be used
independently of XSLT. This implementation has the advantange that it
makes XSLT uniformly available on more browsers than natively provide
it, and that it can be extended to still more browsers if
necessary.

The library works in these browsers:

- Firefox/1.0, Firefox/1.5
- Internet Explorer/6.0
- Safari/1.2, Safari/1.3, Safari/2.0
- Opera/8.0, Opera/8.5"


Paul Spencer wrote:

> Isn't this the part that makes mapbuilder not work in Safari?
>
> Paul
>
> On 9-Nov-06, at 10:43 PM, 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")
>>
>> The cross browser XPATH and XSLT functionality we use is provided by
>> http://sarissa.sf.net . I assume other ajax frameworks like Dojo and
>> Atom provide something similar.
>>
>> While I'm not convinced that XSLT is required by OpenLayers yet, I  think
>> XPATH would be very useful.
>>
>> I suggest that OpenLayers considers including all, or part of a  library
>> which supports XPATH. Sarissa is available under the LGPL, GPL and
>> Apache Software Licence.
>>
>> --
>> Cameron Shorter
>> http://cameron.shorter.net
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://openlayers.org/mailman/listinfo/dev
>
>
> +-----------------------------------------------------------------+
> |Paul Spencer                          [hidden email]    |
> +-----------------------------------------------------------------+
> |Chief Technology Officer                                         |
> |DM Solutions Group Inc                http://www.dmsolutions.ca/ |
> +-----------------------------------------------------------------+
>
>
>
>
>


--
Cameron Shorter
http://cameron.shorter.net
_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: XPATH library to support GML parsing

Christopher Schmidt-2
In reply to this post by Cameron Shorter
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
_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev