Re: XSLT 1.1 comments - the chocolate hobnob challenge

Evan Lenz wrote:
> 
...
> 
> Francis Norton wrote:
> "But XSLT is also good at providing cross-platform portability - indeed one
> of it's strengths is that it is more portable than *any* language. This is
> something that the XSLT community are, I suspect from feedback in this list,
> very keen on...For me, and I suspect for many on xsl-list, what XSLT does is
> provide *platform-independent* XML processing."
> 
> I wholeheartedly agree with Francis.
> 
> I hope that the XSL Working Group will take these apparently widespread
> concerns to heart and reevaluate their requirements for XSLT 1.1.
> 
Thank you, Evan - posting the claims in that paragraph made me feel
*very* nervous ...

What really worries me is that an extended period during which the spec
privileges non-platform-portable extension functions over XSLT extension
functions will do irreversible damage in terms of fragmenting the
codebase and encouraging people to drop the idea of platform-independent
portability as a realistic goal for XML technologies.

I am also concerned about performance - using server-side MSXML3, which
is immensely fast, the overhead for calling out of XSLT via msxml:script
was about 15ms when (I'm talking from memory) - but *without*
msxml:script some of our transforms are running in as little as 10ms...

It has been suggested that implementing XSLT-language extensions will
cause type problems with XSLT 2.0, but nobody has yet suggested any
problem that would not equally be raised by xsl:script and non-XSLT
extension functions.

Because I don't want to make an idiot of myself by proposing something
with severe technical flaws, I would like to put this to the test.

Here is a small but concrete proposal:

[1]	extend the xsl:script definition to specifically permit "xslt" as a
value of the language attribute.
[2]	specify a binding to Mike Kay's function and return elements [1],
but in the XSLT namespace, with behaviour exactly as in Saxon - ie it
would transparently return any data type supported by XPath, now or
future, or an RTF which could be converted implicitly to a node-set in
standard XSLT 1.1 style.

And just to give people an incentive, I will send a packet of chocolate
hobnob biscuits (plain or milk cholocate, at user preference) to author
of the first technical objection to including it in XSLT 1.1, which does
not have an uncontroversially satisfactory answer.

Francis.

[1]	http://users.iclway.co.uk/mhkay/saxon/saxon6.2/extensions.html

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