This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1
> 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