Re: Element navigation additions

On Apr 14, 2004, at 11:27 AM, 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.

A similar situation has occurred with script initially developed on 
implementations that eliminate element content whitespace.  When that 
script is migrated to an implementation that did not eliminate element 
content whitespace, bad things happened.  However, it was possible to 
write the code in such a way that it could run on either.  Also, there 
is probably a decent amount of script out there that did not anticipate 
comments in the documents.

Ideally, any SVG Tiny script that also wanted to work on full SVG would 
check that Node.nodeType == ELEMENT_NODE before assuming a child node 
represented an element.

>
> 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.
>

I'd take exception to the second point, particularly about the 
"performance hit".

Processing instructions, comments, and whitespace in element content 
aren't significant could be assumed to be discarded on input.  However, 
it should be possible to represent text content as Nodes, when 
requested, without a significant performance penalty.   The 
implementation of elements that are expected to contain text content 
can store the text as a String member and only construct a "text" node 
only on demand (for example, Node.firstChild on the parent).  There 
would be an little extra footprint to add the supporting class, but 
that should be small even compared to SVG Tiny.  There should be some 
constraints added to Node.appendChild, Node.removeChild (if they exist 
in Tiny DOM) so that attempts add a text node to an element with 
element content or to modify an element's text content by manipulating 
its Text child would throw an exception (possibly 
HIERARCHY_REQUEST_ERR).

Received on Wednesday, 14 April 2004 17:11:24 UTC