[
Lists Home |
Date Index |
Thread Index
]
- From: Ray Whitmer <ray@xmission.com>
- To: haustein@ls8.cs.uni-dortmund.de
- Date: Fri, 07 Jan 2000 06:38:28 -0700
Stefan Haustein wrote:
> Ray Whitmer wrote:
> >
> > Perhaps the word "unpredictable" might be replaced with "suprising" or "undesirable".
> >
> > Level 1 methods preserve level 1 behavior, including where colon may be used as a
> > non-namespace-delimiting character. Intermixing level 1 methods with level 2 methods can
> > produce quite unexpected results, which are nonetheless strictly predictable from the spec, I
> > believe.
> >
> > There are some simple cases where I believe intermixing does work, including:
> >
> > 2. If a level 2 parser produces a level 2 DOM hierarchy, always setting the prefixes in
> > addition to the namespaceURIs, which is then exclusively traversed and manipulated by a level
> > 1 application.
> >
>
> Are you sure? As far as I know, prefixes can have different
> bindings at different levels in the hierarchy, manipulating
> the tree may result in invalid prefixes in DOM1 and DOM2.
> In DOM2 you have a chance to "repair" the prefixes while
> writing out the tree since I know the namespace URI....
Perhaps I have not comprehended exactly what you are asking "Are you sure?" about.
I believe that a level 2 parser operating on a level 2 DOM implementation can easily produce a
tree that a pure level 1 application or a pure level 2 application will find equally satisfying,
as long as each one sticks to the appropriate set of methods -- NS for level 2 and non-NS for
level 1.
The level 1 methods called by the application generally ignore everything but the local name,
which the level 2 parser has correctly produced in the level 2 DOM. Level 1 mutation methods will
continue to preserve consistency with respect to this.
The level 2 methods called by the application generally ignore everything but the namespaceURI and
the local name, which, again, the level 2 parser has correctly produced in the level 2 DOM. Level
2 mutation methods will continue to preserve consistency with respect to this.
> The methods I was talking about were mainly attribute access
> methods. What I would expect is that they use the elment
> namespace as a default. In a plain DOM1 situation, the
> element has no namespace, and DOM1 behavior is preserved.
>
> But in the current specification this is not fixed. Thus,
> the DOM1 read methods will work in most cases, but will
> deliver unpredictable results when I have two attributes
> with the same local name but different namespaces. That
> seems very dangerous to me.
Level 1 methods do not look at the local name or the namespace URI. They look at the nodename,
which in the case of a level 2 node consists of the prefix and the localname. This will have been
correctly set up by the level 2 parser.
The parser is the one application that can easily set the hierarchy up so that it is consistent
from both a level 1 and a level 2 perspective.
Level 2 calls which further modify the nodes looking only at namespaceURI + localname for
uniqueness can easily mess it up for a level 1 application. And the other way around, level 1
calls which modify nodes only looking at the nodename (prefix + localname) for uniqueness can
easily mess it up for level 2 methods.
This means that it is only "dangerous" if you intermix level 1 and level 2 NS calls after the
parser. You have to pick your model and live with it. Otherwise, I believe it is not possible to
preserve level 1 compatibility while avoiding all conflicts between the models. One model has to
win, and given compatibility requirements, that model will be the level 1 model ruling out a level
2 model where namespaceURI + localname is the unique key.
Ray Whitmer
ray@xmission.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
|