Re: 4 Rendering Custom Content

I wrote:
> >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.

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

You mean just from SVGBindBegin event handlers?  Only if the XSLT engine
were exposed to the scripting environment somehow.

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

Ok.  You'd have to be careful with cycles then, I guess.

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

It's not terribly difficult.  My algorithm involved stepping through the
XPath ignoring any square bracket predicates.  At each step a specific
type of dependency would be set up:

  - an attribute dependency, which sets up a DOMAttrModified listener on
    the current node
  - a node dependency, which sets up a DOMSubtreeModified listener on
    the current node

(ignoring variables for the moment).  Both of these dependencies could
be deep or shallow (whether they recognise mutations anywhere in the
subtree or just on the given node).  For deep dependencies, these can
either include or exclude the given node.

So we start with the current node (in my case, the element whose
attribute this XPath is describing).  Then recursively for each step:

  - if it's an id() function call, add a deep attribute dependency on
    the document element for "id" attributes.  If we're not currently
    inside a predicate, evaluate the id() function call and for each
    node in the resulting nodeset, recurse.
  - otherwise, it is a node test.  If we're in a predicate, just
    recurse without executing the step.  If we're not in a predicate:
      - if the axis is ancestor or ancestor-or-self, keep moving the
	current node up the document tree and each time, if the node
	test on this step matches the node, recurse.
      - if the axis is attribute:
          - if the previous axis was descendant, add a deep attribute
	    dependency on the current node for the given attribute,
	    excluding the current node.
	  - if the previous axis was descendant-or-self, add a deep
	    attribute dependency on the current node for the given
	    attribute, including the current node.
	  - otherwise, add a shallow attribute dependency on the current
	    node for the given attribute.
      - if the axis is child:
          - if the previous axis was descendant, add a deep node
	    dependency on the current node, excluding the current node.
	  - if the previous axis was descendant-or-self, add a deep
	    node dependency on the current node, including the current
	    node.
	  - otherwise, add a shallow node dependency on the current
	    node.
      - if the axis is descendant, for each descendant node that
        matches the node test, recurse.
      - if the axis is descendant-or-self, for the current node and each
	descendant node that maches the node test, recurse.
      - if the axis is following-sibling or preceding-sibling, add a
        shallow node dependency on the parent of the current node.  For
	each following or preceding sibling that matches the node test,
	recurse.
      - if the axis is parent and the parent matches the node test,
	set the current node to the parent and recurse.
      - if the axis is self and the current node matches the node test,
        recurse.

Currently I ignore the namespace, following and preceding axes.  In my
CSVG project I have other dependencies that are set up when extension
functions are called, e.g. for bounding boxes.

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

It will be interesting to see if I can implement the XPath dependency
analysis, constraint propagation and evaluation in plain SVG 1.1.
Anyone know of an existing ECMAScript XPath evaluator or XPath to DOM
calls compiler?

Cameron

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

Received on Sunday, 7 March 2004 19:21:29 UTC