Re: Namespace treatment, cloning and node.supports

> (1) In my opinion the prefix attribute of the node interface should be
> readonly in DOM2

We've adopted the position stated by the namespace working group, that the
prefix is only syntactic sugar and the namespace URI is the "real"
information. The prefix is retained primarily as a hint to serialization
routines, and is mutable because you may want to hint differently.

Note that if no namespace URI is provided -- if it's a non-namespaced node
-- trying to change the prefix will throw an exception, since in that case
changing it would lose real information. That behavior supports
backward-compatability of Level 2 DOMs with Level 1 applications.


> (2) §1.1.7.Note reads: "... using setAttributeNS, one can set on an
> element two attributes (or more) that have the same nodeName ..."
> That would lead to a violation of the XML conformance of the document,

This was a deliberate design decision. There are folks who want to generate
a DOM with only localnames and URIs, and assign prefixes as necessary
during serialization. If we didn't allow qualified names to collide, they
couldn't do so.

Yes, this assumes a namespace-aware serializer, or a fixup pass before
serialization. Your old DOM Level 1 serialization code may not handle a
namespaced document correctly by itself.

We do prevent the assignment of two attributes with the same localname/URI
pair, of course, since those really are "the same attribute".

Standardized serialization, and additional well-formedness tests (including
namespace well-formedness), have been deferred to DOM Level 3.


> (3) node.cloneNode: Cloning an unspecified attribute node should
> return a specified attribute node, shouldn't it?

Yes. That should probably be documented. Good catch.


> (4) node.supports: Since this is very similar to
> DOMImplementation.hasfeature, why not use the same word?

This call tests whether the specific node supports the feature, and we
didn't want folks confusing it with the more general issue of whether the
implementation as a whole supports that feature. (If the two always agreed,
we wouldn't need both...) I suppose we could have called it
thisNodeHasFeature, or something like that.



______________________________________
Joe Kesselman  / IBM Research

Received on Tuesday, 29 February 2000 11:59:16 UTC