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

Element navigation additions

From: Robin Berjon <robin.berjon@expway.fr>
Date: Wed, 14 Apr 2004 18:27:56 +0200
Message-ID: <407D668C.7000707@expway.fr>
To: www-dom@w3.org

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,

-- 
Robin Berjon
Received on Wednesday, 14 April 2004 12:28:30 GMT

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