[no subject]

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.

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

Then again, I've not attempted to build an XSL processor, so I may be talking rubbish!

Bill Ayers (BillA@xxxxxxxxxx)  


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