[xsl] LINQ to XML versus XSLT

["Jesper Tverskov" <jesper@xxxxxxxxxxx>]

Hi XSL-list

LINQ to XML versus XSLT

I guess that we all agree that the new LINQ to XML API is the greatest
thing to happen to XML for a very long time. For an introduction see:
".NET Language-Integrated Query for XML Data",
http://msdn.microsoft.com/en-us/library/bb308960.aspx.

I have no doubts that in the .net world LINQ to XML will replace
XmlWriter, W3C DOM and make XQuery mostly irrelevant. In .net we still
need XmlReader for SAX like programming and validation. For us at this
XSL-list the interesting question is how good LINQ to XML is to make
XSLT-like transformations.

Even for the simplest transformations, "fill in the blanks", LINQ to
XML, in my experience, only comes in second. But considering the
benefits of an almost "all-in-one" API for XML being a special
implementation of a more general API for any data, LINQ, and that we
in LINQ to XML have the unlimited direct power of a general
programming language like C#, etc., XSLT needs to be at least twice as
good to make it worth learning and to make it worth adding also an
XSLT processor and XSLT stylesheets to your project, if you already
have and know LINQ to XML.

Until a few days ago I thought that LINQ to XML programming would
never be capable of hardcore transformations like transforming
WordProcessingML to XHTML. But now we have Eric White's Blog, "Using
Annotations to Transform LINQ to XML Trees in an XSLT Style (Improved
Approach)", http://blogs.msdn.com/ericwhite/. Also read comments of
Sal Mangano and replies.

Extremely interesting except that it is not correct that "The first
rule that matches is the one that is applied", should be (in most
situations): "The most exact". The weakness of this latest attempt of
imitating XSLT transformations in LINQ to XML is that it is just an
experiment trying to reinvent XSLT and to prove that even advanced
XSLT-like transformations can be done with LINQ to XML. That is
fascinating reading but still a far cry from a uniform way of doing
things nice and easy, constituting a realistic alternative.

I feel that the limited nature of XSLT is also its strength. It being
a standard is unique at least for now, its stylesheet approach,
templates and recursion, is unique, it being itself XML is unique,
making it possible for XSLT also to transform XSLT and to create new
markup the true literal way (it must be well-formed), making XSLT
literal result elements easier to create and understand compared to
pseudo xml literals in variables, etc.

But just like we have many programming languages for anyone in any
situation, I can live with the idea of having several ways of doing
XSLT-like transformations.

Cheers,
Jesper Tverskov
http://www.xmlplease.com