4 Rendering Custom Content

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!

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.

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.

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

  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.

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

  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.

  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.

  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.

  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.

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

Received on Thursday, 4 March 2004 22:53:49 UTC