XSLT 2.0 might be worth a second look, if...

XSLT 2.0 Is Way Cool, by Micah Dubinko

Micah. Kimber. Pawson. A handful of the folks who have, like me, turned up their nose at XSLT 2.0, are starting to reconsider. This is not a massive drugging campaign by XSLT 2.0 boosters: it seems all these folks still don't want anything to do with the oppressive type system of XPath and XSLT 2.0, and all balk at the stupendous complexity of the specifications. The key to me is that they see these specs as usable without choking on the types mess. Some folks were claiming this was possible 2 years ago or so, but when I checked, I wasn't convinced. Perhaps things have improved since then.

So I may be up for reconsidering my shunning of XSLT 2.0, but as Micah mentions, I'm not about to wade into 9 documents to work on implementation. (OK, so it would really be 4 or so, but those are 4 huge documents, compared to the 1.0 series, which was 2 modestly sized documents). If someone comes up with a coherent spec that omits the type info, it could somehow make its way into the 4Suite post 1.0.

Micah says, "XSLT 2.0 is a power tool. I don't think it will displace XSLT 1.0, which is remarkable for its power in a small package." For a while I've wanted to write a series of comparisons between XSLT 2.0 and Amara code (which includes XPath 1.0 support). Amara is my power tool, for when XSLT 1.0 + EXSLT is not enough, and I find it hard to imagine XSLT 2.0 as offering more power.

And I really need to get back to work on EXSLT. Folks are getting very restless with the fact that work on EXSLT has been fallow for most of 2005. I just wish I could count on some help. Part of what impedes me is a shrinking back from all the demands of the EXSLT community without many offers of help.

[Uche Ogbuji]

via Copia
Upvote Upvoted 0
15 responses
Could you please post references to more information on the type of help you need with EXSLT?  What kind of help are you looking for, and why has the community been less than responsive?
— John L. Clark
Hi Uche,



For the most part, I've been cherry-picking the fun stuff in XSLT 2.0 and avoiding the heavier stuff, and I've found plenty to play with. I put together a page of links to my experiences with XSLT 2 (and its use of XPath 2) at http://www.snee.com/xml/xslt2.html.



Bob
— Bob DuCharme
> Micah. Kimber. Pawson



The difference between these people and you is that they are writing XSLT 2.0 applications and you are not.



It doesn't take big effort to learn to use XSLT 2.0 and this may not require even reading the specs. Mike Kay's two books on XSLT 2.0 and XPath 2.0 are an excellent resource and an essential reading.



From my experience I can state that anyone, who has put his fingers into XSLT 2.0 will only use XSLT 1.0 if forced (e.g. payed for it... :o)  ).



It is incorrect to compare the two languages  (, as XSLT 2.0 is a giant leap forward) as it wouldn't be correct to compare an old truck and a supersonic plane.



XSLT 2.0 adds more expressive power, more elegance and aestethics, coding with xsl:function -s and FXSL feels almost like writing in Haskell.





Cheers,

Dimitre Novatchev
— Dimitre Novatchev
Bob,



I understand that from a user's point of view it's straightforward to just cherry-pick the good stuff in XSLT 2.0, but I should have clarified that I tend to look at such technologies with one eye as an implementor, and most of my comments were along those lines.  Goven that I can already do everything that XSLT 2.0 supports using either XSLT 1.0 + EXSLT, or failing that, Amara, it's hard for me to justify any effort spent on XSLT 2.0, even learning it, unless I feel it's worth implementing as a help to other users.



Dimitre,



You'll have to explain yourself better:



"The difference between these people and you is that they are writing XSLT 2.0 applications and you are not."



It seems as if you're trying to make a big point with that statement, but I guess I don't really get it.  If you mean "they're doing things in XML processing that Uche can't", then you missed the part in my posting where I point out that I can do anything with Amara that people can do with XSLT 2.0.
— Uche
John,



Watch this space.  I'm working on uour question right now.



--Uche
— Uche
Uche,



<Quote>

"The difference between these people and you is that they are writing XSLT 2.0 applications and you are not."



It seems as if you're trying to make a big point with that statement, but I guess I don't really get it.  If you mean "they're doing things in XML processing that Uche can't", then you missed the part in my posting where I point out that I can do anything with Amara that people can do with XSLT 2.0.

</Quote>



Nowhere I said that what one can do cannot be done with XSLT 1.0 + xxx:node-set()



In fact, it can be done with Assembler.



If we thought like this we'd still be using Assembler -- there wouldn't be even Fortran and C.



The reason that new languages are created and successful is not that with them something can be done that was not possible with the languages of the past.



The reason is that people tried the new language and loved it -- found that they can do the same task in a more natural and elegant style, that the language is naturally expressing and supporting a better model for solving this task.





Therefore, unless you really tried working with XSLT 2.0 and got some real experience with it, commenting about the value of XSLT 2.0 and comparing it to other languages has little real value.



Cheers,

Dimitre
— Dimitre Novatchev
Dimitre:



"Therefore, unless you really tried working with XSLT 2.0 and got some real experience with it, commenting about the value of XSLT 2.0 and comparing it to other languages has little real value."



Ah.  OK.  Well, I have tried XSLT 2.0.  That was nearly two years ago, of course, and though I could feel that some things were easier than in XSLT 1.0, the advance wasn't earth shattering to me.  Also, I've followed Bob Ducharme's series and thus I've seen a good deal of XSLT 2.0.  Again, I see good points, but nothing to immediately wow me.  As an example, doing so much XML processing with Python, I find it hard to be too impressed with the ballyhooed analyze-string.



As for the "assembler" comment.  That's cool if you want to miss the pint, but just for others, I'll spell it out in alphabet blocks.  Python is a language that a lot of people find extremely productive, including me.  This means that If I can find Python tools that give me the expressive poer I need with XML, the attraction of XSLT 2.0 is pretty slim.



Python does need help from the XSLT world to really come into its own with XML processing, and that kick it needs is pretty much completely represented within XPath 1.0.



Actually this discussion has pretty much reminded me that I don't really have a reason to want to implement XSLT 2.0.  I think we needed XSLT 1.0 to entice people to the Python tool-chain for XML processing, but I don't see the incremental attraction for such people in XSLT 2.0.  As such, I'd rather work on better Python/XML integration (and stuff like EXSLT).  I don't begrudge others the exciting stuff they see in XSLT 2.0, and remember that I was an enthusiastic supported of XSLT 1.0.  But in terms of simple utility, XSLT 2.0 just isn't there for me yet.
— Uche
Uche,



I have been arguing against the inclusion of type inclusive material in XSLT2 practically from the spec's inception, and one of the beauties of the most current implementation is that you can actually avoid using nearly any type-specific API within XSLT2 and STILL be able to write just about anything with it.



Michael Kay's division of Saxon into 8.4 and SA models actually work reasonably well by this principle - if you REALLY need type support (for instance, in the creation of PSVI objects, a somewhat dubious endeavor anyway) then you can get it, albeit at some cost. If your goal is simply to transform XML more easily and efficiently, then I would (and have) recommended XSLT 2 over XSLT 1 whenever possible. As a Python user with some fairly major contracts, I'd lap up a Python XSLT2 processor in a heart-beat.



-- Kurt
— Kurt Cagle
Kurt,



Thanks for your notes.  The clarification that the type system is not necessary for implementation is key, and is one they have been way too slow to provide.  I have gathered that they fixed that aspect of XPath 2.0 since the last time I closely reviewed it.



It would be very useful for me to know in what ways you would find it the Python/XSLT 2.0 combo particularly handy.  Would you look forward to writing Python extensios for XSLT 2.0?  Would you look forward to an implementation you can readily tweak?  Or is it just attractive to be able to use something written in a preferred language?



Thanks.
— Uche
Uche,



Everybody has the right to use whatever languages and tools suits them best. It is perfectly natural that some people will love XSLT 2.0 and some (like you) will not.



However, I get the feeling that the purpose of your blog article is to influence other people into taking your opinion for granted. Especially when you use the "we" pronoun in your next blog article.



I am a supporter of EXSLT and have made a proposal for introducing the "exslt:memo-function" attribute on xsl:function .



Yes -- exslt for XSLT 2.0.





Cheers,

Dimitre.
— Dimitre Novatchev
Uche,



Everybody has the right to use whatever languages and tools suits them best. It is perfectly natural that some people will love XSLT 2.0 and some (like you) will not.



However, I get the feeling that the purpose of your blog article is to influence other people into taking your opinion for granted. Especially when you use the "we" pronoun in your next blog article.



I am a supporter of EXSLT and have made a proposal for introducing the "exslt:memo-function" attribute on xsl:function .



Yes -- exslt for XSLT 2.0.





Cheers,

Dimitre.
— Dimitre Novatchev
Copia Ok. I'm up to the challenge. I think its safe to assume that Uche knows a thing or two about programming. So, in reality, a simple list of features and capabilities that need to be present should be more...
— Trackback from
>>It would be very useful for me to know in what ways you would find it the Python/XSLT 2.0 combo particularly handy.  Would you look forward to writing Python extensios for XSLT 2.0?  Would you look forward to an implementation you can readily tweak?  Or is it just attractive to be able to use something written in a preferred language?<<



I've been working with a couple of other developers putting together a medical evaluation application with a previous history where the XML existed primarily as a serialization format, despite the fact that many of the requirements for the application practically begged for a more formal XML treatment.



After a fairly stormy meeting we decided to create a proof of concept of a new direction for the application using 4Suite's XPath and XSLT capabilities.  This dramatically enhanced what could be done with the application.



The XLST2 implementation request comes into play for a couple of reasons. XSLT1 does not support regular expressions, even though there were several points where regexes could have been critically useful in both generating output and performing evaluation processing.



XSLT2 also has a more functional orientation (pushing the invocation of functions out of &lt;call-template&gt; and into XPath expressions, significantly reducing the calling syntax for functions - this is aided and abetted by the uniformitization of external function invocations from XPath, which would have made it easier to bind Python calls directly to the transformation (again something which came into play, as there were a number of information passing routines that would have been useful to call directly from the transformation itself).



Finally, XSLT2 provides for a more robust sequence model that makes it easier to induce non-XML-node iterators into the mix (such as an index that iterates from 1 to 10 - something that gets cumbersome to write in XSLT 1, and that invokes a fairly dramatic degree of recursion stack processing when the iterator stack-size gets large.



As a note - most (though not all) of the EXSLT changes have ended up in XSLT 2. I think that most of the principles of both groups (and there's a significant overlap) would concur that XSLT 2.0 has an entirely unnecessary type layer overlaid on it that has been put there largely (and I suspect with malice aforethought) by the database vendors who can't seem to think that anyone would see any value in meta-typing and much prefer "explicit" typing.



That does not diminish the capabilities of the rest of the standard at all (tokenize() by itself is worth the price of admission), but only serves to point out that standards tend to emerge not because a given standard is the best possible choice, but instead may be the most politically expedient one.



As to your questions - YES, I would be willing to work with you to help implement an XSLT2 layer in Python, as I think it may prove beneficial to us as well to have such an engine implemented within the Python/4Suite application. Contact me offline at kurt.cagle@gmail.com and we can discuss it in more detail.



-- Kurt
— Kurt Cagle
Dimitre,



OK.  I think we're cool.  I'll ease off on the baiting, if we can agree to stick to the specific technical consideration of implementing XSLT 2.0 rather than broad advocacy.



Kurt,



Your post and M. David's entry is one of many that are the key issue as to whether or not to work on XSLT 2.0.  I'm definitely hot on the idea again (quite an XSLT 2 roller-coaster for me past coupla days).  Never mind the language politics: it's the community that makes such ventures worthwhile.



Thanks.
— Uche
Interesting entry and comments. I am too new to the XSLT world to have any opinion on XSLT2 but two things :



1. From what I've seen, XSLT2 brings really interesting features but I'm not sure to get the why of some of them since they don't bring anything that already exist in the language you could use to handle XSLT. I mean regex are great but almost all modern language already support them.



2. I don't think the 4suite guys ever stopped anyone to contribute. Simply because Uche is reluctant to involve his time into bringing XSLT2 to 4Suite doesn't mean you cannot do it by yourself and let the Python community have it :)



The 4suite guys are pretty open to help :)
— Sylvain
Add Website URL »