Re: [dom-xpath] XPath or? (was RE: Announcing www-dom-xpath@w3.org)

At 01:34 PM 5/2/00 -0400, Scott Boag/CAM/Lotus wrote:

>I think the first order of bussiness might be to discuss whether or not
>XPath should have an API at all.  XPath is meant to be a normative,
>abstract, standard, above XPointer, XSLT, and XML Query (hopefully).  Maybe
>what people really need is an XML Query API or an XPointer API.  If it's an
>XML Query API, it's way early to be discussing this.  On the other hand,
>XML Query and XPointer don't really return the result of a random
>expression, like "2+2".  So I dunno.

XPath certainly can be used as a simple query language that does 
projections on a document. In fact, one of the precursors of XPath was XQL, 
which was designed as a query language from the beginning, and which is 
basically the same as the abbreviated syntax of XPath.

Nobody knows for sure what XML Query will do, it's much too early, but if 
it follows the lead of languages like SQL, it may well be able to return 
single values as the result of aggregate functions, e.g. 
"average(//invoice//price)" or "2*average(//invoice//price//)" or even "2+2".

>I would really *not* like to see something like getNodes(XPath expression)
>as a method on Node.  DOM2 is already way too bloated.

What kind of bloat are you concerned about, code size or complexity of 
implementations? I assume that you aren't concerned about adding a small 
handful of calls to the interface, since that wouldn't make a big 
difference. If XQL implementations are any guide, it's possible for one 
person to implement an abbreviated syntax XPath query engine in less than a 
month, but that *is* significant in terms of time. I think this API should 
be optional. On the other hand, this functionality is being added to many 
DOM implementations, and there is clearly benefit in establishing one way 
to do this - or am I missing something?

Jonathan

Received on Tuesday, 2 May 2000 15:32:23 UTC