Re: [Geotools-devel] Internal or External XPath processing

[Ian S. <Ian...@ar...>]

On Thursday 31 March 2005 10:19 am, Jesse Eichar wrote:
> On Thu, 2005-03-31 at 11:44 -0500, James Macgill wrote:
> > There has been a lot of talk about XPath over the past few days and
> > one issue which has been a little glossed over is where the xpath
> > smarts should live.
> >
> > IanS has noted his objections to getAttribute(String xPath) and Jody
> > has expressed his keenness for the power that it provides.
> >
> > It is important to note that IanS (as I understand it) does not object
> > to xpath itself, far from it, but rather to it bing handled inside
> > features.
> >
> > I mention this as jody recently gave the following example:
> > getAttribute('nodes/*/name')
> > Parsing that is quite hard work for a feature and if we want to have
> > interchangable feature implementations (i.e. more than just
> > DefaultFeature) then we are passing quite a burdon onto each
> > implementer.
>
> ...
>
> > Now the question is, where do we want to put the code to handle that
> > kind of logic?  Inside features or in an external utility?
> >
> > James
>
> I implemented an XPATH parser for MetadataEntity in the middle of last
> year which is separate from MetadataEntity but simply called by the
> getXXX() methods when required.  If the XPATH framework that exists has
> an implementation made for feature it would not need to be part of
> feature at all.  It could operate on the interfaces so the
> implementation could be easily switched without changing the
> implementation.
>
>With regards to where to put the logic I suppose it should be separate=20
> but nothing says that feature's getXXX() methods can't make calls to the
> utility=20
Of couse it could be allowed, but then a request for an attribute by name=20
always invokes an XPath parse. This not only puts a burden on simple=20
attribute lookups, but on an internal XPath implementation which would=20
probably use getAttribute itself. To be technically correct, to retreive an=
=20
Attribute from a Feature, one would use "@attname" as using "attname"=20
introduces an ambiguity - is "attname" and location path or an attribute.

>(preventing the user from having to know about the utility and
> the feature which can make learning more difficult).
Oh so difficult...
XPath.query(feature,"long/obnoxious/path[@toAttribute]");
or better yet
XPath.Query query=3D XPath.compile("long/obnoxious/path[@toAttribute]");
=2E..
query.eval(feature);

Before a decision is made, lets look at both useability and performance fro=
m=20
both a system and user view. Perhaps we could all add to some use cases and=
=20
combine our collective experiences.

Heres my limited, naive observations:
=46rom the system view, the most common place xpath queries will occur is i=
n=20
filters and styling. Because a Filter or Style will be called repeatedly (a=
nd=20
it already lags performance) the XPath query (even a simple one) will be=20
quite a hotspot, especially if theres ambiguity involved and no "compiling"=
=2E=20
Ideally, a Filter can compile its query to be reused over and over again.=20

I really can't see foresee much direct useage of XPath by users, as even no=
w,=20
most user code interacts will Filters and Styles. The greater burden is not=
=20
using an API or knowing about it, but actually understanding the XPath=20
language and which subset is supported in geotools and if the statement=20
itself has an error or is it only the junky implementation...

Regards,
Ian