W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2000

Re: Namespace treatment, cloning and node.supports

From: james anderson <james.anderson@mecomnet.de>
Date: Mon, 06 Mar 2000 14:13:28 +0100
Message-ID: <38C3AEF1.9EBF2280@mecomnet.de>
To: "www-dom@w3.org" <www-dom@w3.org>

Dieter Köhler wrote:
> > Why? Having two attributes with the same qualifiedName on an element
> > only is a problem if you ever want to serialize your document.
> .. or if one wants to write a component which interacts with other
> people's components in handling DOM trees.  One does not know, whether
> the other peoples components use the old DOM1 methods for creating
> attributes or the new namespace methods.


This situation perplexes me. Isn't it the same as when one has a 3-D
geometry model and then is perturbed when some app is permitted to
insert 2-D elements into it? Either the model is prepared for this and
the 2-D instances comply to a 3-D interface, or one had better not
subsequently try to perform perspective transformations on the model.

Either your names (or your element and attribute nodes, should you so
insist) guarantee valid values returned to the respective name-related
methods when cross called, or the mixed-mode applications are not possible.

In the particular case of using a "namespace-aware" model instance
through a "non-namespace-aware" interface, it is possible to assure
statically unique qualified names by associating a unique canonical
prefix with each namespace at the point when it is first encountered.
This prefix may, or may not, agree with a "vanity" prefix, but, if the
namespace-aware names were valid in context, it is guaranteed sufficient
to generate (for caching if need be) a non-conflicting
"non-namespace-aware" qualified-name.

If there is a prospect of "non-namespace-aware qualifiedName conflict",
then the "nna" app will need to provide sufficient information for the
"na-model" to provide it with unambiguous results. It is possible to do
this statically. In which case the "qualifiedName conflict" is a
serialization artifact, or rather a consequence of conflating
serialization and DOM state.

If, on the other hand, one really is insisting on an implicit dynamic
mapping, so that, for example, one is insisting that the 2-D be able to
use a 2-D selection box to select components from the 3-D model
<em>without</em> having to provide and allow for the 3-D to 2-D
transform, then, well, you've got me stumped...
Received on Monday, 6 March 2000 08:07:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:36:45 UTC