James Clark wrote:

> For this kind of [string-to-string manipulation] extensibility problem, there
> could be a special case of xsl:filter that makes things simpler.  For
> example your particular example could be handled using something like
> 
>   <xsl:transform-string script="Number(this)+5">
>     <xsl:number/>
>   </xsl:transform-string>
> 
> xsl:transform-string would be a special case of xsl:filter.  It creates
> a string from the text content of the result tree fragment being
> filtered, applies the script to that string, and replaces the result
> tree fragment by a single text node containing the result of evaluating
> the script.

I _do_ like this.    In the trivial case (no children or children
not used) it collapses to be equivalent to <eval> but with the
script in an attribute.    So not only do you get a far more powerful
mechanism, but you get a bit of backwards compatibility as well!
And as you say, no need for special functions like childNumber().


> Allowing access to the source tree via the DOM has some problems.  What
> happens if you use the DOM to mutate the source tree? That's really
> scary.

The source tree would have to be read-only, and that also seems common
sense.   The implementation would have to somehow enforce this.

In general, I think loss of WYSIWYG editor performance is a price worth
paying to have scripting available when you need it.   One would hope that a 
good editing tool would gracefully degrade in performance as the extensions
were used.
 
Bill Ayers  (BillA@xxxxxxxxxx)


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