- From: Joseph Kesselman <keshlam@us.ibm.com>
- Date: Tue, 17 Sep 2002 10:41:36 -0400
- To: www-dom@w3.org
On Tuesday, 09/17/2002 at 07:15 MST, rayw@netscape.com (Ray Whitmer)
wrote:
> I have been unable to make the concept of ownerElement work the same as
> XPath all the time, even if moved to Node. [... ]
> ownerElement appropriately returns an Element node, so it cannot return
> the same thing as XPath's parent axis in this case because the root is
> not an element, but is rather a Document.
Hmmm. We're now working around Attr nodes via
Node xpathParent=node.getParent();
if(xpathparent == null && node.getNodeType()==DOM.ATTRIBUTE_NODE)
xpathParent=((Attr)node).getOwnerElement();
and with this change that could be inverted to
Node xpathParent=node.getOwnerElement();
if(xpathparent == null)
xpathParent=node.getParent();
Slightly cleaner and probably slightly better performing. But still a
nuisance. Sigh.
An alternative would be to implement Node.getOwnerNode(), which for attrs
would yield the same value getOwnerElement() does now (but as a Node) and
for others would yield the new behavior -- ownerElement if exists, else
the parent (Document node if this is the root, null if it's an orphan
tree). But I was hoping to do this by a minor reshuffle rather than by
enlarging the DOM API; the latter's harder to get acceptance on.
Of course if we'd thought of this at the time we could have implemented
getOwnerNode() in the frst place. Hindsight is always 20/20...
______________________________________
Joe Kesselman / IBM Research
Received on Tuesday, 17 September 2002 10:42:15 UTC