- From: <keshlam@us.ibm.com>
- Date: Fri, 24 Mar 2000 15:47:50 -0500
- To: kboone@ebt.com
- cc: www-dom@w3.org
kboone wrote, on the public list:
> Assuming the following Java statements are executed:
>
> attr.setValue("foo");
> element.setAttributeNodeNS(attr);
> element.setAttributeNS(attr.getNamespaceURI(), attr.getName(),
> "bar");
>
> What will be returned by attr.getValue()?
If I'm reading this correctly, this has some serious concerns.
He didn't say how the attr node was created. Two scenarios:
1) createAttribute -- prefix/localname/namespaceURI are all null.
2) createAttributeNS -- attr has the localname and namespaceURI specified
It may have a prefix.
When we issue setAttributeNodeNS, this Attr replaces any existing Attr with
the same {nsuri}localname. Problem: If it's a non-namespaced Attr, that
means it replaces a non-namespaced Attr but we don't know which, since they
all have null for both values. The results are implementation dependent.
Ugh.
When we issue setAttributeNS()... As written, the line doesn't work; he
probably intended to use getLocalName().
But if it's a non-namespaced node, this still results in our setting the
value for {null}null, which matches any single non-namespaced Attr on this
element. And again, the results are implementation dependent.
Ugh ugh.
Is my analysis in error?
If so, do we still believe this is an acceptable answer?
Note that if we had gone with localname=nodename for non-namespaced nodes,
this particular scenario wouldn't arise; the NS methods would be replacing
{null}localname, and everything would work correctly.
______________________________________
Joe Kesselman / IBM Research
Received on Friday, 24 March 2000 15:48:46 UTC