Transforming XML

XSLT is one of the most successful and heavily used XML technologies, primarily due to the fact that it is a complete programming language for manipulating XML. In the world of data where XML is flowing between applications on a network, we need to process and reshape this data in accordance to some schema (whether explicitly through the use of an XML schema or DTD, or implicitly without a schema) so that people can share data.

In such a diverse world, no one is going to agree on a single data representation for a person, an invoice, or an address. This is where XSLT comes into its own by allowing different data representations to evolve independently, and then, through a transformation process, reshaping one XML structure into another. There are many reasons why XSLT is used; however, the reasons typically fall into one of the following categories:

• Structural transformation: Sometimes referred to as "fixed schema to fixed schema transformation," this is where you are transforming from one XML structure into another. For example, you may be transforming from your private schema into a public industry-agreed schema standard such as XML Business Reporting Language (XBRL). This is the most common usage scenario for XSLT and the one that people think of most often. Microsoft's BizTalk Server 2004 is an example of this type of transformation, where a schema mapping tool is used to generate an XSLT stylesheet.

• Content publishing: This is the separation of content from display information for the data. XSLT can generate more than just the XML outputs mentioned for structural transformation. It is also ideally suited for content publishing in the form of HTML, Scalable Vector Graphics (SVG), various wireless application protocols such as WAP, andlooking to the futureMicrosoft's XML Application Markup Language (XAML), which is part of Windows Presentation Foundation, the UI model for Microsoft's future operating systems. Today, Microsoft's Office 2003 InfoPath application can be considered an example here because it uses XSLT to generate HTML pages for data publishing and retrieval.

• Data-driven documents or sites: Many large Web sites (e.g., MSN) must cope with issues such as globalization and personalization, and they cannot have an army of people continually editing sites to deal with the constant flow of new information. XSLT is ideally suited to building data-driven Web sites where the page's layout changes based on the type of content received. The Microsoft Office 2003 FrontPage application is an example, wherethrough the use of data connectors that map data into XML (e.g., relational data stored in a database)it is possible to build Web sites that change automatically depending on the flow of information. This includes the ability to reorder, filter, sort, and group parts of a document or to display only the part that is relevant to a particular user's profile.

It is also worth understanding what makes XSLT such a powerful programming language. XSLT is described as a declarative language as opposed to most modern object-oriented programming languages such as C# and Visual Basic, which are procedural. Procedural languages have step-by-step operations, holding on to the previous state in order to execute the next statement. Declarative languages, on the other hand, are more like a set of rules or patterns that describe what should happen if a certain condition is matched. XSLT describes a set of rules for ways that the transformed document relates to the original document. The difficulty comes in that, due to human nature, training, or both, XSLT tends to be harder to grasp than object-oriented languages because you have to "see" the pattern matching as opposed to "reading" the code like sentences in a book. In reality, in application development, you end up using a combination of both procedural code, via XML APIs such as the XmlDocument (XML DOM), XmlReader, and XmlWriter, plus XSLT for the parts that need to be more flexible.

Luckily, the world of XSLT programming has been made significantly easier in Visual Studio 2005 with the introduction of an XSLT debugger that is integrated into the development environment.

As an example, suppose you have the shippers data shown in Listing 7.2 which uses elements, and you need it in attributed form (as shown in Listing 7.3). You could create an XSLT file to transform it, as shown in Listing 7.9.

A description of XSLT is outside the scope of this book (it's a book in itself), but for a quick explanation, it revolves around templates, where a template matches a target. A target is generally an element or attribute, and the code within the template dictates what the output iselements or attributes, or even HTML. In the example just presented, each of the elements representing ShipperID, CompanyName, and Phone are converted to attributes of the shipper element. The new attributes have new names to make it clear that a transform is happening.

Debugging XSLT in Visual Studio 2005

XSLT can be a confusing language to work with, especially if you don't have much experience of recursion, but Visual Studio 2005 aids in this by providing an XSLT debugger. To debug XSLT you need to specify the input filethe XML that is going to be transformed. You can do this by opening the XSLT file and setting the Input property to the file being transformed (see Figure 7.7).

Figure 7.7. Setting the Input file for XSLT

Listing 7.9. Transforming Shippers Elements to Attributes

<?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet version="1.0"     xmlns:xsl="http://www.w3.org/1999/XSL/Transform">      <xsl:template match="shippers">     <shippers>              <xsl:apply-templates select="shipper" />           </shippers>      </xsl:template>      <xsl:template match="shipper">           <xsl:element name="shipper">              <xsl:apply-templates select="ShipperID" />              <xsl:apply-templates select="CompanyName" />              <xsl:apply-templates select="Phone" />           </xsl:element>      </xsl:template>      <xsl:template match="ShipperID">           <xsl:attribute name="id">              <xsl:value-of select="."/>           </xsl:attribute>      </xsl:template>      <xsl:template match="CompanyName">           <xsl:attribute name="name">              <xsl:value-of select="."/>           </xsl:attribute>      </xsl:template>      <xsl:template match="Phone">           <xsl:attribute name="phoneNumber">              <xsl:value-of select="."/>           </xsl:attribute>      </xsl:template> </xsl:stylesheet>

Once the input file is defined, you can set breakpoints in the XSLT file, just like breakpoints in code files. To debug the file, you select Debug XSLT from the XML menu; you may receive a warning that the output file already exists, asking if you wish to overwrite it. This is because the output is written to a file, and if you have already run the XSLT, the temporary file already exists. Once running, the screen splits into two with the XSLT on the left and the output on the right. Breakpoints suspend processing (see Figure 7.8), and you can use the step over and step into debugging commands to step through the XSLT to see how it processes the file.

Figure 7.8. Debugging XSLT

Transforming with the XmlDataSource Control

To use and transform XML within ASP.NET pages, you can use the XmlDataSource control and its TRansformFile property, which you set to the name of the XSLT file, as shown in Listing 7.10.

Listing 7.10. Transforming XML Using the XmlDataSource Control

<asp:XmlDataSource  runat="server"   DataFile="~/ch07/shippers.xml"   TransformFile="~/ch07/ShippersAttributes.xsl" /> <asp:TreeView  runat="server"   datasource>   <databindings>     <asp:treenodebinding datamember="shipper"       valuefield="id" textfield="name" />   </databindings> </asp:TreeView>

In this example, the transformFile is applied to the DataFile before the data is presented to bound controls. So the treeView binds to the new attribute names rather than the old.

Transforming in Code

If you have a business or data layer that provides all data to the UI layer, you may not want to perform transforms within ASP.NET pages. Architecturally, a transform should really live in the data layer, so there is a full API for dealing with transforms; this is the XslCompiledTransform class, which lives in the System.Xml.Xsl namespace.

There are two simple methods on the XslCompiledTransform class. The first, Load, loads an XSLT file, while the second, TRansform, performs the transformation. There are several overloaded forms of TRansform, allowing a variety of output targets and parameters, such as the input and output file names. Listing 7.11 shows TRansform with three parameters: the first is the file to transform, the second is a parameter list (in this case null), and the third is the output (in this case a StringWriter instance). The contents of the StringWriter are then displayed in a TextBox control.

Listing 7.11. Transforming XML in Code

StringWriter writer = new StringWriter(); XslCompiledTransform transform = new XslCompiledTransform(); transform.Load(Server.MapPath("ShippersAttributes.xsl")); transform.Transform(Server.MapPath("shippers.xml"), null, writer); transformedXML.Text = writer.ToString(); writer.Close();

The XslCompiledTransform class supports a number of advanced features, such as script support, parameters, and extension object, all of which are outside the scope of this discussion. If you'd like to learn more about this topic, there is a chapter on transforming XML in the Addison-Wesley book ADO.NET and System.Xml v2.0The Beta Version. While aimed at beta 2 of .NET 2.0, most of the content is still suitable for the released product.

The XslCompiledTransform class doesn't replace the XslTransform class but provides a number of additional features, one of which is vastly improved performance. If you are considering migrating applications to .NET 2.0, you should use the compiled class to achieve best results.