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
