Re: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1

Subject: Re: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1
From: cutlass <cutlass@xxxxxxxxxxx>
Date: Thu, 01 Mar 2001 20:27:36 +0000
To come back to to XSLT embedding XSLT within a general purpose language
would be as bad an idea as embedding the general language within XSLT
(i.e. xsl:script) and IMHO, the clean way to do it is rather through the
usage of the function call (or corresponding feature) of each language.

Eric

the proof of this will be which xslt parser will become dominant. a wild variant may be more successful even if it is 'out of spec', due to it being free, representing the mass's user requirements etc.

IMHO i think if the spec states no xsl:script; one of the implementors will have a variant, and the end user will implement that which is easist. ie a parser with a <xsl:script> to java will be used by the java programmer, etc..... just because w3 says so, dont mean it won't happen, to some it will represent a marketing opportunity. though i agree that the architecture of such a variant may be implemented differently in light of the spec saying no <xsl:script>.

i signed the petition because i think functional programming has a lot to offer in general, and an escape hatch to other languages may 'delay' adoption of these techniques and overall adoption of xsl. methink most people believe the same. i also believe that other langauges need to mature with respect to integrating towards the xml suite of technologies.

when i was given the job of technical audit and review of ICL's beeb.com implementation for BBC Worldwide ( sorry to refer, but its such a perfect example ) i learned quite a bit of what was relevant with these technologies, and determined that the users of the system; editors, layout and content developers were more important and relevant to adoption vs the programmer ( unfortunately, took them 3 times to get to a system that was relevant, no offense intended to those parties ).

so i would say to those arguing the whole XSLT case ( with respect to new requirements )in detail to step back a bit and lookat your user requirements, instead of our requirements ( painful as it seems ); xsl is in a period of adoption which requires characteristics which are commercially viable.

so to those folks who've been quiet in the face of technical dissertation on the list, i would suggest that they get their top 10 XSLT suggestions in before its too late.

now i'll shut up.

cheers, jim fuller







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


Current Thread