Re: XPath host language for querying several XML fragments

I have submitted a new version addressing most of the issues you raised. I
do not pretend it to be in final shape yet, but at least we get rid of some
bugs.

http://www.ietf.org/internet-drafts/draft-godoy-webdav-xmlsearch-01.txt

Summary of changes:

- Reference W3C.REC-xpath20-20070123
- Change namespace prefix to "WXS"
- Use required axes from XQuery.
- Set default function namespace to http://www.w3.org/2005/XPath-functions
- Set the function signatures as:
     fn:root($arg as node()?) as node()?     [note]
     fn:not($arg as item()*) as xs:boolean
     fn:count ($arg as item()*) as xs:integer
     fn:exists($arg as item()*) as xs:boolean
     fn:empty ($arg as item()*) as xs:boolean
     (may be overwritten).
- Draw a mechanism for advertising supported functions.

[note] because of the expansion for "/" and "//".

Again, thanks you for your comments.

Javier Godoy


----- Original Message ----- 
From: "Michael Kay" <mhk@mhk.me.uk>
To: "'Javier Godoy'" <rjgodoy@fich.unl.edu.ar>; <www-xpath-comments@w3.org>
Cc: "'Sharon Adler'" <sca@us.ibm.com>; "'Andrew Eisenberg'"
<andrew.eisenberg@us.ibm.com>; "'Jim Melton'" <jim.melton@acm.org>
Sent: Monday, January 21, 2008 9:40 AM
Subject: 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/

Received on Friday, 25 January 2008 16:28:41 UTC