- From: Robin Berjon <robin.berjon@expway.fr>
- Date: Wed, 14 Apr 2004 18:55:18 +0200
- 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 UTC