Re: Element navigation additions

Why not simply make this new "tiny" API provide a specialized 
implementation of a TreeWalker 
(http://www.w3.org/TR/2000/REC-DOM-Level-2-Traversal-Range-20001113/traversal.html#TreeWalker) 
that will work consistently regardless of whether the underlying DOM 
contains text nodes or not. That way you wouldn't introduce new DOM 
attributes/methods that give you nothing that doesn't already exist, and 
in fact, what you're going for would be doable w/o any changes to the 
DOM, what so ever.

I personally don't think that extending the already heavy weight core 
element classes with yet more attributes/methods is a good idea, when it 
seems like it's completely avoidable.

Robin Berjon wrote:
> 
> Dear DOM IG,
> 
> 
> I am writing to you on behalf both of the SVG WG and the JSR-226 Experts 
> Group. As you may know, both our groups are working on a subset of the 
> DOM that would be suitable for implementation on devices supporting SVG 
> Tiny (1.1 and 1.2). The relevant documents can be found at:
> 
>   http://www.w3.org/TR/SVG12/svgudom.html
>   http://jcp.org/aboutJava/communityprocess/review/jsr226/index.html
> 
> One of the things we believe users must be able to do is to navigate 
> from an element into its children, as would appear natural. However, we 
> have a very strong constraint of minimising the number of interfaces, 
> and of only exposing the strict minimum functionality that needs to be.
> 
> As such, the only way of accessing textual content is through 
> textContent() -- there are no Text nodes, no more in fact than there are 
> CDATASection, ProcessingInstruction, Attr, etc nodes. We have Node, 
> Document, and Element.
> 
> We also have a strong constraint that content that works in SVG Tiny 
> must work in SVG Full, which uses the complete DOM.
> 
> Given the context, the following problem appears: on a Tiny device using 
> childNodes, hasChildNodes(), firstChild, lastChild, previousSibling, and 
> nextSibling will always contain Elements, and elements only. However, 
> the same program running inside a Full implementation will see many more 
> nodes of different types, and given the fact that it can safely expect 
> to only see Elements in Tiny it will very likely blow up badly in Full.
> 
> There are only three clean ways out of this quandary:
> 
>  - give up entirely on providing access to children. This was seriously
>    considered for a while, but it renders the API far less powerful, to
>    say the least;
>  - insert objects of type Node with no information available on them
>    where non-Element nodes would appear. Not only is the presence of
>    these objects totally useless from the point of view of API users, it
>    also incurs a performance hit that we consider to be intolerable;
>  - add a few fields to the Element interface that provide access to
>    Element children and siblings alone. That is the path we have chosen.
> 
> The additions to the interface are as follows:
> 
> 
>   interface Element {
>       ...
>       readonly attribute Element         firstElementChild;
>       readonly attribute Element         lastElementChild;
>       readonly attribute Element         nextElementSibling;
>       readonly attribute Element         previousElementSibling;
>       ...
>   };
> 
>   firstElementChild of type Element, readonly
>       The first element child of this element. If there is no such
>       element, this returns null.
>   lastElementChild of type Element, readonly
>       The last element child of this element. If there is no such
>       element, this returns null.
>   nextElementSibling of type Element, readonly
>       The element immediately following this element. If there is
>       no such element, this returns null.
>   previousElementSibling of type Element, readonly
>       The element immediately preceding this element. If there is
>       no such element, this returns null.
> 
> 
> These are the parts that the mobile subset would use, the full set would 
> also add childElements and hasChildElements() for consistency (perhaps 
> requiring an ElementList interface as well). By a chance side-effect,
> this addition also eliminates the infamous problem of users trying to
> access the first element child of an element using firstChild and
> getting a Text node of white space instead of what they expected.
> 
> I hear you saying "but why are you changing the DOM Core Element 
> interface when you have your own SVGElement interface with which you can 
> fudge to your heart's content without bothering us?" Well, quite simply 
> because SVG is intended to be a multinamespace environment, and these 
> fields would have to be present not only on SVG elements, but also on 
> elements from foreign namespaces present in the same document.
> 
> Now, we well understand that there is a problem: the DOM WG turned into 
> a pumpkin and DOM 3 Core went to Rec last week (many kudos by the way, 
> it is an excellent spec). Yes, both the SVG WG and the JSR-226 EG are 
> currently flagellating themselves for not having thought of this 
> previously, but that does nothing to fix the problem: it's very probably 
> impossible to change DOM 3 Core now, or to hope for a DOM 3.1 Core, yet 
> those fields need be on Element, or very close to it.
> 
> So here is what we propose: the SVG WG would take under its 
> responsibility to create a new Chapter in the DOM 3 spec-suite. That 
> chapter would be called "DOM 3 Element Navigation" (or something 
> similar) and would be available through the "ElementNavigation" feature. 
> Language-neutral DOMs would be able to get at it through the normal 
> feature/casting mechanism, and SVG implementations of the DOM would 
> mandate that all instances of Element support it "natively" (ie with no 
> form of casting).
> 
> Since the JSR is on a very tight schedule for the end of April, we would 
> appreciate comments you may have on this approach.
> 
> Thank you very much in advance,
> 

-- 
jst

Received on Wednesday, 14 April 2004 13:53:32 UTC