Re: 4 Rendering Custom Content

Cameron McCormack wrote:
> The point, though, is that the use of XSLT
> itself shouldn't be an obstacle to including it in SVG 1.2 since there exist
> libraries that implementors can use.  Implementors needn't rewrite an XSLT
> processor!

Unfortunately, not all implementors can reuse third-party libraries.

> By "difficulty in optimization" I assume you're talking about the issue of
> shadow tree regeneration.  I can understand that the dependency tracking in
> XSLT is not trivial, but it is easier than tracking the dependencies set up
> by RCC script.

But in RCC you don't have to track them, which is what makes it so 
simple. There are interesting research projects on bi-directional 
transformation, but right now they're really at the research project 
stage (that I've heard). Finding an algo that will properly track all 
dependencies and rerun enough of the XSLT to garantee that the change in 
the DOM propagates is easy: all it takes is to run the entire thing for 
every mutation (in fact, that's not true. There will be problems with 
tracking document() related dependencies, and a problem with id()). 
Finding an optimal one, or at least one that doesn't watch the entire 
document too easily and eat gobbles of memory, is much harder.

>  Since it's OK for script to have to set up event handlers
> manually to handle custom element mutations, why should it not be OK for
> shadow trees generated by XSLT as well?  Surely for a custom element that has
> an XSLT transformer one could add an SVGBindEnd event handler that sets up
> DOMAttrModified events (just like non-XSLT RCC elements) which could force
> the rerunning of the transformation if the author decides it is not too costly,
> or manually minimally modify the shadow tree with script.

Using script and XSLT at the same time could cause trouble, you'd easily 
overwrite your own changes since you have two sources accessing the same 
tree. Re-running the whole XSLT would work in some cases, but for things 
like GUIs it's likely to be very slow (a slider would have to rerun a 
full render on every mousemove).

> In 4.1.8 you talk about a "declarative syntax for
> specifying the set of events that cause a particular element's shadow tree to
> be regenerated".  This sounds like a great idea to help authors avoid writing
> the same DOM mutation event handlers again and again.

I agree.

> It would be nice if there were some way of specifying the valid attributes
> for custom elements, their types, the element content models, etc.
> In document XML Schema or RelaxNG would be good for this, and perhaps somehow
> be integrated with the declarative shadow tree regeneration specifications.

I have been suggesting that RDDL would be a good way of doing this for 
UAs that want to.

>   7. [RCC minimizing scripting]
> 
>      I believe that RCC should go to reasonable lengths to help the author
>      avoid writing script.  There seems to be a lot of worry about burdening
>      implementors, but this results in burdening the author.  This is the
>      wrong way of doing things.

If you have a language that's easy to author, and has wonderful 
features, but no implementors you're screwed. The quality of the 
language design is important, but if implementors say something is too 
costly to do, then we make the pragmatic decision of removing it (at 
least for now). So no, it's not the "wrong way of doing things".

>   11. [XPath and XSLT burden]
> 
>       It seems to have been decided that XPath support will be required in SVG
>       1.2 due to the DOM Level 3 support.  From my experience, supporting XSLT
>       was not a huge burden at all since I could just use an existing XSLT
>       library and plug it straight in to Batik.

Supporting XSLT is however much more effort than supporting XPath.

>   15. [Animating custom element attributes]
> 
>       Animating custom element attributes is vital, I believe.  It seems that
>       the DOM traits are to be used to handle animation.  This would work
>       but would require the modification of actual attributes of shadow tree
>       elements in response to the animation of custom element attributes.
>       Thus the shadow tree elements aren't actually being animated in the
>       sense of having their SVGAnimated*.animVal values being updated.
>       Sometimes it is necessary to distinguish between animation in this
>       respect, and modification of the base value.

I'm not sure there's a requirement that the actual value be changed when 
given a trait.

>   22. [DOM 3 XPath]
> 
>       Having the ability to evaluate XPath expressions from script would be
>       a boon to script authors.  It would eliminate the drudgerous walking
>       of the DOM.  I don't think this would be sufficient to implement
>       attribute expressions (as in CSVG), however, as handling extension
>       functions and SVG types could not be used without some modification to
>       the XPath engine.

Adding an API to add functions to the XPath engine should suffice, and 
it doesn't typically require modifications to the engine since it is 
something that is normally supported by XPath engines. Adding new types 
on the other hand seems to be to be a bad idea as it breaks XPath's 
consistency and elegance, isn't necessarily supported by enough 
implementations, and in fact isn't needed since those types can be 
expressed as elements.

-- 
Robin Berjon

Received on Wednesday, 10 March 2004 10:26:45 UTC