Re: Comments by XSL WG on DOM Level 3 XPath API

[XSL WG comments to DOM Level 3 XPath]

On Fri, 2002-04-26 at 10:17, Scott wrote:
> This is the formal comments by the XSL Working Group regarding the DOM
> Level 3 XPath API at
> http://www.w3.org/TR/2002/WD-DOM-Level-3-XPath-20020328/.  On our April 25,
> 2002, telcon we discussed and approved these comments.  We hope these
> comments are acceptable as a response to
> http://lists.w3.org/Archives/Member/w3c-dom-wg/2002JanMar/0105.html.
> 
> The comments are made with awareness of the discussion at
> http://lists.w3.org/Archives/Public/www-dom/2002JanMar/thread.html#271,
> titled "Comments on DOM XPath Interface", and elsewhere on the public
> comments list.
> 
> 1) The XSL WG understands that the intent is for the API to cover XPath 1.0
> only, and that an entirely new attempt would be made for XPath 2.0 and
> XQuery 1.0.  The WG feels this is regrettable given how much is known about
> at this point about the XPath 2.0 data model, the XPath 2.0/XQuery 1.0
> context requirements, and the XPath 2.0/XQuery 1.0 result output.  We feel
> it would be better to design the DOM Level 3 XPath API to be upgradeable to
> an API that could handle XPath 2.0/XQuery 1.0.  In two years, having two
> APIs that functionally do the same thing will be a disservice to Web
> application developers.
> 
> The decision to not restrict the design to only considering XPath 1.0
> should not be based on the namespace node issues.  Even with these nodes,
> the difference from the XPath 1.0 data model should be rather small.
> Beyond namespace nodes, the XSL WG does not think that the XPath 2.0 data
> model differs significantly from the XPath 1.0 data model.
> 
> Following this line:
> 
>    a)  The notion that the result can be any sequence, of atomic values or
>    nodes, is quite clear in XPath 2.0/XQuery 1.0, and structuring
>    XPathResult on this basis would not only make the transition to XPath
>    2.0 easier, it would also give a cleaner interface for XPath 1.0.  As it
>    is, XPathResult seems a rather odd combination of iteration and single
>    value wrapper.
> 
>    b) Both XPathEvaluator#evaluate and XPathExpression#evaluate could and
>    should accept a context argument as a parameter, which may be null.
>    Even if you don't specify this now, a note that you may specify such a
>    thing in the future would make the XPath 2.0 upgrade path clear.
> 
> 
> 2) We do not think the specification says what method getNodeValue() will
> return, when applied to a namespace node, even though it seems to be
> covered by Issue XPath-11.
> 
> 3) It should be made explicit that xmlns: attributes will *not* be exposed
> as attribute nodes through the XPath interface.
> 
> 4) The specification says nothing about the use of the XPath id() function.
> Does this mean it is always guaranteed to work?  If not, might there be a
> function that tells if it will work?
> 
> 5) There should be conformance rules. For example, is an implementation
> conformant if it extends the vocabulary of functions that can be called
> within an XPath expression?
> 
> 6) The "is expected" language in
> http://www.w3.org/TR/2002/WD-DOM-Level-3-XPath-20020328/xpath.html#XPathEvaluator
>  is overly vague as to what one can expect from a DOM Implementation that
> returns true for hasFeature("Xpath", "3.0").  If this returns true, can one
> definitely cast the Document interface to an XPathEvaluator?  (We have
> heard some non-exact information that this may be being fixed already).
> 
> 7) Description states "this adapter works by calling the method named
> lookupNamespacePrefix on Node". This appears to be a typo and should
> probably be the method named "lookupNamespaceURI". More importantly, this
> would appear to conflict with previously stated requirement that only DOM
> Level 2 Core need to be implemented since lookupNamespaceURI is a Level 3
> core method. Additionally there appears to be no formal requirement for the
> nodeResolver that is passed in to be from the same implementation of DOM so
> it could theoretically even be from a Level 1 DOM. Either a formal
> requirement for Level 3 DOM needs to be required here or the specification
> should only hint that "lookupNamespaceURI" can be used in the event that
> the nodeResolver implements Level 3. If a formal requirement is made, then
> createNSResolver probably needs to be able to throw an Exception in the
> event that the requirement is not met.
> 
> 8) In the description of XPathExpression.evaluate(), WRONG_DOCUMENT_ERR,
> "not supported by the XPathExpression that created this XPathExpression"
> should probably be "not supported by the XPathEvaluator that created this
> XPathExpression".
> 
> 
> -scott

Received on Monday, 29 April 2002 13:57:46 UTC