Re: Microsoft extensions to XSL

[info@xxxxxxxxxx (Flow Simulation)]

James Clark wrote:


> I agree that without script there will always be cases that you can't
> handle, and I agree it's bad if you can't use XSL as part of a
> solution if XSL can handle 95% of what you need.  But I don't think
> it follows that you need an "escape to scripting language".  I find one of
> the most interesting things in Microsoft's beta to be the way they have
> integrated it into the DOM.  They give you a DOM method on a node that
> takes a DOM node containing the xsl:stylesheet element, and returns the
> XML that results from transforming the tree rooted at that node using
> that stylesheet.  (Another nice feature is that their DOM allows you to
> use XSL patterns to navigate the tree.) This gives you a clean way to
> use script with XSL while keeping things nicely modular.  

This is great and very powerful.   And I can also see why you would want to
limit the scope of XSL.   And if you need to do a lot of data processing
using procedural code it would make sense to do it separately from applying
the stylesheet.

But my fear is that by forcing any scripting out to another layer we have 
already fallen off the "95% there" cliff.   E.g. I have this great
XSL stylesheet to render an invoice.   But in order to total the net and tax
amounts (i.e. the last 5%) I have to get involved in DOM 
and some other processing step and how they interact etc.    

Really I'd just like the stylesheet to be self-contained.   It might contain
a little bit of script for formatting or totalling.   
My investment of effort in developing the stylesheet is protected because 
XSL is a standard and I can use that stylesheet with other tools and 
platforms.


Andrew Bunner then wrote:

>  "How hard do you want to make it for someone to write an XSL engine?"

> Your XSL engine would have to include an interpreter for a language that's
> almost as complicated as C++. The opinion expressed was that there would end up
> being only one or two XSL engines in this world.

As a tool developer one might want to avoid the complication of scripting.  
I think I can picture how I would write an XSL processor without too much
difficulty.   Although ECMAScript isn't quite C++, I don't really fancy 
writing an ECMAScript interpreter.   But I think
there are a few interpreters out there which could be plugged in.

I think a bigger danger is if XSL is made too difficult to use in practice.
Then there might be plenty of XSL engines - but only one or two users!

Bill Ayers (BillA@xxxxxxxxxx)

<<application/ms-tnef>>