Content area
XSLT isn't a declarative language in the truest sense. An XSL style sheet is an XML document that conforms to a schema, and is therefore a well-defined markup language. The markup is used to describe programming constructs foi loops, if/then tests, and so on. Because XSLT is XML, you can treat it just like any XML document using programming techniques.
Full text
Who should you put in charge of your style sheets-designers or developers?
new element type or altering an existing element, you may have to modify many style sheets. In the Web example, even a minor modification to just one document type means we'd have to update nearly 50 style sheets.
There are two ways to solve this problem. The first is through the use of project-oriented tools or XML development environments. The second is to create your own style sheet management tool using a scripting and an XML API like the DOM.
Tools Should Support XSLT
Despite all of the new XML tools hitting the market, there's a distinct lack of support for XSLT. I have found some support in several tools, but not the level of support for which I'm looking. Specifically, I'd like to see a tool that lets me browse document, schema, and (most importantly) XSLT collections. I'd also like the tool to assist me in creating XSLT documents.
Among the tools that you might expect to support XSLT are the XML editing and authoring tools. Tools like XMetaL (from SoftQuad) and XML Spy (from Altova) support the creation of style sheets, but are geared toward authoring single documents and validating them against a schema. Support for creating style sheets is particularly good in XML Spy. For example, it recognizes style sheets in the environment and employs syntax-directed highlighting, which color highlights various element types and attributes, making the document easier to read. The editor also pops up a list of XSLT element types, letting you create your style sheets quicker.
XMetaL 2.0's support for XSLT is much less advanced. The editing environment views an XSL document as any other XML document, but doesn't support XSLT directly. In fact, to incorporate style sheets, you must create XMetaL macros, which are scripting extensions built into the product. XMetaL 2.1 is due by the time this column reaches print, so XMetaL may have improved support for XSLT. However, neither XMetaL nor XML Spy let you maintain large style sheet collections.
One tool, thinkXML, which I covered a couple of months back (see "XML@)Large," May 2001), does seem to recognize and partially address the problem. thinkXML is a solid product. It includes a management console that lets you create XML applications using a forms-based approach. Once a form has been created, you can link each form schema to a theme. The form schema is bound as an XML data island to a table cell within an HTML document and is then transformed by XSLT. In this type of product, the transformations are handled for you-all of the transformations are created and managed under the hood. Unfortunately, while this works fine in the thinkXML environment, it's a general-purpose solution to the maintenance of large numbers of style sheets.
I'm sure there's a tool out there that lets you create style sheets, maintain them in a project-friendly manner, and seamlessly integrate them within your XML applications. However, I've yet to find one that completely meets those requirements. If you know of such a product, I'd love to hear from you.
Wrapping Up
There are other ways you can deal with style sheets, but they all involve some programming. For example, you could store style sheets in a database and fetch them as necessary. This doesn't do away with the propagation problem, but it does let you manage it.
Another method takes advantage of the fact that a style sheet is a well-formed (and in fact, valid) document. That is, you can load the style sheet into the DOM, create new elements, and modify attributes-just as you can with any other XML document. You can use this feature to load a basic style sheet into a DOM object, then use DOM methods to begin building a style sheet instance in memory at run time. Once you have the style sheet built, you can apply it to an XML document and continue processing as normal. Because you can reconstruct the style sheet at will, you can clear out the inmemory instance, or cache it for later use once the application has completed its task.
The devil is, of course, in the details. Those will be the subject of another article. Until then, remember: It's all about the data. ).
Have you had the argument yet? You know: It's the discussion in which the entire development team sits around the conference table and argues, heatedly at times, over who should develop the XSL transformations. The programmers don't want anything to do with them and neither do the Web designers. Managers are caught in the middle, and sometimes don't understand the intricate technical issues associated with XSLT. At the heart of the issue are major misconceptions held by all parties about the role XSLT plays, how you can use it, and even the meth. ods for creating XSLT documents.
This month I'll describe some of the myths surrounding XSLT, its role in XML applications, the problems that style sheets introduce, and approaches you can use to solve a thorny problem I call the propagation of style sheets.
Debunking the Myths
Myth One: Style sheets are for presentation. A typical misconception held by management is that XSLT is used to render XML documents, add styles to characters, and create views to data. Thus, the team leader or project manager leans toward handing it off to the Web designer or HTML author. However, although the application of your transformations may be intricately woven around the data presentation and HTML, they could equally involve mapping database fields from one format to another.
Myth Two: The Web designer/author can't do it. Did I mention that most Web designers have no intention of learning something as verbose as the XSL transformation language? Like most generalizations, this one may be a bit unfair, because I'm lumping designers and HTML coders into one group. Either way, the general feeling is that XSLT is too much like a programming language. Yes, XSLT is verbose, but I believe you can use to percent of XSLT's features to do go percent of your work.
More importantly, many transformations involve converting XML into HTML so it can be presented in a browser. The HTML you want to generate goes right in to the style sheet. With a little instruction on tree walking and a quick run-through on match patterns, any HTML author worth his or her salt should have little difficulty writing basic transformations.
Myth Three: XSU isn't a programming activity. Some programmers argue that they're hip deep in the Document object Model (DOM) or Simple API for XML (SAX) and want nothing to do with writing transformations-in part because "XSLT isn't a programming language! However, the argument that XSLT is a declarative language rather than a programming language isn't exactly true. To oversimplify a bit, declarative languages let you describe something using a set of rules. The rules can often be placed anywhere, but they usually say little about how actions should be executed, or in what order. Cascading Style Sheets (CSS) is one example of a declarative language.
XSLT isn't a declarative language in the truest sense. An XSL style sheet is an XML document that conforms to a schema, and is therefore a well-defined markup language. The markup is used to describe programming constructs foi loops, if/then tests, and so on. Because XSLT is XML, you can treat it just like any XML document using programming techniques. That is, you can load an XSLT document into the DOM (or any other XML API), walk its tree structure, change element and attribute values, and save the results on a disk. This implies that programmers can generate XSLT style sheets directly from an application, or even create an authoring tool that lets the Web-design guys develop XSLT documents more easily.
The Role Transformations Play
We've heard the promise that XSLT can be used to convert from anything to anything else. In a nutshell, style sheet transformations are useful anytime you want to convert something from one "thing" to another. In fact, I tell my students that they can benefit from XSLT anytime they convert a single format to a multitude of transformations; whether it be mapping relational data from an Oracle database to other proprietary formats, or converting XML into HTML for presentation over the Web. In addition, you can use XSLT to map a common data set to a different rendition of the same format, for instance, allowing you to present different views of the same data.
Figure1depicts a Web server that serves XML documents to various browser types. On the right side of the figure are several different browsers including Internet Explorer 5, Netscape Navigator 4, Lynx, and brand X. Every browser has different capabilities; indeed, the capabilities of Internet Explorer differ dramatically between versions 4 and 5. The problem being that some of the browsers understand XML quite well, some have a partial understanding, and most don't recognize XML at all.
As you know, one feature of XSLT lets you create style sheets that convert XML into HTML. It's simple (at least conceptually) to create a separate style sheet for each browser type. That is, one style sheet that transforms your XML document into HTML specific to Navigator 4, another that generates a minimal set of HTML for viewing in Lynx, and so on. When the browser requests the document, you can perform a little browser detection and attach the style sheet best suited for that browser type. XSLT is an elegant solution to the age-old problem of servicing different types (and versions) of browsers.
However, this is just one example. XSLT is useful anytime you need to convert a common data set to multiple formats. Figure 2, for example, is actually Figure 1 with different labels. This time, the figure depicts a B2B relationship. Acme Trucking contracts out trucking services to hundreds of business partners, and maintains a database that tracks trucking schedules. Internally, the company must update the database to reflect whether individual trucks are en route, have completed their routes, or are in some other stage of transit. The company makes this information accessible externally so that clients can check available routes and schedule deliveries. In addition, Acme wants to let these clients conduct transactions that issue purchase orders and schedule new deliveries.
The problem is that Acme wants to distribute routing information, but the internal systems of the various clients require that it export this Information in any one of 4o different formats. Acme could write custom translations for each client, but adding a new client or changing the application itself could result in major rewrites. XSLT, on the other hand, offers the unique benefit that you can write each style sheet just once, then use DOM scripts to select and attach the appropriate style sheet, just as in the Web example. Writing the style sheet is easier than coding a conversion, and maintenance is somewhat simplified.
But how does the transformation from raw data to a proprietary format actually work? While early efforts may have been more ambitious, the W3C has made it clear that XSLT isn't a general-purpose transformation language, nor will that be a goal for future revisions. Specifically, XSLT is designed to convert an XML document using one vocabulary to a document conforming to another XML vocabulary, or to HTML. That sounds limiting, but XML is the format du jour because you can define your format in terms of an XML vocabulary. Once you've done this, an XSLT processor can take an appropriate style sheet and convert your vocabulary into any format that has likewise been defined by its own vocabulary. You can do this using an API like the DOM. But, when you're translating to a large number of formats, the process of creating XSLT style sheets can be far easier than coding the transformations by hand. This, of course, leads to another problem.
Propagation of Style Sheets
With style sheets, when you have several variables, you can wind up with literally hundreds of style sheets. For example, Figure 1 requires that style sheets be written for IE versions 1 through 5.5, and Navigator 1 through 4.5. Solely to support these browsers I'll need to create roughly a dozen style sheets. However, this is only for one type of XML document with a specific structure. On my Web site, I have DTDs that describe document structures for a half dozen document types. In addition, I also let users change the site's appearance using one of four themes. Thus, each document type must be supported by 48 (12x4) separate style sheets. With just six document types, that adds up to some 288 transformations. As you can see from this example, style sheets proliferate in a hurry.
The propagation of style sheets leads to all kinds of problems. If you change the structure of a given document type by, for example, adding a
Michael is the author of Building Web Sites with XML from Prentice Hall, and architect of the Rocket XML framework. He is also the publisher of BeyondHTML.com and carries the honorary title of Editor At Large at Web Techniques. He can be reached at [email protected].
Copyright Miller Freeman Inc. Jul 2001