Re: Element navigation additions

Joseph,

Joseph Kesselman wrote:
> When XPath ran into similar issues -- specifically, when they wanted to
> consider an element the parent of its attributes, despite their not being
> children -- the DOM's response was that, while we were willing to given
> them an ownerElement attribute on Attrs so this navigation was possible, we
> were not willing to accept and implement their definition of parent; it was
> their responsibility to write their implementation of XPath's parent
> operation so that when run over a DOM it Did The Right Thing.

I believe that this is a different kind of issue though. Given 
ownerElement one has all it takes to do XPath's parent axis right. 
Without the chapter/addition we propose, one cannot produce a useful 
Mobile DOM subset for the devices we are targeting.

> Frankly, I think the response to SVG's request should be similar. There's
> nothing wrong with a firstNonTextChild operation being provided by the SVG
> abstract data model. But I don't see any strong reason it has to be a
> property of the DOM Node, rather than an operation provided by SVG which
> may be applied to a DOM Node.

We are not investigating /direct/ additions to dom::Element -- as I've 
said that is unfortunately impossible at this time -- but rather a new 
chapter in the DOM suite (and the ability to file this under org.w3.dom).

Having an SVG-specific method does nothing at all to solve the issue of 
a Mobile DOM subset applicable to multinamespace documents. Despite this 
work being undertaken by the SVG WG, that is what we need.

-- 
Robin Berjon

Received on Wednesday, 14 April 2004 12:55:54 UTC