Re: Namespace treatment, cloning and node.supports

keshlam@us.ibm.com wrote:
> 
> >? Or could it be that the DOM constrains one to always manage consistent
> >namespace nodes simultaneous with tree mutations? please tell me it
> >isn't so.
> 
> The DOM is always internally consistant, since each node carries its own
> namespace URI.

There is a peculiar asymmetry in the way the DOM models namespaces. It
is said, for example, that a given element node (as any node) is bound
to a namespace. This although it is not the node which stands in a
relation to a namespace, but the node's name. Why was it deemed
necessary to close this transitive relation in the model? The asymmetry
becomes apparent when one looks to answer the question ? in what way is
the element node "bound" to the namespaces "of" its attributes? In the
serial form these are symmetrical; in the DOM they are not. Why is this?

That this relation is closed in the model, and in an asymmetrical
fashion, is one reason the questions of consistency and the
serialization difficulties arise. Were the model to stick closer to what
the serialized data actually says, that is if the namespace information
were recorded in the names and not in the nodes, then serialization
would be direct, there would be no departure from "canonical form", and
no "normalization" would be necessary.
 
> It may or may not contain all the namespace declaration
> attributes in the right places, or have the prefixes matched up properly if
> those declarations do exist.
> 
> The DOM is being allowed to depart from canonical form, just a bit, in part
> because we were concerned that continuously enforcing those restrictions
> could impose a significant amount of overhead. But it should contain all
> the data needed to allow us to reconcile those departures.

So long as the respective names entail the uri and the local part, then
the model contains sufficient information. Any "namespace" attributes
are superfluous. They could well be trashed upon element modification
and generated (with caching if so desired) as requested.

> 
> If you think about this as a namespace_normalize() operation, it may make
> more sense.

Why normalize? ever?

>     In Level 2, that normalization task is left as an exercise for
> the reader,

poor soul...

> but Level 3 is expected to provide a standardized version.
>

Received on Friday, 3 March 2000 12:48:29 UTC