Re: 4 Rendering Custom Content

At 02:53 PM 3/5/2004 +1100, Cameron McCormack wrote:

>I think that the transformer element, along with XSLT transformations, should
>be left in SVG 1.2.  From my experience adding this support to Batik, it
>wasn't a great implementation burden at all.  The code specific to handling
>XSLT transformers for a custom element was only a couple of hundred lines.
>I used Apache's Xalan libraries to perform the transformation.  I know this
>won't be the case for all platforms, but Java is distributed with an XSLT
>library (a slightly older version of Xalan) and thus wouldn't require shipping
>additional libraries at all.  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!

OK, but we'd still need to have one, right? I'd be hesitant to require XSLT
in SVG viewer.


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

But if you have an access to XSLT processor you can do it yourself without any
hassle already, right?


>Of course this sidesteps the main problem I have with RCC and that's that
>one has to handle all of these dependency problems oneself, setting up
>event handles and so forth.  With pure script based RCC elements this is
>of course difficult, since analysing the author's script to determine which
>elements and attributes are inspected (what dependencies exist) is impossible
>without executing the script itself.  As I said earlier, tracking XSLT
>dependencies would not be impossible, but is still hard.  In my 
>implementation,
>constraints can be used to solve the problem of propagation into the shadow
>tree for common cases.  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.

This is actually not how you'd write RCC components most of the time. 
Generation
of the shadow tree is a trivial part. The hard part *IS* keeping source DOM and
shadow tree in sync. It is important NOT to regenerate it because that will 
kill
performance: every time you regenerate shadow tree you destroy the old one and
with it you destroy the cashed drawing state that was associated with the 
elements
in the old shadow tree (it is many times faster to redraw an element that 
has already
been drawn than to draw a new element). If you regenerate refContent 
element, you
also will kill the drawing state of all the children of the custom element 
- huge
performance penalty. So it is crucial to "fix" the shadow tree instead of 
regenerating it.
Once you written the "fixing" code, you can simply run it upfront to produce an
up-to-date shadow tree from the prototype.

The main problem with XSLT is that it is not incremental and it cannot 
translate
small changes in the source into the small changes in the shadow tree.


>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.
>
>So here are my responses to the 4.5 Open Issues for which I have an opinion
>that differs with those given in the working draft comments.
>
>   2. [What events trigger shadow tree regeneration]
>
>      While adding event listeners manually with script is workable, I think
>      a declarative syntax for specifying which mutations cause a shadow
>      tree regeneration is better.  This declarative syntax should allow
>      specifying that these events cause either a complete shadow tree
>      regeneration (equivalent to calling rebind) or some script function
>      which performs a smaller, specific modification to the shadow tree
>      (preferable with XML Events syntax).

XMLEvents cannot handle because they don't allow filtering on the attribute
name.


>   6. [One way or two way]
>
>      I'm unsure what you mean here.  Do you mean should changes to shadow
>      trees cause changes to corresponding parts of the prototype or subtree
>      of the custom element?  I think if an element, which was generated 
> because
>      it was copied from the prototype, is modified then these changes should
>      not be reflected in the prototype.  The shadow tree should initially
>      just be a copy of the prototype.  If an element from the subtree of the
>      custom element is inserted into the shadow tree by means of refContent,
>      then I think changes on it should be reflected in the custom element's
>      tree, just as if this were a use element.

Imaging writing a text field. You'd use an editable text element. When text 
changes
you need to update the source (or data) tree to reflect that (and the other 
way around).
So in some cases there is 2-way change propagation.


>   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.  The SVG specification should be written to
>      ease the burden of authors.  As to this particular issue: by what do you
>      mean "event mapping"?  How events on shadow tree elements get mapped to
>      events on the custom elements?  I haven't thought much about this, and
>      I'm not sure if there are common event mappings that would benefit from
>      a declarative syntax.  If there are, though, declarative syntaxes are
>      the way to go (in my opinion).

Yes, but we don't want to screw up. It is OK to leave stuff for future.


>   8. [Dependency mapping]
>
>      I'm unfamiliar with XForms and its instance data model and how that
>      relates to dependencies.  I agree however that dependency mapping is
>      highly desireable as it would take a lot of burden off RCC element
>      authors.  As I said above, though, it's not an easy task.  A declarative
>      syntax for specifying dependencies (which is pretty much was 2. is 
> about)
>      should be investigated.
>
>   9. [Styling system]
>
>      If by "styling system" you mean XSLT, then yes, I'm for it.  If you mean
>      CSS, then I really don't know how this could be achieved.
>
>   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.

It is one thing to have XPath evaluator and it is a different thing to have 
XPath
dependency tracker, right? How hard is such tracker, based from your 
experience?
I thought that it is fairly hard, but if it is not maybe we need such 
thing. It would
help in #8 as well.


>   14. [Script context for external extensionDefs scripts]
>
>       How are scripts in external documents handled when a use element is
>       used?  However this is handled should be how extensionDefs scripts
>       are handled.

That's simple: every document has its own script context.


>   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.
>
>       Perhaps for simple cases some declarative syntax could be used to
>       map the animations of custom element attributes to the attributes of
>       the shadow tree elements.  If we take this idea further and allow
>       expressions for mapping the animations to the shadow tree elements, we
>       come back to my constraints project which would solve this problem.

I agree. The issue is how much should be swallow now.


>   21. [Disallowing SVG namespace for extensionDefs]
>
>       I think it should be disallowed.
>
>   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.

OK.

Peter


>--
>Cameron McCormack
>|  Web: http://mcc.id.au/
>|  ICQ: 26955922

Received on Friday, 5 March 2004 12:21:52 UTC