|
[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
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
|
| |
Mac OS X
Linux/Unix
data server software 