Re: XPATH query Take 2

[duane <duane@xmlglobal.com>]

JP Morgenthal wrote:
> 
>
> 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.
>>>>>>

Hello all:

First off I apologize for not getting involved earlier inthis thread.  I
have been in the Alps.

This point made by JP is paramount and outlines my earlier concerns
dating back to May of this year.  There must be no processing done on an
XML document instance on a Registry Server.  The overhead will kill
ebXML.  The registry is a place to find a document instance.  All post
query overhead must be assumed on the users app.

Most of the talk has been also centered around using some sort of XPAth
/ Quilt hybrid.   If this is to be the supported syntax,  it must be
made very clear that this takes place on the users application, not
inside the Registry.  How big will it scale if we have 1,000 users a
minute hitting a Registry Server, loading up a document into DOM and
running XPath querioers against it?

I say not very efficient.  My vote - OQL - NO!!!

Duane Nickull


 
> 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>>