This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: XSLT 1.1 comments -Examples please
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] XSLT 1.1 comments -Examples please
- From: Uche Ogbuji <uche dot ogbuji at fourthought dot com>
- Date: Thu, 15 Feb 2001 21:58:32 -0700
- Reply-To: xsl-list at lists dot mulberrytech dot com
> > 1. A usage illustrating portability. Say get and re-format the date
> > in ecmascript, which could also use a java extension, as per DC comment.
> > - Regularly asked for? Reasonably 'safe'.
>
> I just posted this off list to someone, may as well repost here (the
> actual method and class names don't work, but the basic
> principle I hope is clear)
I'm glad you posted it. I think it's a useful capsule of the thinking behind
xsl:script+bindings.
> If you have a web form on which you get a date in the local language
> settings and want to know if it is within a month of today, are you
> really going to write a recursive xslt extension function to do that
> or use a couple of lines to an extension language with built in locale
> aware date handling? More than anyone I've argued for the benefits of
> the functional approach, but I know which I would do. (Until XSLT n+1
> when the feature gets added to XSLT)
Who needs recursive templates?
> Using xsl:script you can implement a date:number-of-days-between(a,b)
> function that works for any XSLT 1.1 implementation that supports
> javascript or vbscript or java. I don't think you can do that
> in xslt 1.0 in any reasonable way.
Why do you need to do so when the XSLT implementors have done so for you?
> in xslt 1.1 you make date: point of at any unique URI and then give
> multiple xsl:script to bind that URI to date related methods in whatever
> target languages you are using.
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.
And you're also saying that you are going to be willing to manage the code
across multiple stylesheets needing these date functions?
This doesn't scare you from acode maintenance POV? The network effect of
dependencies you have introduced does not give you the heebies?
> in XSLT 1.0 you have to make date: point to a URI that is an xsl engine
> specific prefix followed by a URI using the java class name, so it only
> works on one engine, not even all the java ones.
No you don't.
> xmlns:date="http://www.oracle.com.XSL/Transform/java/java.util.Date
> (if java.util.date had a method of that name, which it probably doesn't)
There is no reason for this mess except that the Java implementors decided for
it.
I would much rather
xmlns:std="http://xml.com/xslt-extensions"
and then, ignoring the fact that "within a month of today" is unclear, use my
std:date.diff() function.
Then Java, Python, Perl, VBScript, etc. people are happy, without an explosion
of maintenance.
> This is what xsl:script is trying to avoid.
All xsl:script does is drag this problem from a layer opaque to XSLT to a
layer intimately coupled with XSLT. I really don't understand how anyone can
think this is a good idea.
> It means I can use
>
> <xsl:value-of select="date:number-of-days-between($a,$b)"/>
>
> rather than the XSL 1.0 equivalent
>
> <xsl:choose>
> <xsl:when test="function-exists('xt:number-of-days-between')">
> <xsl:value-of select="xt:number-of-days-between($a,$b)"/>
> </xsl:when>
> <xsl:when test="function-exists('saxon:number-of-days-between')">
> <xsl:value-of select="saxon:number-of-days-between($a,$b)"/>
> </xsl:when>
> <xsl:when test="function-exists('xalan:number-of-days-between')">
> <xsl:value-of select="xalan:number-of-days-between($a,$b)"/>
> </xsl:when>
> <xsl:when test="function-exists('msxsl:number-of-days-between')">
> <xsl:value-of select="msxsl:number-of-days-between($a,$b)"/>
> </xsl:when>
>
> which is crazy,
Wow. You set up a pretty flammable straw man there. So of course it's crazy.
--
Uche Ogbuji Principal Consultant
uche.ogbuji@fourthought.com +1 303 583 9900 x 101
Fourthought, Inc. http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list