RE: [SVGMobile12] SVGT12-207: Conformance to uDOM

Ian,
The trait APIs were designed via a long coordination effort between the
SVG WG and the Java Community Process and the JSR-226 Expert Group. The
JSR-226 EG needed small footprint APIs from Java to manage SVG graphics
in order to serve the application development requirements of highly
constrained mobile devices and to provide typed access to attributes.
(As you know, Java is a strongly-typed language.) The JSR-226 EG said
that complete support for appropriate W3C DOM APIs would not fit on the
target devices and would not have adequate performance. The JSR-226 EG
developed their specs simultaneous with building a reference
implementation, which is part of the JCP process, so there was
continuous implementation feedback. 

The initial specs for JSR-226 defined APIs that prevented simultaneously
support for W3C DOM APIs and those early drafts of JSR-226. The long
coordination effort brought about significant changes to JSR-226 such
that it became possible to satisfy all constraints: the JSR-226's
committees requirements for small footprint implementations, typed
access, and efficient performance on the target devices; and the W3C
requirements that it is possible for a single implementaiton of SVG to
support both JSR-226 and the W3C APIs. The most significant changes to
JSR-226 from the coordination effort was to get the JSR-226 spec to
support relevant W3C APIs (such as DOM3 Core) instead of the conflicting
alternative APIs that had been originally proposed. These conflicting
alternative APIs would have prevented a single SVG implementation from
supporting both JSR-226 and the W3C DOM. It was a standards coordination
success that JSR-226 ended up like it did.

I definitely understand the points you are making below; however, the
W3C and the SVG WG will have to trade off the requirements of unified
HTML+SVG web browser implementers (which want to implement a single DOM
engine) and the requirements of other SVG workflows, such as JSR-226.

Here are some possibilities:

1) Embrace the uDOM universally across the whole CDF domain. This would
lead to defining HTML attributes and CSS properties as traits within a
future uDOM which supports multiple languages.

2) Treat the uDOM as an SVG-only thing and support it across all
versions of the SVG language (both Tiny and Full) and all language
bindings.

3) Treat the uDOM as an SVG+Java-only thing. Thus, it would only be
available via the Java language binding.

4) Treat the uDOM as a JCP-only thing. Thus, it would not be a
requirement for "SVG" as such but would be a requirement for integration
of SVG with mobile Java.

There are some *features* from the uDOM which make sense across the
whole CDF domain; however, maybe the uDOM isn't the best horse to ride
in order to deliver these features. My understanding is that ECMAScript
is adding strongly-typed data support, and Java always has had
strongly-typed data, so strongly-typed DOM access is good. The uDOM
provides access to the animated values for properties and attributes,
and it seems likely that the CDF activity will want to extend SVG's
ability to animate graphics with SMIL into the ability to animate
HTML+CSS content with SMIL. There are also extensibility possibilities
(<traitDef>) in conjunction with the uDOM which offer the ability to
define how SMIL might work with custom attributes on XBL-defined custom
elements. It's a tough call, especially given that JSR-226 devices are
already shipping and that it appears a large percentage of mobile
devices will be shipping JSR-226 support fairly soon.

Jon




-----Original Message-----
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf
Of Ian Hickson
Sent: Sunday, January 01, 2006 4:04 PM
To: www-svg@w3.org
Subject: Re: [SVGMobile12] SVGT12-207: Conformance to uDOM


On Wed, 28 Dec 2005, Ian Hickson wrote:
> 
> Please change the specification so that serious SVG implementations
can 
> implement the W3C DOM instead, and still claim conformance.
> 
> If there are parts of the SVG DOM that are not an incompatible subset
of 
> the W3C DOM, e.g. the parts of the SVG DOM such as SVGElement, please 
> define these in a separate appendix so that implementators can clearly

> distinguish the parts that they must implement vs the parts that are 
> redundant with the W3C DOM. In this case, please make such a split 
> publically available for review before progressing to CR, as this
would 
> be a significant change to the specification.

In addition, please make it clear that implementations that include full

DOM Level 3 Core and DOM Level 2 Style implementations do not have to 
implement the "trait" APIs, since they are redundant with the 
aforementioned specs.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 2 January 2006 16:20:29 UTC