Re:Namespace resolution in L3 Core and XPath (was Full infoset support for DOM 3 Core)

> This functionality is already expressed in Level 3 core in the Node
> interface.  By keeping the XPath version of the interface abstract, we
> permit applications to construct maps for cases where the namespace
> context is not based upon a Node in the hierarchy (although we do not
> have a create method for that type of object).  There are other
> differences, such as one you stumbled on:  XPath never requires the
> default namespace (and requiring XPathNamespaceResolver to supply it
> might make the implementer erroneously apply it to prefixless names
> within the expression).

Sorry, I hadn't looked at DOM L3 Core at the depth I looked at L3 XPath and
L3 Events.  Definitely there is a significant functional overlap between
Node.lookupNamespaceURI and XPathNSResolver.lookupNamespaceURI.  I would
think that it would be confusing if these two methods had slightly different
behavior.  I would recommend that XPathNSResolver.lookupNamespaceURI be
defined as behaving identically to Node.lookupNamespaceURI

If these methods are made optional (Issue lookupNamespaceURI-2), then it
most probably would be in a distinct interface that could make
XPathNSResolver redundant.  I definitely agree that XPath needs a namespace
resolver interface that is independent from Node.

Since null and "" are indistinguishable on some bindings, there needs to be
a clear description of the behavior with regard to default namespace.  For
example, if a return value of "" is supposed to indicate a match with the
default namespace, then it may be impossible to distinguish a match with the
default namespace and no match.  Probably the best approach is to declare
that "" should raise an exception as an argument to lookupNamespaceURI and
that a different mechanism be provided (such as a defaultNamespaceURI
attribute) to determine the default namespace.

Node.namespaceURI is pretty confusing, especially "This is not a computed
value..."  If a node is created by loading an XML document and namespace
processing was turned on, you would expect nodes to have a namespace URI
based on its prefix even if the namespace binding is defined on an ancestor
node which would require "computing" even though it would be handled
typically by the SAX layer underneath.  However saying its value is null if
the node was created by createElement or createElementNS(null,...) would
probably get make the point that you were trying to make.  "namespace URI of
this node" is also potentially confusing, since it might be interpreted as
the namespace URI of the qualified name of this node (and a complement to
localName) or as the default namespace.

Node.localName: The note on createElement and other nodes is inconsistent
with the behavior of XPath's local-name() which would return a local-name
for unqualified tag names.   I would say that localName returns the same
value as nodeName except for ELEMENT_NODE and ATTRIBUTE_NODE.
localName(doc.createElement("foo")) should return the same value as
localName(doc.createElementNS(null,"foo"))  Raising an exception or
returning null on localName(doc.createElement("myns:foo")) would be
appropriate.

DOMImplementation.hasFeature() doesn't mention "3.0" as a valid version.

Received on Thursday, 6 September 2001 19:22:13 UTC