The End of XSLT for .NET Programmers?
Microsoft's VB team is starting a series of articles on how to use XML Literals. Many of these articles will demonstrate how to replace XSLT code with VB by making direct comparisons between the two languages.
XML Literals is a syntax first pioneered for Haskell and later brought to Microsoft for use in C#. Not finding a home in either language, the Visual Basic team snapped it up and made it a cornerstone of VB 9. This should not be too much of a surprise, as the Haskell syntax was heavily influenced by VBScript's inline HTML notation.
In the first XML Cookbook article, Doug Rothaus demonstrates the VB equivalents to XSLT's <xsl:copy-of>, <xsl:for-each>, <xsl:template>, <xsl:if>, <xsl:value-of>, and <xsl:attribute> elements. He also shows how to use XML Axis Properties in place of XPath.
Though the examples are simple, the VB versions are consistently shorter than the XSLT versions. Most of the gains are from moving away from XSLT's rather verbose syntax. Though not demonstrated here, VB also has an advantage in that you can call out to normal .NET code when needed.
Only VB though
For simple, one shot operations, sure... but if you have a business critical transformation process, why would you do it in normal code?
Re: Only VB though
XSLT might also be used in conjunction with Web Services that rely on XML (messaging) rather than Code-First Web Services.
Both use cases (and many more) are a natural way of handling XML and model transformations, independent of the implementation language.
I would hate to see MS Build files cluttered with calls to VB code, which implements transformations ...
I have used it on many occasions and I also find it much simpler and more effective than XSLT. I've been using XSLT for 9 years now, and I still have to reach for the manual or samples. But I can write a short, sweet, simple E4X transform in minutes. If you are using the Rhino implementation, you can even replace the default XMLBeans-based parser implementation with one based on Apache Axiom which gives a significant performance boost.
Finally, there is even an open source Mashup Server based on E4X. [Disclosure - I work for WSO2]
microsoft's at it "again"
Miguel de Melo
So I am not surprised they did it again, after all is part of Microsoft's philosophy, rip off what someone else is doing well, make it worse, and make a bucket out of it . . .
Re: microsoft's at it
It's got nothing to do with XQuery. It simply makes XML literals behave as objects that Visual Basic code can interact with in a more feature-rich way than simple string literals.
The VB team has combined that with the XML querying features of LINQ (which were designed to allow you to create an object interface to XML data files) to replace some of the operations XSLT allows.
The point is that a Basic developer now can now use the full power of the language when working with XML. This is in no way an attack on XQuery, it's just that there is no need now for it when using Visual Basic as your language of choice.