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

Undefined XML DOM Level 2 core 'Element.getAttribute' Behaviour

From: Gerald Huck <huck@ipsi.fhg.de>
Date: Fri, 8 Feb 2002 09:31:00 -0500 (EST)
To: <www-dom@w3.org>
Message-ID: <JCEEKCICONKKDCPJIGCFKEECCEAA.huck@ipsi.fhg.de>
Hi,

I could not deduce from the DOM level 2 specs which Attribute/Value to
return from Element.getAttribute(name)/Element.getAttributeNode(name),
when setting attributes via setAttribute and setAttributeNS as follows
(Code in Java syntax):

1 Element e = aDocument.createElement("foo");
2 Attr   a1 = aDocument.createAttribute("foo:bar");
3 Attr   a2 = aDocument.createAttributeNS("http://www.w3.org/DOM2/bugs",
"foo:bar");
4 a1.setValue("value1");
5 a2.setValue("value2");
-- no problem so far
6 e.setAttributeNode(a1);
-- no problem: add a1 to e
7 e.setAttributeNodeNS(a2);
-- OOPS, no problem, too, when following the spec. for setAttributeNodeNS:
-- a1.getPRefix(), a1.getLocalName() AND a1.getNamespaceURI() all return
null =>
-- it is safe to add a2.
-- AMBIGOUS STATE: NOW EXIST 2 ATTRIBUTES IN e WITH THE SAME NAME/NODENAME
"foo:bar"
8 e.getAttribute("foo:bar");
-- So please, what should i return here: "value1" or "value2" ???
-- Naturally, the same problem appears for a bulk of related methods, like
-- calling e.setAttribute("foo:bar",...) again,
e.getAttributeNode("foo:bar"), ...
-- and what about serialization :-(

Note that this behavior is not even commutative (adding first a2, then a1
works!):
6' e.setAttributeNode(a2);
-- no problem: add a2 to e
7' e.setAttributeNodeNS(a1);
-- no problem: a1 replaces a2 as it has the same nodeName
8' e.getAttribute("foo:bar");
-- no ambiguity - relates to a1

I know, that it is 'BAD CODING STYLE' to do such things -
I am implementing the DOM spec, and i am not writing such code,
but i have to react appropriately when such scenarios appear.

The following are possible approaches to clarify this issue:
1. The behavior is up to the implementation (bad idea)
2. Elements raise NOT_SUPPORTED_ERR exceptions if they encounter
   'incompatible' attribute types between existing attributes
   and new ones (not very transparent).
3. documents are 'created' in a namespace aware mode or not,
   raising NOT_SUPPORTED_ERR exceptions if a method is applied
   that does not conform to the namespace mode (good, but requires DOM API
   changes).
4. Semantics of attributeNS setters is changed:
   'If an attribute with that local name and that namespace URI or
    with local name==null and namespace URI==null and same node name
    is already present in the element, it is replaced by the new one.'
   This would be 'compatible' to the behavior of simple non attributeNS
   setters, and 'preserve' replacements semantics in both cases.

Gerald Huck
Received on Friday, 8 February 2002 11:29:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:55 GMT