Re: Resolution of XPath DOM LC issue B5

On Thursday, 09/05/2002 at 12:45 MST, rayw@netscape.com (Ray Whitmer) 
wrote:
> I do not recall such a discussion.

If I'm not dreaming, this was brought up fairly early in DOM L3 
discussions as a "did we miss an obvious opportunity by being 
overspecific" question. Feel free to blame me for the fact that it isn't 
in the Open Issues List. Or someone may have come up with a killer 
objection -- but I honestly don't remember hearing one. (Might be time to 
check the archives/minutes for past discussion; searching for ownerElement 
ought to find it...)


>  This would be a core issue.

Granted, but it would be intended to ease XPath/XSLT/XQuery 
implementation.

> In practice, it doesn't seem to me to be a big hassle anyway

It isn't _big_. But it also isn't hard, and it would help address the 
ongoing accusations I hear that the W3C seems to be scattering away from 
the Infoset rather than finding ways to come back to it. Call it a 
convenience function if you like, but one which does permit some 
optimization of that operation... which is a category the DOM has been 
willing to consider in the past.

> most
> normal applications know if they have an attribute node to start with
> before asking for the parent or owner element

As you said: Most. Some don't. XPath is an example of one that may not, 
except by explicitly testing the node type. Yes, they can do so. Is there 
a Good Reason we shouldn't reduce the need to do so?

> In DOM, there are additional cases, such as attributes which have text
> nodes underneath them.

Remember that I suggested only generalizing ownerElement. If that's 
defined as "move up to the nearest enclosing element", it works fine for 
XPath and may be useful for others. That would also address the case of a 
Text node within an EntityReference within an Element -- skipping the 
EntRef and going to the Element would match XPath's desired behavior. (And 
illustrates another place where this convenience would add value.)

> The parent of the text node is clearly the attribute

Not in the XPath view. There, attrs don't have children; they carry text 
directly. Hence, in that environment going from the text (which is "part 
of the attr") to the Element is entirely reasonable.

Again, remember that I specifically suggested moving getOwnerElement back 
to Node. That's a clearly defined behavior. 

If it isn't one _you_ want to use in your apps, that's fine... but I think 
it really would be a step back toward making these two views of the 
Infoset consistant, and thus is a Good Thing for the W3C architecturally. 
It doesn't address the terminology problem, but at least it provides a 
very direct mapping.

> of thing is that they think that the parent attribute of an attribute
> should be the element,

I'm trying to take us a step away from arguing about the use of the 
specific term "parent" -- which is now unchangable, as are some of our own 
past mistakes -- and focus on functionality, as I now wish we had when 
this issue first came up. (Hindsight is always 20:20...)

If they can say "what we call parent, the DOM calls ownerElement" for all 
of their nodes, the fact that they use a different term for the same 
concept is annoying but reduced to the level of a documentation problem 
rather than persisting as a genuine architectural divergence.

> Perhaps if it solved more problems...  entity reference skipping seems
> like another side benefit.

Sorry; that was my intent, as mentioned above. I should have stated that 
more explicitly.

> The root node would have to have no owner element

Agreed.

 ______________________________________
Joe Kesselman  / IBM Research

Received on Thursday, 5 September 2002 17:42:13 UTC