Would you like to see XSLT1.1 + EXSLT in .NET2?

| 2 Comments | 2 TrackBacks

Hey, I've got another idea. XQuery and XSLT2 are surely huge undertakings (we can truly thank W3C for that), but still there is plenty of plain poor .NET devs struggling with limitations of XSLT 1.0 and XPath 1.0. What if Microsoft implements XSLT 1.1 + EXSLT in .NET 2.0, would you like to see it?

XSLT 1.1 is that officially frozen XSLT version, which was supposed to improve XSLT in an evolutionary way - by solving only the most irritating problems in XSLT 1.0. Changes from XSLT 1.0 are small: that nasty result tree fragment data type is eliminated, so no need for xxx:node-set() function; XML namespaces quirks are fixed; support for XML Base is added; multiple output is supported via new xsl:document instruction; xsl:apply-imports can have parameters; standard way to define embedded extension functions is defined - xsl:script; new "external object" data type is defined for better interop with extension languages.

No big deal to implement IMO, but what a relief for .NET devs working with XSLT. And it's quite stable - XSLT 1.1 isn't Recommendation actually, but it's oficially frozen and won't change anymore. Saxon and jd.xslt support it. And implementing EXSLT would provide rich function library to allow XSLT developers to be much more productive by eliminating the boring needs every time to reimplement from scratch such trivial tasks as string tokenizing, formatting dates or getting list of unique values. EXSLT.NET project proves it's pretty implementable.

Yes, one can use EXSLT.NET right now, but EXSLT.NET library has some serious limitations. It's perf and security problems I'm talking about. The main problem is about how EXSLT.NET is implemented. Main idea behind EXSLT was that XSLT vendors would implement it, while EXSLT.NET is just external layer on top of the XslTransform class. It's implemented as user extension functions, not system extensions like msxsl:node-set() function. Hence - awful lots of reflection work is done during each function call and on returning a node-set and of course FullTrust security demand, which makes EXSLT.NET plain useless in any not fully trusted environment such as ASP.NET. All these problems could be fixed easily by just moving EXSLT.NET into the core of the XSLT implementation - it would make it faster, safer and more reliable.

Well, just an idea to evaluate actually.

Related Blog Posts

2 TrackBacks

TrackBack URL: http://www.tkachenko.com/cgi-bin/mt-tb.cgi/377

Would you like to see XSLT1.1 + EXSLT in .NET2? As an official member of the <XSLT:Blog/> "Legends of the XSLT Community" I generally tend to pay attention and respect what Oleg has to say in regards to XML/XSLT and... Read More

: Food for thought - brought to us by the legendary Oleg Tkachenko" href="http://www.nzlinux.org.nz/blogs/index.php?p=78">Visions of Aestia � : Food for thought - brought to us by the legendary Oleg Tkachenko I don't think I will ever tire of finding... Read More

2 Comments

Hey, Oleg!

I'm personally pushing to see Microsoft implement XSLT 2.0, if only because there are some (huge) advantages in having the largest software company in the world endorse a simpler, more consistent standard in transformation languages. However, given that a fair amount of this functionality is currently in XSLT 1.1 + EXSLT, I would agree with you in wishing to see this happen if they continued to argue that XSLT 2 is unimportant. Functional expressions, randomizers, multiple output streams and so forth would definitely make the task of writing XSLT apps easier, though I'm also inclined to suspect that IF they are going to do that, then the jump to 2.0 is NOT that far.

-- Kurt

Absolutely. Something needs to be done. Most of the performance issues I face are simple tasks in any other language. Don't get me wrong, I love working with XSLT. They need to throw us a bone every now and then.

Leave a comment