Re: XPATH query Take 2

[Farrukh Najmi <Farrukh.Najmi@east.sun.com>]

Frank,

Thanks for your comments on this vital issue. Yesterday we spent an entire day
looking at the XPATH alternative.

I am not an XPATH expert regarding the node set issue you bring up. We will look
into it with Mike Rowley and ask that all XPATh experts on the list keep an eye
out for a posting today in which we will summarize the meeting from yesterday
and an XPATH alternative approach that maps the OQL queries and the info modem
to XPATH on a set of virtual XML documents that are designed with a schema that
makes it more easier to use XPATH. In yesterdays meeting this virtual document
concept was breakthrough that mitigated my biggest concerns regarding the use of
XPATH.

I wanted to mention that the concern about perceived OQL implementation
complexity could be mitigated by a free implementation of an OQL query processor
with a RDB binding. I have mentioned in the past that I am exploring the
possibility of Sun donating any OQL processor for the registry if OQL is what
the registry group agrees to.

More later.

--

Regards,
Farrukh

"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.
>
> Frankie

--
Regards,
Farrukh

begin:vcard 
n:Najmi;Farrukh
tel;work:781-442-0703
x-mozilla-html:FALSE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh Najmi
end:vcard