Re: Comments on DOM XPath Interface

Michael Kay wrote:

>1. It is likely that XPath 2.0 will relax some of the rules concerning
>namespace nodes. In particular, rules concerning their identity, parentage,
>and position in document order. These relaxations are designed to make
>namespace nodes easier to implement without removing any useful
>functionality. The DOM might consider anticipating these changes, at the
>very least by a note advising users not to rely on these properties.
>
I refer you to the resolution of Issue 38 in the published last-call 
working draft.  It is not the intent of the specification to tell people 
they cannot rely on these things, because to the extent that the XPath 
2.0 model is incompatible either in attributes or behavior, supporting 
it will require a different interface.

>2. The specification does not say what methods such as getNodeName() and
>getNodeValue() will return, when applied to a namespace node. I would expect
>them to return the name and string-value of the node as defined in XPath,
>but since that is not true of other node types, I might be wrong.
>
It clearly states what each of these do.

In every case, accessors are documented under the attribute name only. 
 The getter is usually formed by adding get on the front and fixing 
casing.  There is also a setter if it is read-write.  I do not know why 
this would be done differently for this case.

Also, in the interface itself, the DOM specifications do not list the 
same attributes that were already defined in a previous interface, but 
it may have lists or tables citing how the attributes are more specific 
in the derived class.

<<<beginning of quote>>>

The core specification describes attributes of the Node interface that 
are different for different node node types but does not describe 
XPATH_NAMESPACE_NODE, so here is a description of those attributes for 
this node type. All attributes of Node not described in this section 
have a null or false value.

ownerDocument matches the ownerDocument of the ownerElement even if the 
element is later adopted.

prefix is the prefix of the namespace represented by the node.

nodeName is the same as prefix.

nodeType is equal to XPATH_NAMESPACE_NODE .

namespaceURI is the namespace URI of the namespace represented by the node.

<<<end of quote>>>

>3. It might help if the specification spelled out exactly how the set of
>namespace nodes for an element are derived from information accessible
>through other DOM interfaces. The different ways namespace information can
>be represented in DOM (through attributes representing namespace
>declarations, through namespace URIs on the element and attribute nodes,
>etc) is a constant source of difficulty. It should also be made explicit
>that xmlns: attributes will *not* be exposed as attribute nodes through the
>XPath interface.
>
It seems obvious that namespace nodes will only be returned that exist 
in the XPath data model, since these are XPath-specific nodes being 
returned only by the XPath implementation.  You may want to point out 
specific language you believe gives a false impression or some spot 
where you think something is needed.

Before the core DOM specification is released, it will be completely 
spelled out there (to the extent it isn't completely clear already) how 
the DOM determines which namespaces are in-scope on a particular 
element.  If you have a particular place in the XPath specification you 
would like to suggest a link to this, that could be useful.

>4. The interface provides only limited ability to set the XPath static and
>dynamic context. It provides no capabilities to create variables or
>extension functions, and no way of setting the context position or size. For
>the typical end-user of the interface, this is not a problem. However, it
>means that an implementor wishing to provide an XPath engine that is
>suitable for use, for example, by an XSLT processor, will need to provide
>additional interfaces, and these will vary from one implementation to
>another, which will make it more difficult to write an XSLT engine that can
>work with any DOM implementation.
>
The additional interfaces are simply out of scope for this version of 
the APIs, but unlike XPath 2.0, it is believed that these will be very 
easy to add if or when the effort occurs to implement these and 
standardize them.  This is a simple case of doing first what most people 
need, without preventing the rest.  As the issue has come up before, I 
do not believe there is the sufficient energy exists to standardize it 
now, but if you have particular interfaces you favor, I would suggest 
submitting them as a note and suggesting an activity that might have the 
energy to do the necessary work.

>5. In designing the XPathResult interface, it would be a good idea to
>anticipate the XPath 2.0 data model. In XPath 2.0, everything is a sequence;
>it is possible to return a single node, or a sequence of strings. This might
>suggest separating the notion of result type into two parts (a) is it a
>singleton or a sequence, (b) what type are the items?
>
I refer you to the resolution of XPath-28.

I do not believe that anticipating XPath 2.0 is useful at this point. 
 There are many things that would have to be redesigned and would no 
longer serve XPath 1.0 well due to incompatibilities between the models.

>6. Only two codes are defined for XPathException: invalid expression error,
>and type error. I couldn't find any definition of these codes. For example,
>which one should the (incorrect) expression "count(3)" return?
>
<<<beginning of quote>>>

    INVALID_EXPRESSION_ERR
        If the expression has a syntax error or otherwise is not a legal
        expression according to the rules of the specific XPathEvaluator
        <http://www.w3.org/TR/2002/WD-DOM-Level-3-XPath-20020328/xpath.html#XPathEvaluator>
        . If the XPathEvaluator
        <http://www.w3.org/TR/2002/WD-DOM-Level-3-XPath-20020328/xpath.html#XPathEvaluator>
        was obtained by casting the document, the expression must be
        XPath 1.0 with no special extension functions.

        Issue XPath-4:
            A separate exception should be raised if there are problems
            resolving namespaces.
            Resolution: Yes. These now raise DOMException with the code
        NAMESPACE_ERR.

    TYPE_ERR
    If the expression cannot be converted to return the specified type.

<<<end of quote>>>

To me, it is obvious from these descriptions that INVALID_EXPRESSION_ERR 
would be appropriate, because TYPE_ERR is described as only applicable 
if the expression could not be coerced to the desired type, whereas 
XPath 1.0, being statically typed, can easily determine that the 
expression is invalid (I do not dare guess on XPath 2.0, but 
fortunately, that is out of scope).  I could have missed something, though.

>7. The specification says nothing about the use of the XPath id() function.
>Does this mean it is always guaranteed to work?
>
The specification says nothing about the implementation of any XPath 
function.  We leave that to the XPath specification.  Is it guaranteed 
to work in the XPath specification?

>8. XPath says that it is the job of the host specification to define
>conformance rules. Where are the conformance rules? For example, is an
>implementation conformant if it extends the vocabulary of functions that can
>be called within an XPath expression?
>
In several places in the specification, it states that the 
XPathEvaluator, if obtained by casting the document, will have no 
specialized extension functions or variables (for example, in the error 
I just quoted).

If this is not sufficient, then perhaps you could suggest more clearly 
what is missing.

It is out of scope for the specification to determine these rules for 
XPathEvaluator interfaces obtained from other sources, because that must 
be specified by those other sources according to their needs.

Thanks for the feedback.  The above statements are my own personal 
analysis, designed to spur more dialog where you may disagree with me. 
 Naturally everything will be considered by the working group.

Ray Whitmer
rayw@netscape.com