Re: Using templates instead of script to render custom content

Hi Antoine 

Further to Cameron's reply we believe the main advantage of using templates
and dynamic attribute evaluation aka one-way constraints approach over the
other approaches to RCC that we have seen (though we are not members of the
working group) is its support for user interaction and animation (which
really is a sort of extreme user interaction in which an elements attributes
are updated every few milliseconds).

To clarify the issue consider the following scenario. A SVG author has
written RCC code that takes n buttons with text and lays them out
vertically. The buttons and vertical layout element are custom elements. Now
the author wants to support the following animation, when one of the buttons
is selected by the user they want that button to expand in size and the
layout to be preserved, i.e. buttons below the selected button must move
downwards. To make it more interesting we might allow more than one button
to be selected or allow buttons to toggle on and off, i.e. grow and shrink.

How should the author do this? There are two obvious approaches, either they
A) Directly modify the generated shadow tree elements (almost certainly
using script). This will require considerable programming effort but
hopefully will be reasonably efficient.
B) Modify the custom element attributes and regenerate the shadow tree. This
will be considerable simpler: simply modify one or two attributes, but has
the potential disadvantage that it is very expensive: regenerating all
shadow trees for every time step in an animation seems prohibitively
expensive.

However there is a third approach
C) Modify the custom element attributes and then have the browser/custom
content renderer automatically propagate the consequent changes through the
attributes of the shadow tree elements, i.e. incrementally update the shadow
trees. The advantages are clear: the author can perform animation and
modification on the level of the user elements but not pay a performance
hit.

This is the approach that Cameron's project is investigating. There are a
number of ways such incremental regeneration of shadow trees might work
C1) Examine the script used to generate the shadow tree and automatically
generate scripts that incrementally update the shadow trees. This seems very
hard---script is complex to reason about and understand.
C2) Extend SVG with custom elements which do not provide the full-power of
script but that are designed to support incremental update of shadow tree
attributes and elements. This is the approach we have taken and modelled our
extension on XSLT since this seems the closest relevant standard.
C3) Use a reduced form of XSLT which can be efficiently incrementally
evaluated and use this to generate the SVG from the custom elements. This
requires little modification to SVG but does mean identification and support
for such incremental or dynamic XSLT.

In terms of the underlying techniques and their feasibility the difference
between C2 and C3 does not seem great. We are investigating two techniques
for incremental regeneration of shadow trees
1) One-way constraints to keep track of dependencies between attributes in
the custom elements and elements in the shadow tree. Whenever a custom
element attribute is modified all attributes depending will be automatically
and efficiently updated, there is no need for any shadow tree regeneration
and the author needs to do nothing. This supports simple animation and user
interaction. Cameron's current implementation provides this.
2) Incremental regeneration of the shadow tree elements. We have not yet
implemented this but are looking at earlier work on incremental XSLT
transformation 
     http://citeseer.nj.nec.com/458768.html
However it is not clear to us whether other people think this is a real and
important issue and whether to focus on (C2) extending SVG or (C3)
investigating a reduced subset of XSLT and providing a incremental
implementation for this that could be used to implement RCC. The advantage
of (C2) is that we can leverage from our current implementation and that it
is control of the SVG community, the advantage of (C3) is that it is more
general and that it arguably more orthogonal and requires little (no?)
extension to SVG. However communication between the SVG renderer and the
XSLT engine may introduce overhead and be a little tricky.

What are your thoughts?
 
Cheers 

Kim

on 5/11/03 9:59 AM, Cameron McCormack at cam-www-svg@aka.mcc.id.au wrote:

> Hi Antoine.
> 
> Antoine Quint:
>>>  - 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.
> 
> True, but I think there is potential for it to be used in incremental
> situations.  See, for example, http://www2002.org/CDROM/refereed/321/ .
> 
>>>  - 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.
> 
> Yep, things like this would have to be worked out.  My implementation
> isn't a complete solution, just a prototype!  Plus, I haven't
> implemented any animation support at all.  I think though, that in my
> CSVG framework, some system of typing custom elements' attributes will
> have to be done, and this is what could be used to hint at what sort of
> animation can be done.
> 
>> 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.
> 
> Yup.  One thing I was considering is using my expression based
> attributes similarly to animations, for example:
> 
> <rect x="0" y="0" width="100" height="100">
>   <constraint attribute="x" value="id('r')/@x"/>
> </rect>
> 
> This then would parallel how animation is handled in current SVG.  It
> also has the advantage of supplying default values if there is no
> support for my constraint extension.
> 
> In fact, if the idea was generalised to allowing animation to support
> expressions, then the constraints could just be another form of
> animation.
> 
> <rect x="0" y="0" width="100" height="100">
>   <animateExpression attributeType="XML" attributeName="x"
>     expression="id('r')/@x"/>
> </rect>
> 
>> 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.
> 
> Without expression based attributes, I agree.  That's the angle I was
> coming from though, so sorry if I confused you.
> 
> With expression based attributes though, animation could be specified in
> a completely different way, using some time variable.  For example:
> 
> <rect x="time()" y="0" width="100" height="100"/>
> 
> where time would be a function that returned the current animation time
> in seconds.  This would allow for all sorts of interpolations not
> supported in SMIL.  This style of animation might be easier to integrate
> with the template stuff than SMIL's.
> 
>> 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.
> 
> Yes, object orientation is good for this sort of thing, especially as
> authors might like to think of their custom elements as objects.  That
> is a disadvantage of my approach.
> 
> The best reason why I think something like templates+expressions could
> be better than script for implementing RCC is the automatic dependency
> tracking.  I imagine that if everyone is writing their script to handle
> custom elements that they will have to handle mutations on them
> manually, by attaching event handlers and then manipulating the DOM
> when the event is fired.  This sort of code is going to be common to all
> RCC scripts if authors want their custom elements to be modifiable and
> the changes to be propagated to the shadow tree.  With the expressions
> and dependency tracking, this sort of thing would happen automatically,
> so the author doesn't have to worry about it.
> 
>> 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.
> 
> Sure, the eval thing is really hacky.  I just used it in my examples
> because 1) my prototype didn't have the ability to handle
> non-XPath-expressions for custom element attributes, and 2) I didn't
> think going to the effort of creating DOM events and firing them off was
> useful for the purposes of the example.  I would, of course, prefer
> proper event handling/dispatching.
> 
>> 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.
> 
> That is probably the greatest obstacle.  In the beginning of my project
> I was wondering whether to use ECMAscript for the expressions but I
> decided that XPath was just too useful.  Also it is more consistent with
> the template stuff.  If attribute expressions used the DOM, though,
> you'd get examples like:
> 
> <rect x="document.getElementById('r').getAttribute('x')" y="0"
>   width="100" height="100"/>
> 
> which is quite verbose.  Also tracking dependencies through the script
> would be a nightmare compared to the XPath stuff.
> 
> At the moment I am not completely happy with the syntax I have
> (lots of accessor functions).  I will probably end up having (mostly
> implicit, sometimes explicit) type information about elements'
> attributes so that they can be referred to just with XPath locations.
> That is,
> 
> <rect x="id('r')/@x" y="0" width="100" height="100"/>
> 
> instead of
> 
> <rect x="x(id('r'))" y="0" width="100" height="100"/>
> 
>> 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.
> 
> I'd certainly be interested in knowing which direction it's going.
> 
> Thanks,
> 
> Cameron

-- 
Kim Marriott
School of Computer Science & Software Engineering
Monash University, Wellington Rd, Clayton, Vic 3800, Australia
Ph: ++61 (3) 9905-5525, Fax: ++61 (3) 9905-5146
Email: Kim.Marriott@infotech.monash.edu.au

Received on Tuesday, 4 November 2003 23:33:03 UTC