[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: XPATH query Take 2
The GMD-IPSI XQL Engine downloadable from http://xml.darmstadt.gmd.de/xql/
returns a NodeSet (called a NodeList) and supports the basic XQL/XPath
syntax. You can use it with any DOM-compliant parser.
Audree A. Thurman
Independent Technical Consultant & Educator
On Fri, 5 Jan 2001, Frank G. Pitt wrote:
> A query and some opinions on queries :
> Firstly, I'd like to clarify something.
> I understood that XPath statements like the examples shown are designed only
> to return the _first_ object that matches the criteria, and that there is no
> easy way to get any more matches using XPath.
> At least, this is how XPath has worked in my usage of it so far, I have had
> to write explicit tree walks, matching each node individually, to get more
> than one match, as XPath "queries" have no 'history', so always returned the
> same (first) match.
> Are there DOM implementations that will return a nodeset rather than a
> single node in response to such a request ?
> If there aren't, then I don't see how XPath is a serious contender as a
> query language, or that the XPath statements are, in fact, equivalents of
> the OQL statements.
> I also think that the OQL syntax is far easier to understand in general,
> though if that really is the most complicated query you're ever going to
> use* it probably doesn't make much difference.
> (*it's a pretty simple one though, so be sure you don't need more. IME,
> people always find they need more complicated queries further down the
> track. )
> I personallly feel the objection to the usage of OQL from certain parties is
> commercially based rather than technically based*, because certain vendors
> don't want to have to implement OQL to be compliant. I can see where they
> are coming from, implementing OQL is a little harder**, but I don't agree
> that an international standard should be compromised for the commercial gain
> of a few small, but vociferous, vendors.
> (*I've seen no arguments that there is anything actually _wrong_ with using
> OQL, merely claims that everything needed can be done using XPath, so why
> bother with OQL ? )
> (** But not a lot harder, all they need is a transform to translate OQL into
> XPath, and then use the existing XPath engine. Should be simple if the
> claims of XPath being equivalent to OQL are correct...)
> I'd also like to point out that XPath is _not_ the same thing as XML Query,
> though XML Query _may_ make use of XPath syntax. Those arguing that we
> should be sticking to XML standards should be arguing for support of XML
> Query, not XPath, as XPath is _not_ the W3C's query recommendation for XML.
Powered by eList eXpress LLC