Re: [Element Traversal LC] access to element by index

Hopefully, not too late to bring some more 'Elements' (at least our 
opinion) to this thread and spec.

As some of you already know, we have brought JSR-280 [1] (parts of which 
is DOM related and refer to the ElementTraversal (draft) specification) 
to a Final Release back in October 2007.

This has been done in knowledge of (a) the status of that specification 
and (b) the risks that are thereby implied. JSR-280 contains therefore 
the necessary 'draft, may change & work-in-progress' statements. We are 
fully aware of that situation and are willing and prepared to 
change/deprecate/add APIs as they are being defined/decided by this WG 
for this specification even if our reference implementation of that JSR 
(among others) is right now being distributed to our licensees.

 From a technical and deployment point of view however, we like to 
emphasize the usefulness of the attribute 'childElementCount' with the 
same argument that was already given by others (1 pass versus 2 passes 
in particular use cases).

A few alternatives were proposed here, referred below as
    (i) 'attribute NodeList childElements',
   (ii) 'Node item(index)' and
  (iii) xpath .querySelector.

I personally like (iii) because it is powerful (or is it just queries 
that are powerful?), however it definitely belongs to another spec.

Alternative (i) has its advantages and disadvantages that were also 
theoretically mentioned in this thread. However, from our experience in 
the mobile space and in particular given our implementations (optimized 
SVG and 280-DOM, both for Java-ME), it would cost extra memory and code 
execution: the implementation would need to create an object with very 
short life span (an instance of NodeList). It should hurt the 
performance on two fronts: extra garbage collection and extra code 
execution. On the other hand, if Elements would cache the NodeList 
object it will inevitably affect RAM footprint.

Alternative (ii) is in about the same situation.

We understand that adding a NodeList to the ElementTraversal interface 
is particularly interesting for vendors who already are managing 
NodeLists in their implementation. Nevertheless, as a matter of fact, 
not all implementations follow this architectural decision and a 
NodeList then becomes a penalty.

Therefore we support the original specification [2] ... not only because 
of the obvious reason ... but also because of that obvious reason :-)


regards,
Jean-Yves

[1] JSR-280, XML API for JavaME,
http://www.jcp.org/en/jsr/detail?id=280

[2] ElementTraversal, 
http://www.w3.org/TR/2008/WD-ElementTraversal-20080303/


Doug Schepers wrote:
> 
> Hi, Bjoern-
> 
> Bjoern Hoehrmann wrote (on 4/3/08 6:30 PM):
>> * Simon Pieters wrote:
>>> The result of (2) probably also means that there's both 
>>> childElementCount  and childElements.length to do the same.
>>
>> If the SVG Working Group wants the count but not the NodeList, you end
>> up with that either way. This might be a good time to talk to them.
> 
> The SVG WG is not the only stakeholder that I'm trying to get feedback 
> from.  I will be posting my research and conclusions very soon.
> 
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG, CDF, and WebAPI
>

Received on Tuesday, 8 April 2008 14:52:44 UTC