- Client-Side Versus Server-Side Transforms
- Java Servlet Transform
- JAXP and XSLT
- The XML Data Adapter
- Summary
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The XML Data Adapter
Now that we’ve seen how XSLT can take us from XML to HTML, it’s time to discuss how XSLT can take us from one XML dialect to another. XML-to-XML transformations are useful when you need data in a slightly different format and don’t want to rewrite software to cope with change. In the vocabulary of design patterns, we can use XSLT to build an XML Data Adapter.
To put the problem into context, let’s jump a bit into the future, where your success in establishing a web presence for ZwiftBooks has increased company visibility. Now EuroBooks, a European book distributor, has entered into an agreement with ZwiftBooks for rapid book delivery to Europe. EuroBooks sends ZwiftBooks an XML order, and ZwiftBooks responds expeditiously by getting the books on the next flight to the appropriate European city.
This arrangement has been wildly successful. Software has been developed to process incoming XML from EuroBooks. A problem has arisen, however. Another distribution company, AsiaBooks, is interested in setting up a similar arrangement, but they’re adamant about using a different XML format for their orders.
Figure 3 shows the EuroBooks and AsiaBooks XML. Notice that there are two significant differences:
- In the EuroBooks XML, isbn is an attribute; in the AsiaBooks XML, isbn is an element.
- The top-level element name for EuroBooks is request, while for AsiaBooks it’s order.
)
Figure 3 EuroBooks vs. AsiaBooks XML orders.
The ZwiftBooks programming staff claims that they’ll have to rewrite their code to handle the new data format, and complain that with two different data formats they’ll have to maintain two separate software versions, which will require additional staff. AsiaBooks is a big potential customer for ZwiftBooks, and they want to plug into the ZwiftBooks order system immediately. The programming staff requires at least several weeks to get things up and running. As the XML guru, you’ve been called in to help. What to do?
XSLT to the Rescue
Your solution to the problem of handling multiple XML data formats is four letters: XSLT. Rather than have the programming staff write new code to handle the new format, an XSLT transform adapter can be used to change AsiaBooks XML into EuroBooks XML, so that the existing software can be used to process the AsiaBooks order. This approach can be used to work with different customers (and can also be used to help manage data-format version control within an organization). Rather than having to support different implementations that depend on different data formats, an XML adapter can transform one data version to another. This approach can be especially useful in an agile development environment, where refactoring over several iterations is considered the norm.
To see how to set up such a transform let’s start with some XSLT that simply copies its XML input to output. Once we see how a complete copy is done, we can then focus on the parts we want to give special treatment—in our case, turning the isbn attribute into an element and changing the name of the request element to order.
The easiest way to copy something with XSLT is to use the <xsl:copy> element, which tells the XSLT engine to make a copy of whatever is in context. Listing 3 shows a simple style sheet that makes a pure copy of its input.
Listing 3 XSLT that copies input to output.
1. <?xml version="1.0" ?> 2. <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> 3. 4. <xsl:template match="node() | @*"> 5. <xsl:copy> 6. <xsl:apply-templates select="node() | @* "/> 7. </xsl:copy> 8. </xsl:template> 9. 10. </xsl:stylesheet>
Now the details:
- Line 4: Begins our rule that says to match "node ( ) | @* " (which we can read "as any node or attribute"). In XPath, nodes mean any element, CDATA section, comment, or processing instruction—but not attributes. Attributes are special; that’s why we need to say node or attribute in our match expression.
- Lines 5–7: Tells the XSLT processor what to do when it finds a node or an attribute: Copy it (in XSLT parlance, <xsl:copy>). But so that the process doesn’t stop here, we need to add line 6.
- Line 6: Tells the XSLT processor to keep going, applying all the template rules (we only have one) to any nodes or attributes it finds as it moves down the XML tree.
Adding More Specific Rules
The XSLT with one template rule will give us as output the same XML we feed in as input. This will serve as the basis for our task at hand; namely, to change an element name and then to convert an attribute to an element.
Changing an Element Name
To change the element name from request to order, we need a special rule that matches for the element request when as we travel down the document tree. When we get a match, we simply insert a new element into the output, using <xsl:element name="order">, which will generate an order element. To keep the XSLT processor traveling down the tree, we need to insert <xsl:apply-templates/> as the value of xsl:element. Thus, our new rule becomes the following:
<xsl:template match="request"> <xsl:element name="order"> <xsl:apply-templates/> </xsl:element> </xsl:template>
Converting from Attribute to Element
To change an attribute to an element, we need a rule that matches the attribute of interest and creates an element of the same name. The following template rule will do this for us:
<xsl:template match="@isbn"> <xsl:element name="isbn"> <xsl:value-of select="."> </xsl:value-of></xsl:element> </xsl:template>
As the XSLT processor travels down the tree, it considers our match (match="@isbn") for every node in the tree. When our rule kicks in, an isbn element is generated with a value of ".", which, in the context of the tree, refers to the value of the isbn attribute. Thus, if the processor finds isbn="123456789", it will insert the following into the output document:
<isbn>123456789</isbn>
Putting it all together, we get the style sheet in Listing 4.
Listing 4 XSLT for transforming AsiaBooks XML into EuroBooks XML format.
<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/> <xsl:template match="node() | @*"> <xsl:copy> <xsl:apply-templates select="node() | @* "/> </xsl:copy> </xsl:template> <xsl:template match="request"> <xsl:element name="order"> <xsl:apply-templates/> </xsl:element> </xsl:template> <xsl:template match="@isbn"> <xsl:element name="isbn"> <xsl:value-of select="."> </xsl:value-of></xsl:element> </xsl:template> </xsl:stylesheet>
The XSLT in Listing 4 contains three rules packaged together, which provides an opportunity to explain the rule-matching that occurs in multi-template XSLT. As the XSLT processor moves from node to node down the XML document tree, it checks at each "node stop" to see whether any of the rules in its template set match. If a template rule matches, content of that template is output. But if several rules apply, the more specific rule is applied. In our example, two rules apply as we travel the tree and come to the request element node. These are the two matching template rules:
match="node() | @*" match="request"
Since request is a specific node name, whereas node() refers to any node in the entire tree, the rule for template overrides the rule for node(); therefore, instead of copying the request element, a new element, order, is created. Similarly, for the attribute isbn, the rule that uses match="@isbn" specifically names the attribute it seeks, while match="@*" is more general. Thus, instead of copying the attribute, a new element isbn is created and output.