Re: XT extension mechanism

[James Clark <jjc@xxxxxxxxxx>]

Flow Simulation wrote:
> 
> James Clark wrote:
> 
> > XT's new experimental extensibility mechanism is based on the idea of
> > filtering fragments of the result tree through an object.
> > The xsl:filter element specifies a filter. It has attributes that
> > specify the filtering object in the same way as the HTML 4.0 OBJECT tag.
> 
> which is great if you're building on top of Java or COM, but not so clear
> to me how you would use it if you weren't using either of those technologies.

Just as with the HTML 4.0 OBJECT tag, there is no restriction to Java
and COM.  The attributes can point to a resource containing script.

<xsl:filter  classid="http://www.jclark.com/scripts/total.js";
 codetype="text/javascript">
...
</xsl:filter>

> > I'm also thinking about supporting script directly, using something like
> > this:
> ..
> 
> > <xsl:template match="foo">
> >   <xsl:filter type="text/javascript" script="diddle(this)">
> >     <xsl:apply-templates/>
> >   </xsl:filter>
> > </xsl:template>
> 
> That looks great.   But I'm not sure how this improves on the <eval> element
> in e.g. the Microsoft XML Tutorial 15.   In the latter case you can drop scripted
> elements into the template whereas with <filter> you need to programmatically
> do this, I think.

Huh?  In one case the script is in an attribute value, in another it's
in content.

The major difference is that xsl:filter acts on the result tree, not the
source tree.  A mechanism that acts purely on the source tree can never
be adequate.  Consider the case where you want to use a different style
for every other row of the table.  You can do this with eval as in the
old submission, the differences in the row-handling are non-structural
(eg a different value for an attribute).  But consider a variation on
this case: the rows are generated from source data which is sorted using
xsl:sort.  With xsl:eval you're out of luck, but with xsl:filter you can
do it.

Another major difference is that with xsl:eval (at least as it was in
the submission) you can only generate strings.  With xsl:filter you can
use the DOM to modify the element structure of the result: for example,
you could transpose rows and columns.

>   Is it easier to implement, or a question of language "purity"?
> 
> If you use script (either way), I wonder if you still need to make <filter> like an
> object as well:
> 
> >  <xsl:filter classid="java:ConvertPrice">
> >     <xsl:arg name=".....
> 
> because you could maybe do something like:
> 
> <xsl:object name="MyFilter" classid="MyFilter.class"/>
> <!-- MyFilter.class has a method ConvertPrice(DocumentFragment frag) -->
> .....
> <xsl:filter type="text/javascript" script="MyFilter.ConvertPrice(this)">
> 
> So I would say scripting was a first priority.   Using objects probably flows naturally from
> this if there is DOM support.

The key difference is state.  With an object-style filter there is no
shared state between separate filter objects.  With a script-style
filter there is a shared context that is used for the evaluation of all
script fragments.  An object-style filter is something that I could
imagine implementing in an interactive non-batch environment such as a
WYSIWYG editor, because the effect of the filter is localized to the
subtree of the result that the xsl:filter element contains.  With a
script-style filter, the script code has global side-effects, and I
think it would be very difficult to make this work in a non-batch
environment.

James


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list