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

[cutlass <cutlass at secure0 dot com>]

> 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