Limited EXSLT Support in Mozilla Firefox 3.0

by Kurt Cagle

The news from the XSLT front of late has been very good, with the release of the XSLT 2.0 standard, XPath 2 and XQuery 1 - and I just found another hopeful sign in this post from Mozilla's Jonas Sicking:


We now have code checked in to support some parts of EXSLT
These functions will be supported in the upcoming Firefox 3
release (sorry, no chance of backporting to earlier releases)

exsl:node-set
exsl:object-type
regexp:test
regexp:match
regexp:replace
set:difference
set:distinct
set:intersection
set:distinct
set:has-same-node
set:leading
set:trailing
str:tokenize
str:concat
str:split
math:min
math:max
math:highest
math:lowest


12 Comments

Devon
2007-01-30 12:43:41
I should be excited but I'm not. Why doesn't Mozilla work on supporting XSLT 2 before they work on extensions to the language? That's almost like IE improving CSS support but still won't support a <q /> element. I'd (by far) prefer to see a standard implemented further, before extensions are worked on.... even if the extensions are a sort of standard.
Kurt Cagle
2007-01-30 13:01:08
Devon,


If it's any consolation, I agree with you whole-heartedly here, but given the comparative indifference that I encountered in the past to upgrading the XSLT processor, even this step is not insignificant. The challenge right now is to find someone willing to take on the burden of implementing an XSLT 2.0 processor on the Mozilla stack, as such a processor would definitely need to be reimplemented from scratch (the underlying data model that Transformiix used wouldn't support it).

Aristotle Pagaltzis
2007-01-30 16:40:54
Devon: out of you curiosity: have you written XSLT transforms? (In both versions of XSLT?) Do you know the relative merits of the standards?


Personally I think the Mozilla decision is eminently sensible. EXSLT mostly consists of extensions that retrofit almost everything that you'd want from XSLT 2.0 on XSLT 1.0, so it's not like the Mozilla folk are spending time on frills while ignoring crucial functionality. XSLT 2.0 suffers from massive Second System complexity. Even Microsoft declined to implement it, not least since noone actually cares about it. And that's because XSLT 1.0 is Good Enough for most needs; and XSLT 1.0 + EXSLT is Good Enough And Then Some for just about everything.


Bigger version numbers don't mean anything by themselves.

Aristotle Pagaltzis
2007-01-30 16:56:38
Kurt: I have to say I'm disappointed that they elected to skip the date functions. :-( I hope they just postponed implementation for those, rather than choosing not to support them at all.


However, it remains excellent news nonetheless. EXSLT's string processing facilities in particular have made me reluctant to restrict myself to plain XSLT 1.0, and of course exsl:node-set is indispensable.

Kurt Cagle
2007-01-30 17:21:13
The date functions would have been nice, but they also open up a whole can of implementation worms.


I would also concur about the decision. Right now the primary goal in development is getting the committed features of 3.0 done on the promised timeline; the EXSLT extensions are a nice-to-have, especially if you're doing heavy AJAX based work and would like a more solid XSLT processor on the client, but I don't see any real benefit at this stage for them to implement XSLT 2.0 (not that I wouldn't like to see it, mind you).


The only point I don't agree on is XSLT2 itself. I find that the change in model makes a radical difference for the better wrt complexity and verbosity in transformations. 60-70% less code for the same effect, a consistent extension mechanism, a more rational data model. However, I also suspect that if history is any guide, XSLT2 will first find its niche on the server and only over time will it migrate to the client.

St├ęphane Bortzmeyer
2007-01-31 05:10:20
Besides date:* functions, I will also miss str:encode-uri which I find mandatory :-(
John Perkins
2007-03-21 11:10:34
Are Firefox, Opera, or Safari planning any support for the equivalent of the XPath 2.0 document-uri() or base-uri() functions inside XSLT prior to adopting XSLT 2.0?


Does libxslt support using func:script?


The ability to get the browser url including parameters using xsl:script internal to the XSLT 1.0 transformation inside IE is very powerful.


I use the parameters from the url to support persistent style sheets and to indicate the "page" to display for a given XML that represents in some sense several pages.


Also, is Safari 3.0 planning support for XSLT transformation inside javscript? I understand this to be the case but have not seen it confirmed.


Thank you.


Alpa
2007-04-16 01:24:44
Hey Kurt,


Your Blog rocks!! Just wanted to share something with ya... one blogger to another...
There is this amazing site that I came across where u can make money by sharing information...check it out here's the link http://www.myndnet.com/login.jsp?referral=alpa83&channel=al266


The coolest part is...every time ur information gets sold u get paid for it!!
I signed it for it.. very cool stuff... u can also mail me at barot.alpa@gmail.com


Cheers!
Alpa

Franklin
2007-06-16 15:15:54
Thanks for your great site! Visit my sites, please:
Franklin
2007-06-16 15:15:59
Thanks for your great site! Visit my sites, please:
Dean
2008-02-07 13:12:05
Testing this out
Jessica
2008-08-05 04:24:56
I must admit it is an awesome site! Thanks for such a great site!! Pretty informative. It is marvelous!!! Have a nice time, on1313 mpjnym.