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

On Jan 2, 2006, at 8:21 AM, Jon Ferraiolo wrote:

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

Is the SVG Tiny 1.2 uDOM the result of this JSR-226 process? Because  
if so, I don't think it was as successful as you say, since the uDOM  
as currently specced in SVG Tiny 1.2 has conflicts with standard DOM  
that make it impossible to implement both at once. Please see my  
specific last call comments indicating some of these. I'm not sure if  
there is still time to update JSR-226 appropriately.

These active incompatibilities are separate from the areas of  
overlapping functionality like traits.

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

I think #4 may be the best option here. Category #4 is the only area  
where interoperability with the web at large is not an issue,  
therefore compatibility with the DOM and overlap of standard DOM  
features are not at issue.

> 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 typical DOM mechanisms for accessing the same sort of things as  
traits are threefold:

1) getAttribute family of calls for getting arbitrary attributes as  
strings in a uniform way
2) CSS Object Model (including getComputedStyle) for typed access to  
CSS properties, including ability to update them.
3) Element- and language-specific DOM APIs like the HTML DOM and the  
SVG DOM which provide typed access to particular values of interest,  
some of which may reflect parsed values of attributes

Traits provide a mix of the features of these. I think expanding  
categories 2 and 3 is the best way to provide APIs that require less  
string manipulation. But I'll write up a separate comment on the  
traits API since there are many specific things to be said about it.

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

If what they implement has the same incompatibilities with standard  
DOM (I am talking here about hard incompatibilities like lack of  
capture or the different behavior of some methods) then I think uDOM  
will have to be defined as completely separate from the DOM and it  
should be allowed for UAs to provide the actual DOM instead.

Regards,
Maciej

>
> 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 Tuesday, 3 January 2006 22:39:57 UTC