- From: Ray Whitmer <rayw@netscape.com>
- Date: Tue, 17 Sep 2002 04:36:27 -0700
- To: www-dom@w3.org
Perry Caro wrote:
>Here's what I believe the answers should be:
>
>An ordered snapshot of length 3:
>
>Result[0] = XPathNamespace { // Note: omitted attributes are null or false
> nodeName: "xml"
> nodeType: 13
> ownerDocument: (Document node)
> namespaceURI: "http://www.w3.org/XML/1998/namespace"
> prefix: "xml"
>}
>
>
Correct.
>Result[1] = XPathNamespace { // Note: omitted attributes are null or false
> nodeName: "xmlns"
> nodeType: 13
> ownerDocument: (Document node)
> namespaceURI: "http://www.w3.org/2000/xmlns/"
> prefix: "xmlns"
>}
>
>
No. This does not appear in the XPath or DOM model or in the infoset.
>Result[2] = XPathNamespace { // Note: omitted attributes are null or false
> nodeName: "" // i.e., empty string, NOT null
> nodeType: 13
> ownerDocument: (Document node)
> namespaceURI: "default/"
> prefix: "" // i.e., empty string, NOT null
>}
>
>
I believe nodeName should be null in this case. The namespaceURI is a
deprecated relative URI, so the value of namespaceURI is unpredictable,
at best. but they may be treated literally as you have shown here.
>=========================
>
>Things I'm not completely sure about:
>
>* Should the special-case namespace nodes always be in scope?
>
>
Yes. But not xmlns. Only xml. The rule here is whatever the XPath
specification says.
>* Should the "xml:" special-case be included, and if so, should
>its order be before xmlns:?
>
>
xmlns is never included. The order of these is implementation-dependent.
>* For xmlns="default/", should the nodeName and prefix be empty string, or
>null? I'm assuming empty, because I can find no reference in any DOM Core
>spec that permits nodeName to be null, and I'm told that anything not
>expressly permitted in the spec is forbidden.
>
This is a case that we did not specifically consider when creating the API.
It is obvious to me that prefix should be null in this case, as it is in
other similar cases in the specification. This should be made clear in
the specification. We did not think of the default namespace when
creating that part of the API.
I agree that it is a problem with nodeName being null because we have
never said it may be null except by implication that it must match the
others. I am not sure what to do in this case. I will have to think
about that. Perhaps we need to reconsider the decision to make nodeName
match prefix, because it is unnecessary and may be confusing, as we now
see. Another alternative would to have the value of nodeName be
something like "#namespace", as it is #text for text, etc.
By the way, are you implementing this? If so, in what language, if I
may ask.
Ray Whitmer
rayw@netscape.com
Received on Tuesday, 17 September 2002 07:37:00 UTC