SVG 1.2 WD comments: RCC+XSLT and others

4. Rendering Custom Content

I think allowing the use of XSLT to specify the generation of custom
elements' shadow trees is a great idea.  The automatic regeneration of
the shadow tree will be useful, too.  I think authors will have to take
care though if the shadow tree is modifiable by any script in the
document that the regeneration will overwrite these changes.

With standard XSLT there will still be a need for script, especially for
things like layouting code, where bounding boxes must be computed.  I
have been thinking lately about how this could be achieved just in the
XSLT with a few custom functions but I am not sure a clean solution
exists.  (One possibility would be to provide access to the shadow tree
that is being generated while the template is being executed but I think
this might be a step away from the XSLT processing model.)

A user agent could implement an incremental XSLT processor for when an
author has specified automatic regeneration of shadow trees upon DOM
modification.  This would just be an optimisation and would be invisible
to the author.

As mentioned in an earlier e-mail, animation of other-namespaced
elements would be good to have.  This may be difficult to achieve
without adding support for specifying the types of a custom element's
attributes (as suggested by Fred P. in his e-mail).  Also, how an
animated attribute would effect the shadow tree would have to be
considered.  In the worst case, the transformer must be run after every
"update" due to animation.  This is, I think, not how animation should
be though of (as discrete modifications after short periods of time).
This is also the reason there are no SMIL events for when animation
causes an update to an animated attribute, yes?  In this case, there
might be a way to keep track of where the animated attribute is used in
the generation of the shadow tree to determine which attributes can then
be animated in the shadow tree.  Animation of a custom element's
SVG-namespaced children could well be easier, especially if
refContent is used to add these elements to the shadow tree.

Regarding the comment in section 4.5:

  One of the challenges with custom attributes is that XML defines the
  list of attributes on an element to be unordered. Also, there is no
  natural place to put a shadow tree onto an attribute.

why would animated attributes need a shadow tree?  Shouldn't they just
follow the form of standard SVG animatable attributes (that is, have
baseVal and animVal properties)?

Speaking of refContent, why is there a need for the restriction to
select each child element of the custom element at most once?  Does the
reference in the shadow tree have the same semantics as a use element?
With XSLT now available, is there any point in restricting the XPath
syntax usable in refContent's select attribute?

In XPath expressions inside template definitions is it possible to refer
to any part of the document or will there be restrictions as with
refContent?  If there are no restrictions, what happens if you use the
ancestor axis if you are inside a shadow tree: does
ancestor::*[position()=last()] evaluate to the container element of the
shadow tree or does it work its way up to the document's svg element?

Since XSLT does not specify a default namespace for elements referred to
in an XPath expression (a snag I'm sure most people using XSLT will have
been caught on) does this mean expressions will require lots of prefixes?
For example, with this document:

  <svg xmlns="http://www.w3.org/2000/svg">
    <rect x="0" y="0" width="100" height="100"/>
  </svg>

and this XSLT:

  <xsl:stylesheet 
    xmlns="http://www.w3.org/2000/svg"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    version="1.0">
  
    <xsl:output mode="text"/>
  
    <xsl:template match="/">
      <result>
        <xsl:value-of select="/svg/rect/@width"/>
      </result>
    </xsl:template>
  
  </xsl:stylesheet>

the result element will be empty, as the XPath expression is looking for
an svg and a rect element in the empty namespace.  Instead you'd have to
do:

  <xsl:stylesheet 
    xmlns="http://www.w3.org/2000/svg"
    xmlns:svg="http://www.w3.org/2000/svg"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    version="1.0">
  
    <xsl:output mode="text"/>
  
    <xsl:template match="/">
      <xsl:value-of select="/svg:svg/svg:rect/@width"/>
    </xsl:template>
  
  </xsl:stylesheet>

I think XSLT/XPath 2.0 has a lot of nice extras, notably the typing
system.  This would tie in nicely with the typing of custom elements'
attributes mentioned earlier.  Perhaps the extensionDefs element could
also specify a schema for the element.  Of course, XSLT 2.0 being still
being a working draft would most likely disqualify it from
consideration, but it might be something to think about for the future.

How should the standard presentation attributes on custom elements be
handled?  (And indeed, how are people handling them with ASV6's
implementation of RCC?)  I am sure many people will want to be able to
specify, for example, a font-size attribute on their UI element.  There
being many such attributes it would be unwieldy to have to copy each of
them to a g element in the shadow tree for each of the custom elements
an author is creating.  Or does this already work as it should (just
like putting presentation attributes on a use element)?

The suggestion of be able to evaluate XPath expressions from script is a
good one.  As well as allowing people interested in expression-based
attributes a way to implement this without having to add support to the
user agent, it would be quite useful in RCC scripts (and other scripts)
for navigating around the document tree.

I am beginng to think that the differences between RCC+XSLT and
LiveTemplates are narrowing such that the two could be merged.  At
least, I think the best part of LiveTemplates (the XSLT) having been
incorporated into RCC, I wonder how useful LiveTemplates would actually
be.


10.3 Constrained Transformations

Another good idea and much better than handling onscroll and onzoom
events of the document and then manually updating transformations or
coordinates of objects.  Presumably these referenced transformations
will be automatically updated if they refer to an element whose
transformation is being animated.  Since these transformation references
could be chained (an element with a ref transformation could refer to
another element whose transformation is determined using ref)
dependencies will have to be tracked.  This is a similar problem to
animating custom elements, mentioned earlier, and incremental XSLT
processing.


Cameron

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

Received on Sunday, 16 November 2003 20:08:05 UTC