RE: XPATH query Take 2

[JP Morgenthal <jp.morgenthal@xmls.com>]

My comments never made it to the list yesterday so I will summarize and
repost them today (now that I'm finally allowed to post).

1.  XPath is designed to work against a single root context.  It is very
difficult to take many XML documents (mixed with possible non-XML documents)
and make them look like a single document context.  Hence, searching using
XPath in its current form would be extremely complex (if not impossible) for
the purposes intended here. 

2.  OQL as a language for ad-hoc query is far too much overhead for the
intended purpose and is an incorrect view of what we are creating.  This is
first and foremost a registry.  When you use OQL or SQL as a language, it
turns it into a database application.  Registries have a common nomenclature
for access.  You build a context and then search that context.  We should be
looking at the work done by the LDAP group if we look anywhere for a query
facility for registries.

3.  We need to be careful as a group not to imply ANY implementation detail
for registries.  OQL implies that the data is stored in a fashion that
supports algebraic joining.  We need to institute and interface that is
clearly implementation independent.  Again, I think we need to look at the
work of the LDAP group as an excellent example of this.

That's my story and I'm stickin' to it! :-)

Regards All,
JP

-----Original Message-----
From: Farrukh Najmi
To: frankp@softed.com
Cc: RegRep; mrowley@exceloncorp.com
Sent: 1/5/2001 8:50 AM
Subject: Re: XPATH query Take 2

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

 <<Card for Farrukh Najmi>>