Re: Use cases

On Thu, 18 May 2000, Tim Berners-Lee wrote:

> I'd like to look in more detail at the question as to whether any actual
> damage would occur were the NS spec to changed to require
> absolutizing for comparison. I contend that, because in fact that is
> consistent with URI behavior, it will not cause problems with existing
> documents in practice.

It causes damage because currently the namespace specification only calls
for character-by-character comparison.

To repeat myself (a bit more concisely and carefully I hope):

It is clear to me that the DOM spec would suffer quite a bit.

The current DOM level 2 namespace support has a complex time of trying 
to deal with two representations of namespaces -- the real name, and the 
prefix -- that have to be kept in sync.

It seems that the relative namespace is a third thing.

Which wins when they give different answers: the relative or the 
absolute name?

If relative, then the absolutization must be recomputed at least at
points of mutation, and nodes must be exported / imported into specific 
parts of the same hierarchy because their implementing classes may 
change.  Many other constants become variables if moving data in the 
hierarchy causes the type of the data to change.  For example, 
attributes which did not collide when the node lived in one part of the 
hierarchy may collide and be not NS-well-formed at another point in
the hierarchy because of the relative reinterpretation.  The DOM WG has 
had good reason to keep the name of a node constant up until now.

If absolute, then the relative specification becomes yet another
prefix that is affected by surrounding nodes and has to be coordinated 
at every point, and is likely to become inconsistent with the 
surrounding nodes and lost, if a sane fixup prevails.

If the parser is allowed to absolutize and forget, then we have
programmatically said, the user of the API should not be able to 
manipulate the relative URIs (a good choice, IMO, but then why did we 

These choices are similar to the choices that non-DOM systems will
have as well.  Applications which only read XML without mutating it
have the luxury of absolutizing and forgetting (DOM implementation
is always much simpler in a read-only case).  But I think other
applications have to decide what is the real intent of the document --
the absolutized representation or the possibly-relative specifications.

Many will likely absolutize-and-forget anyway, because to do the whole
relative path support under mutation is quite daunting (and to many, of 
questionable value).

Ray Whitmer

Received on Thursday, 18 May 2000 09:56:38 UTC