Re: Namespace treatment, cloning and node.supports

"Dieter Köhler" wrote:
> 
> The DOM has to specify what to do in such cases:  Raise an exception
> or replace attribute a by attribute b, but not admitt both attributes
> as attributes of the same element.

Why? Having two attributes with the same qualifiedName on an element
only is a problem if you ever want to serialize your document.
I agree you eventually need to be able to fix your document to be able
to serialize it but why does this have to be done while you're
creating/editing it? As it is well known, editing a document often
requires passing by incorrect states. Just like it is true for
validation with regard to a DTD. The DOM doesn't prevent you from
inserting an element where it can't be, according to the governing DTD.
The problem you're mentioning is not really different to me.

> If you I stick with XML conformance (and namespaces at all being
> *semantic* sugar relative to XML, though of course it has itself a
> syntax)

I only talked about _syntatic_ sugar while referring to namespace
_prefixes_. And, given the impact of namespaces all over the place I
have a hard time referring to namespaces in just some kind of "sugar".
;-)

> it is a real advantage not to have to bother with syntactic
> malformed DOM trees.  In an OO view:  If I write a component for doing
> something with a DOM tree, e.g. outputting it as an XML document as
> mentioned above, with the present version of DOM2 my component cannot
> rely on getting wellformed elements -- and this is a real big
> disadvantage.

The only disadvantage is that it pushes the burden of fixing namespace
prefixes to whoever wants to serialize the document. In an OO view, this
would only be done in one place though. And, since the DOM doesn't fix
namespace declarations, the serializer has to do some fixup anyway.
Fixing up prefixes at the same time isn't much of an additional burden.
As opposed to have every possible module/object bother with figuring out
unique prefixes...

> BTW: Why is the attributes attribute defined in the nodes interface
> and not in the element interface?  No other node type makes use of it.

So that you can do everything without having to cast your Node. Casting
can be fairly expensive in some environment, such as COM or CORBA.
-- 
Arnaud  Le Hors - IBM Cupertino, XML Technology Group

Received on Thursday, 2 March 2000 13:10:48 UTC