What Is XSLT?

XSLT is a language designed to transform one XML document into another, changing both its schema and content in the process. At its most primitive, XSLT is a text-processing system that enables the programmer to transform XML documents, or, if required, generate other standard markup languages such as HTML (or any text, for that matter).

In previous chapters, we have discussed the need for transformation as information moves between applications, so we will not devote our attention to it here. However, it is important to remember that XML documents are like messages. And because each application has its own unique set of application semantics, documents moving from application to application need to be transformed (see Figure 11.6). Both data structure and content must be semantically correct in order to load into the target application. If the data is not in the proper format, the update operation is likely to fail.

Figure 11.6. You must transform XML as it moves from application to application.

graphics/11fig06.gif

In addition to transforming the schema and content of XML documents, XSLT can perform other types of text-processing and transformation operations, which include creating text-based standard data formats such as comma-delimited files, PDFs, or other industry-standard formats that use text (see Figure 11.7).

Figure 11.7. XSLT can also create other text-based formats, such as comma-delimited files and PDFs.

graphics/11fig07.gif

Leveraging XSLT Inside Middleware: The Tradeoff

Although XSLT has tremendous promise, a huge disconnect remains between what XSLT provides and what middleware needs to offer in terms of transformation. Still, it is finding its way into more than a few middleware products, including B2B integration servers such as BizTalk Server.

The state of the technology of most integration servers supporting complex but valuable information transport is a better fit for binary messaging, which is more efficient than text-based messaging and is easier to manage and process. However, binary messaging does require that specialized systems (such as message-oriented middleware) manage it, and it is not as easily managed by external systems as text-based messaging (e.g., XML).

Because that is the case, to process messages using XSLT, the messages must first be transformed into XML text (or any text) for XSLT transformation and then be transformed back into a binary message. Efficient? Clearly not. Even as a few integration servers look at XSLT as their standard mechanism for transformation, it is apparent that building text processing into existing binary messaging systems will be difficult.

B2B servers, such as BizTalk Server, do not support such sophisticated message-processing operations. As a result, they are able to maintain their messages as XML or EDI text. Therefore, they have a better opportunity to leverage XSLT as their standard transformation mechanism, which they do.

XSLT will fit into some middleware products and not others. XSLT almost certainly will succeed as a standard transformation mechanism in products that already process information as raw text of XML. If XSLT continues to pick up speed, other middleware vendors will inevitably follow the crowd.

Before XSLT existed, most XML developers could only process incoming XML documents by creating custom applications that typically invoked one of two APIs: the Simple API for XML (SAX) and the Document Object Model (DOM).

The SAX API was an event-based interface that used a mechanism through which the parser notified the application of each piece of information in the document as it was read. In the DOM API, the parser interrogated the document and created an object tree structure that represented the structure of the XML document in memory. From that point, a traditional program (e.g., C++ or Java) transformed the tree.

XSLT and XPath

As the development of XSLT progressed, its creators discovered that there was an overlap between the expression syntax in XSLT for selecting parts of a document and the XPointer language that was being developed for linking one document to another. Taking advantage of this, the creators of XSLT and XPointer decided to combine both efforts, defining a single language known as XPath.

In the world of XSLT, XPath provides a sublanguage encapsulated within the XSLT stylesheet. Most programming operations, including simple calculations or even testing for conditions, can be done using an XPath expression.

The limitation of both approaches was the same each time you wanted to transform a new XML document, you had to write a new program.

XSLT provides several advantages over SAX and DOM. XSLT's design is based on the fact that most transformation programs use the same design patterns, and therefore can be automated using a higher-level, declarative language. (Stating that the XSLT language is declarative means that it describes the transformation behavior rather than a sequence of instructions necessary to perform the transformation. In other words, XSLT describes the transformation, then leverages the XSL processors to carry out the deed.) Moreover, when XSLT is used, the requirements of transformation can be expressed as a grouping of rules that define what output should be created when a particular pattern is encountered.



Next Generation Application Integration(c) From Simple Information to Web Services
Next Generation Application Integration: From Simple Information to Web Services
ISBN: 0201844567
EAN: 2147483647
Year: 2005
Pages: 220

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net