Re: [xsl] XSLT 1.1 comments -Examples please

[David Carlisle <davidc at nag dot co dot uk>]

> I think it's a useful capsule of the thinking behind 
> xsl:script+bindings.

Note it's _my_ understanding of xsl:script. I'm not on the Working Group
and so I don't want to imply that this was actually the reason it was
added, just what I think was the reason.

> Who needs recursive templates?

because in thie original version of the mail (off list) that first bit
was answering the suggestion that extension functions be written in XSLT
rather than (any) extension language. I was trying to say that for some
functionality, if it is not built into XSL you really want to cal out to
something rather than write it in XSL. Date handling being a good
example especially if you want locale specific handling.


> So you're telling me that in the future David Carlisle XSLT scripts, I'll see 
> date implementations in Java, ECMA, VBScript, Python, Perl, and XSLT?  I'll be 
> impressed when I see it, even though the XSLT will probably be a mess.

Well you might see 
<xsl:include  href="userful url to a stylesheet that
xsl:script binds date handlers suitable for lots of different extension
language implementations" />


> This doesn't scare you from acode maintenance POV?  The network effect of 
> dependencies you have introduced does not give you the heebies?
It's  easier than the XSL 1.0 alternative which I sketched out.
(but since you said of that

> No you don't.

I'll pass on that comment at this point.


> I would much rather
> 
> xmlns:std="http://xml.com/xslt-extensions"

So would I. As I posted already on this thread I've been asking for that
for over a year!

Howver I was just trying to be kind to Java programmers (and javascript
and python etc). For me, if I'm not going to write the extension
function myself the best possible course is a common namespace for
extensions, and all XSL systems offer implementations for as many of
those common extensions as they feel they can manage. But this is
bringing standardisation to what are essentially "built in" extensions.

I don't think xsl:script helps at all with these (and I am sure you will
agree) so currently I can use saxon:line-number without xsl:script
and it would be the same in XSL 1.1. As you say it would be better to
have common-extensions:line-number and have all the XSL engines support
that.

BUT I (assume) that there will always be occasions when people want to
write an extension function in a procedural language. (or languages)
xsl:script is trying to standardise this binding for end-user written
extensions. 

> Wow.  You set up a pretty flammable straw man there.  So of course it's crazy.

Not a straw man at all. Look at stylesheets like Norm Walsh's docbook
stylesheets or Sebastian's TEI ones that try to be portable. They have
_lots_ of this kind of rubbish or equally horrible multiple nested
xsl:fallbacks for each of the known processors. This is the real
perceived problem that xsl:script is trying to solve.

David

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet delivered
through the MessageLabs Virus Control Centre. For further information visit
http://www.star.net.uk/stats.asp

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