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


From: Luca Padovani <padovani@scl.csd.uwo.ca>
Date: Fri, 19 Apr 2002 18:39:10 -0400 (EDT)
To: www-dom@w3.org
Message-ID: <Pine.LNX.4.21.0204191809430.2881-100000@arboretum.scl.csd.uwo.ca>


I've noticed some discussions about the getElementsByTagName[NS] method on
this list some time ago (may 2001), but it's not clear to me what is the
position of the WG to this respect. Is the method going to change name (or
to be split into getDescendants... getChildren...)? Does the WG feel that
the method is OK as it is now? Have I missed something in the level 3

Apart from performances considerations, it seems weird to me that a
general method like getElementsByTagNameNS is provided, where it can be
implemented by having something like getChildrenByTagNameNS which is
soo much simpler. What is therationale for having the former one?

Another thing related to that. Quoting an email from that period, about
the efficiency of an hypothetical getChildrenByTagNS versus iterating the
children NodeList and comparing explicitly namespaces and local names:

> the cost of looking for this themselves by walking the list of children
> is minor and there is little hope the implementation can do better. 

In DOM namespace comparison implies string comparison, which can be quite
inefficient if done for a large number of nodes, and given that namespaces
URIs are usually quite long. Thus, having a getChildrenByTagNameNS can be
faster than iterating thru all the children and comparing explicitly the
namespace, since the internal representation of namespace information
usually relies on some _unique_ structure and the namespace is represented
by the reference to such structure. Comparing pointers (internally =>
NodeList implementation) is certainly faster than comparing strings
(externally => user code).

Any comment to this would be greatly appreciated.


Received on Friday, 19 April 2002 18:39:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:10 UTC