Subject: Re: [xsl] XSLT 1.1 comments -Examples please From: David Carlisle <davidc@xxxxxxxxx> Date: Fri, 16 Feb 2001 09:48:51 GMT |
> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XSLT 1.1 comments -Exampl, Uche Ogbuji | Thread | Re: [xsl] XSLT 1.1 comments -Exampl, Uche Ogbuji |
Re: [xsl] xsl:include still a probl, Daniel Veillard | Date | Re: [xsl] XSLT 1.1 comments, David Carlisle |
Month |