Using Annotations to Transform LINQ to XML Trees in an XSLT Style (Improved Approach)

A E » Blog Archive » Using Annotations to Transform LINQ to XML Trees in an XSLT Style…

Tue, 24 Jun 2008 01:48:08 GMT

PingBack from http://ae.morelyrics.co.uk/2008/06/23/using-annotations-to-transform-linq-to-xml-trees-in-an-xslt-style/

re: Using Annotations to Transform LINQ to XML Trees in an XSLT Style (Improved Approach)

Oran — Tue, 24 Jun 2008 03:05:42 GMT

Very cool! Do you have performance metrics comparing this technique to XSLT?

It would be so cool if you could talk the BizTalk team into making the BizTalk mapper output this instead of XSLT.

re: Using Annotations to Transform LINQ to XML Trees in an XSLT Style (Improved Approach)

EricWhite — Tue, 24 Jun 2008 03:29:47 GMT

I don't yet have performance metrics. There is an open source XSL that does a fairly comprehensive transform of an Open XML document to html. I'd really like my DocxToHtml.cs to be as comprehensive as the XSL version. At that point, it would be fair to compare the performance of the two.

Right now, the only transforms that I have are the trivial ones presented in this post, as I just wrote this code over the weekend. It wouldn't really be meaningful to define the same transformations in XSL and compare perf - an XSL transform must fire up the XSL transformation engine, which is a fixed perf cost for every transform.

As I improve the DocxToHtml transform, I'll certainly post the improved code. And when it is comprehensive enough, we'll get numbers.

I'm going to make a bet, however, that this code will perform very well when compared with XSLT.

re: Using Annotations to Transform LINQ to XML Trees in an XSLT Style (Improved Approach)

Sal Mangano — Wed, 25 Jun 2008 00:00:26 GMT

XSLT has a lot of very important ideas that are locked up in an unfortunate syntax. Any effort to extract these ideas into a cleaner environment is a good one. However, I see nothing in your demonstration that convinces me you have accomplished this and certainly nothing to suggest:

"LINQ to XML to transform XML trees with the same level of power and expressability as with XSLT, and in many cases more than with XSLT."

Can you elaborate how this has the more power and expressability than XSLT?

re: Using Annotations to Transform LINQ to XML Trees in an XSLT Style (Improved Approach)

EricWhite — Wed, 25 Jun 2008 00:44:55 GMT

Hi Sal,

Yes, XSLT is very powerful, and has many important ideas in an unfortunate syntax. To me, the most important ideas are:

- pattern matching / application of templates

- ability to specify a transformation for a node, while applying further transformations deeper in the tree

- when used properly, a pure, stateless functional approach

Using this approach, LINQ also can use pattern matching to select nodes to transform, and ability to specify transformations for any node, while applying further transformations deeper in the tree. And of course, with lambda expressions, extension methods, deep support for generics, etc., LINQ/C# 3.0 syntax certainly supports a natural syntax for a pure functional approach. I personally find the syntax of LINQ, and of LINQ to XML easier to read and write than XSLT, hence the expressability. I also consider the much richer type system in C# to be something that also adds to the power and expressability.

With regards to power, the last example presented in this post includes referencing data that is contained in some C# objects. If attempting this transform with XSLT, you must first serialize this data into XML and then use the XML in a transformation, or you must escape into an external language to retrieve the data. Using LINQ to XML, you can write one single, pure, functional transformation that can use data from anywhere in the .NET stack. You could write a pure, functional transformation that uses data from a database, the file system, XML of course, JSON, web services, etc., etc.

There are downsides to using LINQ - the language doesn't enforce a pure functional approach. You can easily break purity by mutating variables, etc. In contrast, with XSLT, you have try hard to write impure code.

What has been missing in the C# 3.0 / LINQ conversation is a technique for expressing the pattern matching / templates approach. This post describes my approach for doing this.

-Eric

re: Using Annotations to Transform LINQ to XML Trees in an XSLT Style (Improved Approach)

Sal Mangano — Wed, 25 Jun 2008 03:54:54 GMT

I think the features of XSLT you reference are imporant but what makes an XSLT solution more powerful in the domain of XML -> XML transforms are "Literal Result Elements" which are cleaner syntactically than "new XElement(...)". XSLT 2.0 also has a much richer facility for specializing templates then you imply in your post (multiple modes, xsl:next-match, xsl:import, named templates, priorities, etc.) Also, using a subset of XPath as a pattern language is very powerful.

Your LINQ based approach is far too procedural for my tastes.

However, outside of XML -> XML, XSLT starts to trip over itself.

re: Using Annotations to Transform LINQ to XML Trees in an XSLT Style (Improved Approach)

EricWhite — Wed, 25 Jun 2008 08:52:57 GMT

I agree with you that sequence constructors have a cleaner syntax than newing up XElement objects. And I agree that literal result elements are nice for simple transforms to XHTML. XML literals in VB are pretty cool, except that I just happen to prefer C#. I saw the issues that came up when introducing XML literals to VB - they were not trivial. I prefer C# without the literals. There is a syntactically minimalist approach to constructing LINQ to XML trees in C# - I haven't used it for some time, but it can serve to reduce syntactic noise. I might have to play with it again, and see if it helps. I personally don't mind using XElement/XAttribute constructors. But this is a good point.

xsl:include and xsl:import are examples of composability, and C# 3.0 used in a functional style takes composability to a high level.

Multiple modes are handled in C# with a dictionary. The implementation is trivial - no modifications to this little library is needed. Same with priorities - add tuples to a dictionary, select ordered results using LINQ expressions. I'd have to write out the code to show you exactly what I mean. But would be another blog post.

Regarding XPath vs LINQ query expressions, have to tell you, I've written more of both than I care to count. I prefer LINQ. Others might prefer XPath.

Actually, there is very little procedural code in these examples. Basically, the transform doesn't care what order you add the annotations, unless you are adding the annotations in a specific order so that certain of the transformations take precedence over the others. When you refer to procedural code, what are you referring to? (Note: not being sarchastic or anything - too much is lost in written communication - I'm just asking because I'm curious about what you see. :-)

BTW, there is another way to write the foreach loops - write them using an extension method public void ForEach<T>(this IEnumerable<T>source, Action<T> action) ...

I changed the code to use foreach, because it is more accessible, and less strange to many developers new to FP.

re: Using Annotations to Transform LINQ to XML Trees in an XSLT Style (Improved Approach)

EricWhite — Sat, 28 Jun 2008 04:29:47 GMT

Sal,

This conversation has really provoked thought about how to specify these types of transformations in a more declarative way. This conversation has been very valuable to me, it has made me see this from another perspective. One thing that wasn't clear - I see the foreach iterations as just another form of a function call, maybe more accessible to some developers. So the specification becomes a collection of calls to functions, where each call does annotation of the source tree. So in my mind, I hadn't deviated from a pure, functional transform. However, the code LOOKS much more procedural. Rewriting the transforms using the ForEach extension method helps make it look less procedural. But there are ways to make the transformation specification even more declarative. I'm currently working on another iteration of the approach. Should be posted sometime in the next little while.

My only motivation here is think about new ways to do transformation, not to promote one technology over another.

I just have to say, there are scenarios where XSLT is a fantastic technology, and probably the only feasible technology. In certain scenarios, I consider XSLT as the only option. I personally know of examples they are using primarily a natively compiled XSLT processor; nothing else performs well enough.

Anyway, please don't take my ramblings as an expression of disrespect for XSLT. It is the wonderful ideas of XSLT that I have missed when writing LINQ to XML transformations.

And also, any ideas that I express are completely my own, and not Microsoft’s. :-)

-Eric

re: Using Annotations to Transform LINQ to XML Trees in an XSLT Style (Improved Approach)

Vishal Doshi — Mon, 30 Jun 2008 15:18:10 GMT

I'm pretty familiar with (and hence?) very comfortable with LINQ syntax. Not so with XSLT. I wonder if you could extend the above example to be a "LINQ to XML to XSLT" compiler?

It would so cool if say, I could use LINQPad to quickly write a transform and then have that magically compiled to XSLT (which is so much easier to release because you don't have to worry about .net 3.5 being installed etc, and will work on so many older systems etc )

[Open XML] Les liens de la semaine – 27/06/08

Julien Chable — Mon, 30 Jun 2008 16:36:11 GMT

Les quelques liens intéressants de la semaine pour vos projets Open XML : Technique : Custom XML : répéter

re: Using Annotations to Transform LINQ to XML Trees in an XSLT Style (Improved Approach)

EricWhite — Mon, 30 Jun 2008 17:01:12 GMT

Vishal,

In theory, it could be possible. The most work would be generation of XPath expressions from an expression tree. One issue - there are LINQ expressions that have no correlating XPath expression.

But it's a worthy activity to learn XSLT. I really appreciated the book by Michael Kay.

-Eric

re: Using Annotations to Transform LINQ to XML Trees in an XSLT Style (Improved Approach)

alex — Thu, 10 Dec 2009 17:58:48 GMT

What about following

- superscript subscript

- Table heading alignment - top - bottom centered..

Also it sometimes bolds text which is clearly not bold.

re: Using Annotations to Transform LINQ to XML Trees in an XSLT Style (Improved Approach)

Eric White — Fri, 11 Dec 2009 10:36:53 GMT

Hey Alex, I'm currently working on a much better conversion of word-proc docs to Html. I should be blogging on this in the next couple of weeks. But caveat, the first version will not contain formatting, just an accurate representation of content. I'm planning on completing the version with formatting sometime early next year.

-Eric