- From: james anderson <james.anderson@mecomnet.de>
- Date: Mon, 06 Mar 2000 14:13:28 +0100
- 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