W3C home > Mailing lists > Public > public-webapi@w3.org > April 2006

Re: Any update on telcon times?

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Mon, 24 Apr 2006 22:19:09 +0200
To: Robin Berjon <robin.berjon@expway.fr>
Cc: Web APIs WG <public-webapi@w3.org>
Message-ID: <hb7q425mot0kt1eg771t97s2t3grjrl8q2@hive.bjoern.hoehrmann.de>

* Robin Berjon wrote:
>I don't think it needs to go into D3C. I am not too fond of adding  
>ever more convenience methods to the DOM, but this one is very  
>convenient as well as adapted to constrained devices (where  
>performance also matters). It also helps kill what is possibly the  
>number one user error when navigating the DOM, which to  
>consider .firstChild, .nextSibling, etc. to be elements.

The great thing about .firstChild, .nextSibling, and so on is that they
work absolutely everywhere, in particular in script-enabled SVG viewers.
Well, except Tiny 1.2 implementations where they may or may not work. So
if you use them, your content is unlikely to work there, and if you use
ElementTraversal instead, your content is unlikely to work anywhere else
unless you include a second code path everywhere so you use both. This,
in addition to the confusion caused, makes this design highly expensive.

ElementTraversal exists virtually nowhere. In contrast, selectSingleNode
is very widely available and known, whether you code with MSXML, .NET,
Xalan, Flash, IE's XMLHttpRequest, Perl's XML::DOM::Lite, JDOM, dom4j,
and so on and on, it's there. It is likely to be standardized and added
to more implementations in the future, it is a highly flexible and easy
to use, and there are more hits for it on groups.google.com than for all
the simple tree navigation methods together, or getElementsByTagName.

It seems unlikely that implementations where neither the DOM Core tra-
versal methods nor selectSingleNode work but ElementTraversal does would
persist for a considerable timeframe, even on mobile devices one of the
facilities is readily available, OMA's ECMAScript Mobile Profile has
firstChild and its kind, and so does Flash Lite, for example.

If the goal is to have less differences between the many XML environ-
ments, inventing entirely new features instead of subsetting fairly
ubiquitous features is clearly not a good approach, both designs pro-
vide the exact same functionality in a similar way and with similar
resource requirements, that one design "rocks" more, matters about as
much as people "love" it or how "nice" it is, there are many better
arguments you could cite against a selectSingleNode based design.

That said, I don't feel particularily strongly about ElementTraversal,
but it should be clear in this discussion that this is more about SVG
Tiny 1.2 having highly SVG Tiny 1.2-specific means to address core use
cases rather than adding a bit convenience to the Core DOM.
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Monday, 24 April 2006 20:19:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:21 UTC