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

Maciej,
See inline comments below.

Jon


-----Original Message-----
From: Maciej Stachowiak [mailto:mjs@apple.com] 
Sent: Tuesday, January 03, 2006 2:40 PM
To: Jon Ferraiolo
Cc: Ian Hickson; www-svg@w3.org
Subject: 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.

JF: The SVG WG agrees that any conflicts with standard DOM need to be
fixed. Thanks for listing the incompatibilities. 

JF: In terms of fixing JSR-226, it is too late to fix the first shipping
version of that spec. It has already been approved and is shipping on
phones today. We will have to look at each incompatibility on a
case-by-case basis and figure out how best to reconcile any
incompatibilities. 

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

JF: The SVG WG agrees that the incompatibilities should be treated as a
separate issue from what to do about 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.

JF: Suppose the incompatibilities were fixed. Would you still vote for
#4? One thing I would point out is that the other major company involved
with your open source browser is Nokia, who is one of the prime
instigators of JSR-226. There might be workflows where KDE browser
codebase is used to deliver JSR-226 functionality.

JF: One more thing. During SVG WG discussion today and in various
comments expressed on this email list, people have pointed out that the
uDOM (including traits) offers features that are not available via the
W3C DOM, such as access to animated values, typed access to attribute
values (versus the W3C DOM, where everything is a string), and as a side
effect overcomes some scripting problems having to do with
locale-dependent representation of attribute values. (I don't remember
the details here, but I believe it has to do with commas vs. periods for
the decimal point.) There have been various testimonials from the SVG
content community that they like the uDOM (including traits).

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

JF: The CSS Object Model has three shortcomings: (a) Tiny 1.2 does not
support CSS at all. (And this Last Call is about Tiny 1.2.) (b) My
understanding is that the existing CSS Object Model is considered a
deprecated feature which will be replaced at some unspecified point in
the future. (c) The CSS OM only applies to properties and doesn't cover
attributes, such as 'x', 'y', 'width' and 'height', which are common
targets for scripting and animation.

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

JF: The trait features in SVG would be considered language-specific DOM
APIs for alternative (2), (3) and (4) above.

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.

JF: The SVG WG is looking forward to your comments on the trait APIs.
Note that the trait APIs are a key part of JSR-226. Although this isn't
the only factor to consider, I will point out that fundamental changes
to the trait APIs are likely to get a poor reception from the folks at
the JCP.

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

JF: I can't comment about the incompatibilities quite yet because I need
to study the details, but I have a hard time seeing how an
implementation could support both the uDOM and the W3C DOM
simultaneously as distinct facilities. If you had an event and an
implementation that supported both the uDOM and the W3C DOM, would it
get dispatched to the uDOM or the W3C DOM? It seems much better to
attempt to eliminate the incompatbilities so that a unified
implementation which supported both were possible.

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 23:30:44 UTC