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.
/filters:no_upscale()/sponsorship/topic/25afca57-6bcb-4c42-9a70-fbea10ce4fc7/MicrosoftLogoRSB-1678874949003.png)
/articles/asp-dotnet-minimal-apis/en/smallimage/logo-1678972581766.jpg){kind=logo}
/articles/functional-dotnet-development/en/smallimage/Fsharp-vs-Csharp-is-one-more-functional-than-the-other-small-1676023056578.jpg)
/articles/dotnet-grpc-json-transcoding/en/smallimage/logo-1674822319367.jpg){kind=logo}
/articles/Dotnet-Seven-MSMQ-Alternatives/en/smallimage/logo-1670585778128.jpg){kind=logo}
/articles/polygot-microservices-dapr-aks/en/smallimage/logo-1666079703389.jpg){kind=logo}
/articles/finops-systems-thinking-lens/en/smallimage/12-places-to-intervene-rethink-FinOps-using-a-systems-thinking-lens-small-1679995317220.jpg)
/articles/secure-software-development-gitops/en/smallimage/accelerating-secure-software-delivery-lifecycle-with-GitOps-small-1679658720410.jpg)
Community comments
Only VB though
by Francois Ward,
Re: Only VB though
by Hartmut Wilms,
Another option is to use JavaScript / EcmaScript 4 XML (E4X)
by Paul Fremantle,
microsoft's at it "again"
by Miguel de Melo,
Re: microsoft's at it
by Angus McDonald,
Only VB though
by Francois Ward,
Your message is awaiting moderation. Thank you for participating in the discussion.
XML literals are VB only though...so C# devs still go the old fashionned way (or with LINQ to XML i guess). Plus with XSLT, you have a standard reusable template, which will still be usuable the day we migrate from .NET to the "Next Big Thing(tm)".
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
by Hartmut Wilms,
Your message is awaiting moderation. Thank you for participating in the discussion.
I have to agree with Francois, XSLT may be used in a myriad of ways. For instance XSLT can be used to transform artefacts within an MS Build script in order to generate code/XML/... from models.
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 ...
Another option is to use JavaScript / EcmaScript 4 XML (E4X)
by Paul Fremantle,
Your message is awaiting moderation. Thank you for participating in the discussion.
I routinely use JavaScript/E4X (Wikipedia Entry) which is a standard extension to JavaScript. It is available in both the Rhino (Java) and SpiderMonkey (C) implementations of JS and means that you can embed simple XML scripting into many applications. It is also available in Adobe Flash, AIR, Acrobat and Flex. The Apache Synapse ESB allows you to use it as an alternative to XSLT when transforming XML messages, whether they are in a filesystem, JMS destination or coming via HTTP POST or GET.
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"
by Miguel de Melo,
Your message is awaiting moderation. Thank you for participating in the discussion.
Surprise surprise, Microsoft just went out of their way to break yet another standard, and give it some fancy name. The so originally called "XML Literals" looks remarkably identical to the just W3C Standard XQuery, that the rest of the XML community have been working on so had together for years, to make sure it works for everyone, and so that we all agree on a common path.
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
by Angus McDonald,
Your message is awaiting moderation. Thank you for participating in the discussion.
Miguel,
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.
Cheers,
Angus