[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] XSLT 1.1 comments -Examples please

---

---

> > 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@xxxxxxxxxxxxxxx               +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

---