RE: [xsl] XSLT 1.1 comments

[Adam Van Den Hoven <Adam dot Hoven at bluezone dot net>]

James Clark wrote:

> Yes, they could, but xsl:script makes it easier. The job of xsl:script
> is simply to provide a way to use a namespace URI to determine:
> 
> 1. The code to be called by an extension function
> 2. How to call that code (ie the language-binding)
> 
> This is a job that is completely language independendent and it is
> something that has to be done by any implementation of XSLT extension
> functions.  In my view this makes the XSLT spec the right place to
> specify xsl:script.  With xsl:script, all that is required for
> standardizing extensions is to specify the language binding like
> Appendix C does; it is not necessary to invent any XML syntax 
> to do the job that xsl:script is doing.

I'm not sure the problem lies with those who are implementing XSLT 1.1
processors. The problem exists for those of us who are using XSLT to produce
transformation documents. If I write a document that I can say is 100% XSLT
compliant, then I demand that when I use that document in a processor that
is 100% compliant the resulting output is exactly as I have specified. With
xsl:script, this is not possible. Because implementors are not guaranteed to
implement the xsl:script tag in a consistent way (if at all), I have no
guaranted that my XSLT document is going to generate the correct
transformations. 

Where this becomes a big issue is with client side transformations. One of
the big promises of the XML revolution was that I'd be able to send a client
(web browser, PDA, cell phone, ...) one transform document and several data
document and allow the client to do the transoformation. Now, I expect to
have to produce different transforms for specific target clients. However, I
have no realistic expectation to know whether the xsl parser that is at the
client supports ecmascript, Java, C++, C#, Python or what ever. All of a
sudden we're back to a situation similar to the browser wars (only worse).
Although I can assume that 90% of my viewers are going to use IE, I'd really
rather not have to. 

Adam

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