Re: SVGT 1.2: Need for uDOM as a DOM subset is poorly justified

Hi Maciej,
Thanks for your comment [1]. This email is the response from the 
Working Group to that comment, which is copied here below.

While the Working Group understands and to a large degree shares 
your insights and concerns. We feel that the uDOM meets the goals 
set out for SVG Tiny 1.2 in the best possible manner. There is 
strong support for the uDOM not only from the group but also from 
the community. The uDOM has been in commercial use on various 
mobile devices as part of the JSR-226 APIs since before you 
submitted your comment. There is a requirement on the SVGT1.2 
specification that it must keep compatibility with JSR-226. This 
makes it impossible to replace parts of the uDOM with DOM 2, or 
even reference DOM 2 or DOM 3 outright.

During the time since your comment the WG has incorporated further 
feed back on improvements to the uDOM specification. Wherever 
possible the uDOM has not only be aligned but also deferred to the 
DOM 3 specification to ensure compatibility and extensibility.

Please accept this as the response to your comment. If you find 
this does not address your comment please let us know directly.

Best regards
Andrew Sledd  on behalf of the SVG WG

[1] http://lists.w3.org/Archives/Public/www-svg/2005Dec/0231.html

------------------------------

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 27 Dec 2005 22:26:13 -0700
Subject: SVGT 1.2: Need for uDOM as a DOM subset is poorly justified
To: www-svg@w3c.org

The introduction to the uDOM says:

"During the later stages of the SVG Mobile 1.1 specification it  
became obvious that there was a requirement to subset the SVG and XML  
DOM in order to reduce the burden on implementations. SVGT 1.2 adds  
new features to the uDOM, allowing for as much necessary  
functionality as possible, still being suitable for SVG Tiny  
implementations.

Furthermore, it should be possible to implement the uDOM on devices  
that support SVG Tiny 1.1 although, in this case, the scripting would  
be external to the SVG document
(since SVG Tiny 1.1 does not support inline scripting).

The goal of the uDOM definition is to provide an API that allows  
access to initial and computed attribute and property values, to  
reduce the number of interfaces, to reduce run-time memory footprint  
using necessary features of the core XML DOM, as well as the most  
useful SVG features (such as transformation matrices)."

However, there is proof that it is practical to provide full core DOM  
implementations on a mobile device, as this has been done in mobile  
device web browsers which provide full-featured DOM, CSS and HTML. I  
know of at least the following:

Opera Mobile - http://www.opera.com/products/mobile/
S60 Browser - http://www.s60.com/browser

While these mostly target higher-end mobile devices, it seems clear  
that more and more devices will be sufficiently capable in the future.

SVG Tiny 1.2 already has a variant that allows not implementing the  
DOM at all. Is there any evidence for a large class of devices where  
it is practical to implement the uDOM but not the DOM? Is it really  
plausible that devices could implement the animation, audio and video  
portions of the spec but not the DOM?

I think the spec needs to either justify this much better or replace  
the core DOM parts of the uDOM with the DOM. DOM Level 2 Core + DOM  
Level 2 Events should be sufficient.

Regards,
Maciej

Received on Tuesday, 18 July 2006 11:25:56 UTC