RE: XPath host language for querying several XML fragments

A couple of editorial points first:

(a) you should surely be referring to the XPath 2.0 Recommendation of 23
January 2007 rather than the Proposed Recommendation of 21 November 2006. (I
would also suggest that you avoid referring to a specifically dated version,
so that you refer the reader to the latest edition at any given time, which
may incorporate errata.)

(b) the www-xpath-comments list is intended for comments on XPath 1.0; the
correct list for XPath 2.0 is the public-qt-comments list.

(c) since the namespace prefix "xs" is often used to refer to the XML Schema
namespace, it might be clearer to your readers if you chose a prefix other
than "XS" - perhaps "WXS"?

Now a general policy point:

(d) there are many people who seem to perceive a need for subsetting XPath,
with a variety of objectives that usually include (i) reducing the cost of
implementation, and (ii) making it harder for users to specify expressions
that will be expensive to evaluate. The designers of such subsets seem to
come up with a wide variety of different solutions to this problem. This
variety can only confuse users. It also makes it less likely that an
implementor can take an existing XPath implementation and reuse it, which by
the law of unintended consequences actually increases costs for
implementors. Despite the difficulty of finding a rational basis for
deciding which features to include in a subset and which to exclude, I think
there is something to be said for having an XPath 2.0 subset defined by the
responsible W3C working groups (XSL and XQuery) and then strongly
discouraging other groups from defining their own subsets.

Now some detailed technical points:

(e) an implementation that does not support descendant, descendant-or-self,
or "//" is going to be pretty unusable. Searching for elements at arbitrary
depth is a great user convenience, and is essential in the case of recursive
document structures. If you're going to make some of the axes optional, I
suggest you choose the same subset as XQuery chose.

(f) you define the minimum set of functions that an implementation must
supply as being empty (no functions). There are some functions such as not()
and count() that I would consider absolutely indispensible.

(g) I don't think the restrictions you propose for numeric predicates assist
with either of your design objectives (reduced implementation cost,
throttled performance). They just make the language less orthogonal and less
interoperable.

This is a personal response, I hope the WGs will produce an official
response in due course.

Michael Kay
http://www.saxonica.com/



 

> -----Original Message-----
> From: www-xpath-comments-request@w3.org 
> [mailto:www-xpath-comments-request@w3.org] On Behalf Of Javier Godoy
> Sent: 21 January 2008 09:19
> To: www-xpath-comments@w3.org
> Subject: XPath host language for querying several XML fragments
> 
> 
> Hello. I'm developing an XPath host language for querying XML 
> fragments from a repository 
> [http://www.ietf.org/internet-drafts/draft-godoy-webdav-xmlsea
> rch-00.txt] .
> 
> Since there may be several XML fragments within the search 
> scope, the proposed approach would have implicated a terrible 
> evaluation cost if arbitrary complex queries had been 
> allowed. So I'm trying to distinguish a subset of "basic" 
> XPath features (which would be REQUIRED) from other features 
> that would be OPTIONAL (the latter may be supported or not, 
> as necessary for each particular use-case). As a consequence, 
> features from the "basic" subset are intended to suffice for 
> most use-cases, and their evaluation may rely on a relational 
> database for optimized processing.
> 
> I would appreciate your feedback about this proposal, as well 
> as any correction about XPath-related issues .
> 
> Regards,
> 
> Javier Godoy
> 
> 
> 
>

Received on Monday, 21 January 2008 12:45:37 UTC