W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2004

Re: Element navigation additions

From: Robin Berjon <robin.berjon@expway.fr>
Date: Wed, 14 Apr 2004 18:55:18 +0200
Message-ID: <407D6CF6.1070807@expway.fr>
To: Joseph Kesselman <keshlam@us.ibm.com>
Cc: www-dom@w3.org

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 GMT

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