two little DOM2 questions...

[Ray Whitmer]

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 at xmission.com



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at 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 at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)