If you are a backend systems developer or a systems architect, you should be seeing the value ofXML by now. A language that represents data in a vendor-neutral way, that is easy to parse, that isportable, and that you can use from Java? Could this be the data format that solves so many of your interoperability issues? It just might be. However, if you are a content developer, an application assembler, or are involved with application presentation, you may be a little confused. Certainly you have heard a lot about the promise of XML for generating content for various types of clients, and how it provides a separation of presentation and data.. You might be wondering if this technology is really right for you. In either case, read on, because XML's capabilities are just beginning to be showcased.

In this article, we begin the process of tackling XML transformations. This is a rather lengthy topic, and we begin in this article by discussing why XML transformations are important, the components involved, and the syntax used to accomplish transformations., from the same initial XML data, and how the Document Object Model (DOM) is used in this process. Throughout, we will continue to focus on the value of XML transformations to you, the application developer. Because XML transformations are such a large subject, we will not touch on every syntactical construct or possible use. For a short reference on transformations, you should pick up the XML Pocket.

Before we dive into the components of XML transformations and the syntax involved, it is important to understand the purpose of XML transformations. Just as we spent time discussing the significance of constraining XML data and its effect on application interoperability, an understanding of the value of transforming XML data is critical to using these transformations appropriately. They are not the final solution in data presentation and should not be used in every situation; by the same token, there are times when transforming XML can save tens and even hundreds of hours of time that would be spent on discovering a comparable solution for a given problem.

We have spent a lot of time emphasizing the importance of XML as a pure data layer. In fact, there has been much more discussion of XML as pure data than as a new way of generating application content. This is in contrast to the hype that XML seems to be receiving as a content-driven language. In the next two articles, we shift our focus to looking at how XML data can be presented to various clients. However, this does not necessarily mean that the focus is displaying a presentation layer to an end user. In fact, we will spend almost no time discussing the user point of view. If this confuses you a bit, that's okay. Let's reiterate what we mean by client.

The most common definition for a client or application client is an end user. The idea that some human using a web browser or a GUI interface is the client of an application is somewhat limiting, though. We've already discussed the variety of clients that might interact with your application; let's extend this definition even more. Consider a database engine; because the data within that database is rarely directly displayed to the end user without another program formatting that data, can we say that the database has no clients? In an application that parses the weather from another HTML page and displays it in a new format to a user, can we say that the weather data has two clients? How about the X Windows system, where the display is generated on the server, and the remote application is the client? Clearly, the commonly accepted definition of a client needs to be redefined.

For the duration of the this article, we consider a client to be anything that uses data from an application, program, or engine. That would make the program using our database engine above a client, as well as the end user who views the formatted data. The program that formats the weather data is a client, as are the users who view that formatted data; and the program that reformats that data is a client, as well as its users. As you can see, the line between an end user and a program begins to get blurred. In a multi-tiered system where a database, Enterprise JavaBeans container, servlet engine, and publishing framework may all exist, there are four, five, or more clients! The point of this discussion is to make you understand that with XML, we do not distinguish between a human and a program using the data; they are both clients. This allows us to think about data transformations in a much more useful way; if application A needs data (in format A) from application B (which stores the data in format B), we will need to transform the data. The formats are simply details of the transformation, but do not affect the concepts involved. With our new definition of what a client is, we can also separate the details of the type of application needing the data. When application C then uses the formatted data in application B in format C, another transformation occurs. Whether these formats are HTML, SQL, XML conforming to different DTDs, or something entirely different, is not important. Whether the client is another program, an end user, or a legacy system, the details are still unimportant. The process is still simply a transformation from one format to another. Understanding this important point will help you see why we need to be able to transform XML data.

As you may already be thinking, certainly the most common purpose for transforming XML is to put it into a format readable by a given client. Sometimes mutating an XML document that conforms to one DTD or schema into an XML document that conforms to another DTD or schema can do this. Other times, radically different documents may need to result from the same underlying XML data. In either case, our previous discussions about the importance of constraining and validating XML should be coming back to you. Even if an application knows the format it must read data in, it cannot correctly interpret another format with that information alone. It must use a DTD, schema, or another set of constraints for the originating document to understand what types of conversions can be accomplished and what data structures are present in the source data. The problems arise when the permutations of application interoperability increase; in other words, the more application components, the more possibilities for data transformations. This can become unmanageable for the components, as each has to keep track of all other components' constraints and formats to allow them to exchange data. For this reason, a set of specifications and standards has been developed for XML transformations. These provide an intermediary layer that can act independently of application components to convert data from one format or style to another, leaving application components to perform business logic. We refer to this middle layer as a processor . It is the processor's task to take one or more documents, determine their formats and constraints, and apply a transformation, which results in data in another format, which might even result in multiple output files. This resulting document can then be used by the next component. Of course, this application may in turn hand its data to another processor, which hands off yet another transformed document to a third component, and so on down the line. In this way, applications that do not speak the same "language" can converse without having to implement complex rules for understanding each other's different data types.

As useful as these XML transformations can be, they are not very simple to implement. In fact, rather than trying to specify the transformation of XML in the original XML 1.0 specification, three separate recommendations have come out to define how transformations should occur. Although one of these (XPath) is also used in the XPointer specification, by far the most common use of the components we outline here is to transform XML from one format into another. Because these three specifications are tied together tightly, and are almost always used in concert, there is rarely a clear distinction between them. This can often make for a discussion that is easy to understand, but not necessarily technically correct. In other words, the term XSLT, which refers specifically to extensible stylesheet transformations, is often applied to both extensible stylesheets (XSL) and XPath. In the same fashion, XSL is often used as a grouping term for all three technologies. In this article, we will distinguish among the three recommendations, and remain true to the letter of the specifications outlining these technologies.. Although this may not follow the letter of these specifications, it certainly follows their spirit, as well as helping to avoid unnecessary confusion.

XSL is the extensible stylesheet language. It is defined as a language for expressing stylesheets. This broad definition is broken down into two parts:

• XSL is a language for transforming XML documents.

• XSL is an XML vocabulary for specifying the formatting of XML documents.

These definitions are similar, but one deals with moving from one XML document form to another, while the other is more focused on the actual presentation of content within each document. Perhaps a clearer definition would be to say that XSL handles the specification of how to transform a document from format A to format B.

The most important concept to begin to understand in XSL is that all data within XSL processing stages is in tree structures (see Figure (a)). In fact, the rules you define using XSL are themselves held in a tree structure. This allows simple processing of the hierarchical structure of XML documents. Templates are used to match the root element of the XML document being processed. Then "leaf" rules are applied to "leaf" elements, filtering down to the most nested elements. At any point in this progression, elements can be processed, styled, ignored, copied, or have a variety of other things done to them.

Figure (a)

A nice advantage of this tree structure is that it allows the grouping of XML documents to be maintained. If element A contains elements B and C, and element A is moved or copied, the elements contained within it receive the same treatment. This makes the handling of large data sections that need to receive the same treatment fast and easy to notate, as well as concise, in the XSL stylesheet. We will look more at how this tree is actually

constructed when we talk specifically about XSLT in the next article.