xml-dev - Re: two little DOM2 questions...

[Ray Whitmer <ray@xmission.com>]

Stefan Haustein wrote:

> Hello,
>
> can anybody explain to me why in DOM2 both
>
>     public Attr setAttributeNodeNS(Attr newAttr);
> and
>     public Attr setAttributeNode(Attr newAttr);
>
> exist, but only one remove method
>
>     public Attr removeAttributeNode(Attr oldAttr);

Off the top of my head, I believe it is an omission.


> Also, the current DOM2 spec says that mixing
> simple and namespace-aware methods should be
> avoided and will result in unpredictable behavior.
>
> There are five methods in DOM2.Element that I
> would normally expect to default to the element
> namespace if available:
>
>  public String getAttribute(String name);
>  public void setAttribute(String name, String value);
>  public void removeAttribute(String name);
>  public Attr getAttributeNode(String name);
>  public NodeList getElementsByTagName(String name);
>
> What is the reason for leaving the semantics open to the
> implementation instead of reusing them as convenience
> methods?

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:

1.  If there are no nodes in your hierarchy which use namespaces (or level 1 names with
colons in them).

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.

But where a level 2 application starts freely modifying the tree, the simple model required
by the level 1 methods may be destroyed.  This is because the URI, rather than the optional
prefix, is used for the unique key.  If this were not the case, the addition of level 2
namespace functionality seems rather pointless to me.  There are a wide variety of
interesting situations including obvious and non-obvious cases -- not failures of the spec to
predict what will happen, but failure of the user to produce a desirable result if calls are
intermixed.  The namespace and non-namespace model are different enough that intermixing the
distinct models as though they were the same will cause unexpected collisions or match
failures.  Some cases work, others fail, and it may not be obvious to a user not steeped in
the model how the mixture caused the failure.  It is easier to point out that by sticking to
one set of methods or the other -- not intermixing -- you can get good desirable results.

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)