Re: Using templates instead of script to render custom content

Hi Cameron,

> Arguments for the use of declarative templates as opposed to script for
> the implementation of RCC include:
>
>   - XSLT is a proven XML transformation language.

Indeed. However, I would add it has been especially proven in a 
different context, more oriented around batch-process, run-once 
transformations, just to make things clearer. I like XSLT, I'm just not 
used to it being used in dynamic environments and I'm not sure it's 
that that proven in that context.

>   - animation could be specified on attributes of custom elements and
>     the "right thing" would happen.

That's interesting. This is a problem I have been thinking about for a 
while in the RCC context and it's not easy to solve. The SMIL Animation 
specification does not specify a way to interact with a SMIL engine and 
feed it information on what a custom attribute's data type is and how 
it should behave during an animation. In fact, you can't even tell a 
SMIL engine what attributes can or cannot be animated. This all has to 
be hard-coded in a host engine, as in an SVG implementation in 
conformance with the SVG implementation which says what is and what 
isn't animatable. Say I have this SVG fragmentt:

<ui:button width="200">
   <animate attributeName="width" by="50" dur="1s" begin="mousedown" 
fill="freeze" />
</ui:button>

Technically, the "begin" value can be defined since RCC/LiveTemplates 
define how a shadow tree's events are routed back to the custom element 
instance. However, go figure how your SVG implementation will know how 
to animate your button's width, how is it supposed to know that your 
button's width is expressed as a float value?!?  You could argue that 
in this case your implementation could "guess" it, but there are a 
variety of data types that can't be guessed and there has to be a way 
to define how incrementation would work on such and such data types.

Additionally, animation (including those done with the <set/> element) 
do not work on the DOM values of attributes but on their animated 
values, there would have to be specific directions in the SVG 
specification to say that the same kind of refreshes happen for DOM and 
animated value changes.

There is no way an XSLT-based mechanism makes it any easier to 
accomplish this than any other mechanism as there is no way to animate 
non-SVG attributes today. If you have proposals on how to accomplish 
this, I'd be happy to read it.

> Examples of what can be achieved with templates have been developed,
> including some user interface widgets and general layout elements.

I took a look at your examples. I think your mechanism would be fit for 
simple standalone widgets, but this approach has some limitations for 
larger-scale projects. Part of what makes RCC "popular" so far (besides 
an implementation :) is that it fits in a DOM-based environment that's 
very good for scripting integration. A popular and well-proven approach 
to designing custom widgets, back from pre-RCC days and greatly 
simplified by RCC, is to have an ECMAScript (or whatever other 
scripting language) class that handles a particular custom XML element. 
Of course, this class architecture can help having some inheritance and 
cleanly share functionalities between different custom elements. 
Additionally, using a controller object, a context can be easily 
maintained for complex widgets that involve state tracking etc without 
having to store data in the XML tree.

Also, there is clean integration with DOM Events, so that custom events 
can be triggered from the DOM implementation, and SVG 1.2 should 
closely integrate with DOM Level 3 Events so that custom and namespaced 
events can be created and dispatched. Your button example relies 
exclusively on attribute-based event listeners, which are implicitly 
deprecated by the XML Events specification and the current efforts of 
its SVG 1.2 integration, although I suspect your samples could be 
reworked to use XML Events. Anyway, not using XML Events you are forced 
to use methods that imply usage of eval(), which is bound to attract 
flames from a good part of the community (I'll let Jim Ley comment 
further) including Java folks who are not necessary "blessed" with this 
functionality.

Additionally, and for what it's worth, note that the RCC approach 
involves a lot less specification work than your approach as there is 
no need to defined additional XPath functions for things like bbox() 
and the likes that I see you use in your samples. RCC leverages the DOM 
specification further.

The good news is that there has been considerable work from within the 
working group to try and concialiate the RCC and LT approach, and all 
of this should be detailed in the next working draft.

Antoine
-- 
Antoine Quint <aq@fuchsia-design.com>
W3C SVG Working Group Invited Expert
SVG Consulting, Teaching and Outsourcing
Fuchsia Design <http://www.fuchsia-design.com/>

Received on Monday, 3 November 2003 05:19:18 UTC