W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2002

Comments by XSL WG on DOM Level 3 XPath API

From: <scott_boag@us.ibm.com>
Date: Tue, 30 Apr 2002 09:54:44 -0400
To: www-dom@w3.org
Message-ID: <OFD77D31C6.BD55B266-ON85256BAB.004C5C0F@lotus.com>
(I guess I got the DOM email address wrong the first time).


----- Forwarded by Scott Boag/Cambridge/IBM on 04/30/2002 10:05 AM -----
                      Scott Boag                                                                                                  
                                               To:       Philippe Le Hegaret <plh@w3.org>                                         
                      04/26/2002 10:09         cc:       w3c-xsl-wg@w3.org, W3C DOM WG <w3c-dom-wg@w3.org>, Sharon Adler          
                      AM                        <sca@us.ibm.com>                                                                  
                                               Subject:  Comments by XSL WG on DOM Level 3 XPath API                              

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

The comments are made with awareness of the discussion at
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
 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

Received on Tuesday, 30 April 2002 10:03:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:10 UTC