One of the single most useful aspects of XML is the capacity to transform it from one form to another based on the tags present in the document.
Transformations of XML (typically done using what are known as XSL Transformations or XSLTs) may be from:
¨ XML to XML
¨ XML to non-XML
In this tutorial, we will focus only on XML to XML transformations. But before we even get there, let us go through an overview of where transformations are used and the architectures that support it.
The most common application of XML transformations fall into two broad categories:
¨ Data Storage to Data Storage Transformations
¨ Data Storage to Device Transformations
Often, organizations have repositories of backend data that are stored in proprietary structures and native forms. All goes well until this information has to be exchanged with other organizations that have similar data but unfortunately in their own proprietary structures and native forms.
Now we have two related issues here:
¨ The political issue: Who’s information structures are better, more complete or more relevant? And quite frankly there is no answer to this – company loyalties simply prevail. Essentially this means that there is no common understanding on the definitions of even similar information.
This issue has been a long standing problem for many an industry vertical. And while XML can afford the technical solution by standardizing the basic syntax, it can do little to solve political issues. These need perseverance and community agreements to determine common structures for information. Often, to agree and draft a XML DTD or Schema for exchanging domain information can take months or sometimes years!
¨
The technical issue:
Then there is the technical background. Let us consider two scenarios of a typical architecture to demonstrate these:
The key issues are how do we:
o
get XML information out of the
data producer and into the data consumer native storage, and
o
convert the information from one
form to another
In Scenario 1, the data is pulled out of a native data repository (such as an RDBMS, an LDAP or an ERP Package) using a native API and then converted to XML using an XML Convertor. Similarly at the consumer end, the data is converted from XML into native data storage format and then written into the repository using native API.
In Scenario 2, the data storage is itself XML Enabled, which implies that either:
¨ the data is stored in native format but can be converted into XML by the data repository itself, or
¨
the data is stored and accessed
natively in XML (as in native XML databases such as Tamino)
In this scenario, the data need not be externally converted to XML. It can be accessed directly as XML. For instance, the Oracle XML Database (XDB) allows users to return queried data in XML.
Commonly, in both the scenarios the XML data maybe translated using eXtensible Stylesheet Language Transformations (XSLT) – which we will study more in detail in the next chapter.
In the days of proliferation of devices and channels, multichannel applications are becoming increasingly popular. The central paradigm of such applications is- Single information source Multiple presentation formats.
A simplified architecture of such applications is shown below.
These applications work on the following flow:
a. Sense the origin device of the request for information. For instance a multichannel application will be able to determine if the device making a request is a mobile phone (including the model of the phone if possible), a PC, a kiosk etc.
b. Determine the characteristics of the device from its internal repository of device characteristics
c. Repurpose the content (the content is irrespective of the device) retrieved from the repository according to the device characteristics. For instance make the content small for handphones, slightly bigger and with more graphics for PDAs and most graphical for say PCs.
d. Set the appropriate content type on the response and deliver the content over the appropriate channel back to the requesting device.
Of the above flow, we are primarily interested in the third component – repurposing of the content which is typically done using XSL Transformations. We will study this in detail in the next chapter.
Just as with the case of data storage-to-data storage, the transformation can take place at either the producer or the consumer end, in the case of the data source-to-device also the transformation may either take place at the server end or at the client end.
¨ Server: This implies that the server transforms the data to the form that the client browser understands and then sends it across.
¨ Client: This implies that the client is able to transform the generic XML data sent to it along with the XSLT and render it according to its needs. For instance the Internet Explorer browser is capable of rendering XML documents to HTML using a supplied XSLT.
In this part of the tutorial, we have seen broad classes of XML Transformations and how typical XML transformation architectures are structured and work. Computationally, at the core of these architectures lie what are known as XSLTs. These are ways of identifying what part of the XML document to transform and how to do it.
In the next chapter, we will study these XSLTs in more detail. We will look at the basic rules of XML matching and repurposing and this will set the stage for two interesting examples of transformation in a subsequent chapter.