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

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  

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 -
S60 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.


Received on Wednesday, 28 December 2005 07:11:48 UTC