XSLT as a compiler

XSLT allows you to transform XML data into any other data format. Usually XSLT is thought of as an XML-to-XML transformation language, taking an XML document as input and transforming it into another XML structure (including XHTML), but it can actually be used to produce any output, not just XML. When thought of this way, an XSLT stylesheet is actually a tool for defining new languages, and can be thought of as a language compiler. This use of the word compiler might seem odd. Usually, you think of a compiler as a program that translates human-readable code into either machine language or virtual machine bytecode, but a compiler in the general sense is just a translator: it compiles one language into another. Often the target language is a binary format like machine code, but not always. In this sense, XSLT is a compiler technology. An XSLT stylesheet implicitly defines a new language, an XML dialect, that it compiles into some other form, which can be another XML dialect or some other language.

As an example of this concept of XSLT as a compiler, if you wanted to generate Java™ code from XML, say to generate Java beans as part of an object-relational mapping system, you could do so using XSLT. A Java bean is a Java class with a default constructor (one taking no arguments), that exposes getter and setter methods that let the caller read and set properties on the object. Listing 1 shows an example of an XML document defining a Java bean class in an XML-based language.

<java>
  <bean-class name="Employee">
    <property name="id" type="int"/>
    <property name="name" type="String"/>
    <property name="title" type="String"/>
  </bean-class>
</java>

This XML document creates one <bean-class> element specifying a number of properties, each with a name and Java type. This is a fairly concise (as XML goes) language to specify a Java bean class in terms of its properties. Listing 2 shows the XSLT that produces Java code from this XML.

<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

  <xsl:template match="bean-class">
    public class <xsl:value-of select="@name"/> {
      
      <xsl:apply-templates select="property" mode="instance-variable"/>
      
      public <xsl:value-of select="name"/> () { }

      <xsl:apply-templates select="property" mode="getter-and-setter"/>
    }
  </xsl:template>

  <xsl:template match="property" mode="instance-variable">
    private <xsl:value-of select="@type"/> <xsl:text> </xsl:text> 
<xsl:value-of select="@name"/>;
  </xsl:template>

  <xsl:template match="property" mode="getter-and-setter">
    <xsl:apply-templates select="." mode="getter"/>
    <xsl:apply-templates select="." mode="setter"/>
  </xsl:template>

  <xsl:template match="property" mode="getter">
    public <xsl:value-of select="@type"/> 
get_<xsl:value-of select="@name"/>() {
      return this.<xsl:value-of select="@name"/>;
    }
  </xsl:template>

  <xsl:template match="property" mode="setter">
    public void set_<xsl:value-of select="@name"/>(<xsl:value-of 
select="@type"/> value) {
      this.<xsl:value-of select="@name"/> = value;
    }
  </xsl:template>

</xsl:stylesheet>

The first template matches on <bean-class> elements, outputting the Java code for the bean class as literal text, as opposed to outputting XML elements as XSLT documents usually do. First, to generate the private instance variables of the class, the template passes the <property> sub-elements into the instance-variable template (the template matching on "property" elements in instance-variable mode). Then it generates a default constructor, and passes the <property> elements into the getter-and-setter template to generate the getter and setter methods of the property. Listing 3 shows the result of passing the sample XML through this stylesheet.

public class Employee {

  private int id;
  private String name;
  private String title;

  public Employee() { }

  public int get_id() {
    return this.id;
  }

  public void set_id (int value) {
    this.id = value;
  }

  public String get_name() {
    return this.name;
  }

  public void set_name (String value) {
    this.name = value;
  }

  public String get_title() {
    return this.title;
  }

  public void set_title (String value) {
    this.value = value;
  } 
}

This demonstrates the use of XSLT to define a new language. Here the XSLT stylesheet implicitly defines a new language for specifying Java class definitions. You can use such a stylesheet, as an example, in an object-relational mapping system that generates Java objects corresponding to database tables, where the XML is generated from the database table columns, or corresponding to user-supplied XML configurations where the XML is supplied directly by the developer. If you flesh out the XML dialect and corresponding XSLT stylesheet, you can then add support to concisely define class relationships such as one-to-one, one-to-many and many-to-many cardinality, in which case the stylesheet generates fairly elaborate code to maintain lists of child objects, and code for reading and storing object trees from and to a SQL database. Once you define the source language (the XML dialect used to specify the Java objects), you can translate that XML into code as complex as you need it to be, while keeping all of that implementation logic hidden from the end developer, who only has to define the object system in terms of the high-level XML language.

Back to top

XSLT defines new languages

When viewed in this context, any XSLT stylesheet implicitly defines such a language, because a stylesheet takes XML and translates it into another form, the same way a Java compiler takes Java source code and translates it into a series of virtual machine instructions. The only restriction is that XSLT is designed to process XML input, so the source language must be defined as an XML dialect.

Seen another way, XSLT can be used to define XML wrappers around other languages and output formats, in the same way that the Java language can be seen as just a wrapper around the JVM's instruction set.

Since XML is so widespread and standard, and so much support exists for it, defining a language as an XML dialect means it will be readily understood and can be easily integrated into other systems (for example, systems already designed to produce XML output.) It also makes it possible to incorporate such a language into an XSLT pipeline, translating source XML data into the new language that wraps the desired output format. The ubiquity of XML makes it a prime candidate to wrap an output format such as PDF or PostScript, making it possible to programatically generate such documents without needing knowledge of the details of the PDF or PostScript language syntax.

Back to top

Producing Adobe PDF from XML

Adobe has already made this logical connection with the Adobe Mars project, in which Adobe has defined PDFXML, an XML dialect that can be used to create PDF documents (see Resources). The Mars project is still being developed, and support is minimal with respect to tools and tutorial documentation. Mars documents also require a special plugin for viewing, as opposed to being viewable in existing PDF viewers. This presents an entirely new platform for creating portable documents, and, as such, is incompatible with the existing world of PDF viewers.

A different approach to an XML-based document format is to define an XML dialect that can be translated into an existing format like PDF using an XSLT stylesheet or series of stylesheets to perform that translation.

One might define an XSLT stylesheet that translates XML structures directly into PDF code, perhaps using the code of the Java iText project as a guide for the stylesheet logic.

As a simpler example, an intermediate approach translates XML into PostScript, and then uses an open source PostScript-to-PDF conversion program to do the final step of compilation into PDF format (see Resources for links to a couple of open source PostScript-to-PDF tools). The ultimate result is that you can create PDF documents programmatically using XML.

Back to top

A simpler example: producing PostScript from XML

For this simpler example of producing PostScript, which you then can translate into PDF format using an open-source command-line tool, the first question is how much XSLT to use. PostScript is a programming language in which you push operands onto a stack, and then apply a function to them—a convention called postfix syntax, in which the function name is specified after the arguments. So the PostScript command for multiplying 3 and 7 is 3 7 mul. This means "push 3 onto the stack, then push 7 onto the stack, then call the mul function". The mul function, when called, pops the first two items off the stack and multiplies them, then puts the result on the stack. So the PostScript command 3 7 mul 2 add is equivalent to the arithmetic expression (3 * 7) + 2. The mul function multiples the 3 and 7, leaving 21 on the stack, then the literal 2 is pushed onto the stack, then the add function is called, which pops the first two items off the stack and adds them, leaving 23 on the stack.

PostScript produces rendered, printable pages of text and graphics. You place text and graphics objects on the page with the same postfix syntax as that of the multiplication and addition example above. PostScript's coordinate system puts the origin (0,0) at the lower left corner of the page, and contains 72 points per inch. So the coordinate (72, 72) represents the point one inch in from the left and bottom of the page. For example, Listing 4 shows the PostScript for rendering a circle.

150 150 10 0 360 arc

This draws a circular arc at (150, 150) on the page (relative to the bottom-left corner), of radius 10, from angle 0 to angle 360, or a full circle. Like the multiplication, the operands are pushed one by one onto the stack, then the arc function is called, which pops 5 items off the stack and uses them to render a circle.

With this one PostScript instruction, you can produce a page of data points in a scatter plot. Listing 5 shows an XSLT stylesheet template to do that.

<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

  <xsl:template match="/">
    <apply-templates select="//point"/>
    showpage
  </xsl:template>

  <xsl:template match="point">
    <xsl:value-of select="x"/> <xsl:text> </xsl:text> 
<xsl:value-of select="y"/> 5 0 360 arc
    fill
  </xsl:template>

</xsl:stylesheet>

This takes an XML document containing <point> elements of the form <point x="30" y="50"/> and produces a PostScript document plotting them as radius-5 dots on the page, turning a set of XML data points into a visual scatter plot. Note the call to showpage at the end of the top-level template. showpage renders as a printable page whatever has been drawn up till then.

Back to top

Adding rendering logic

The scatter plot demonstrates the simplest application of this concept—using XSLT to produce PostScript—because it takes XML elements and translates them each directly into a PostScript command. In this case, the XML element already contains its coordinate information. Things become more complex as that coordinate information disappears from the data (such as when the XML data has less relationship to the rendered PostScript.) For example, moving one step beyond the scatter plot, rendering a line graph from a set of XML data values representing the y-axis value requires that the XSLT calculate the x-axis value as in Listing 6.

<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:output method="xml" omit-xml-declaration="yes"/>

  <xsl:variable name="originY" select="100"/>
  <xsl:variable name="originX" select="100"/>
  <xsl:variable name="graphWidth" select="1000"/>
  <xsl:variable name="graphHeight" select="1000"/>

  <xsl:variable name="xDelta" select="$graphWidth / div count(//temperature)"/>
  <xsl:variable name="tempRange" select="200"/>

  <xsl:template match="/">
    <xsl:apply-templates select="//temperature"/>
    stroke
    showpage
  </xsl:template>

  <xsl:template match="temperature">
    <xsl:value-of select="ceiling($="$originX  + (position() * $xDelta)"/>
    <xsl:text> </xsl:text>
    <xsl:value-of select="ceiling($originY + (@temp div / $tempRange * 
$graphHeight))"/> 
    <xsl:if test="position() = 1">
      moveto
      <xsl:if>
      <xsl:if test="position() != 1">
        lineto
      </xsl:else> 
   </xsl:if>
  </xsl:template>

</xsl:stylesheet>

This stylesheet takes a document containing a number of <temperature> elements of the form <temperature temp="30"/>, and translates them into a PostScript stack rendering a line graph of those temperatures. The stylesheet uses the count() and position() XPath functions to calculate the x values of the points in the line graph. Since the points must be evenly distributed across the page, the stylesheet first calculates how far apart the points will be by dividing the pageWidth variable by the number of <temperature> elements in the document. The xDelta variable stores the result, which represents the number of pixels between each temperature point.

The root-level template works the same as that in the scatter plot example, rendering instructions for the <temperature> elements and then calling showpage to render the contents of the graphics buffer. The temperature template calculates the x-coordinate by multiplying the xDelta value by the value returned by the position() XPath function (which returns the current node's index in the set of selected nodes passed into the template.) It also adds the value of originX, which specifies the x-coordinate of the left-most point in the graph. It outputs this value (pushing it onto the PostScript stack in the output program), and then outputs the y value, which is the temperature proportional to the height of the graph, $originY + (@temp / $tempRange * $graphHeight). $originY makes sure the lowest point is no lower than the bottom of the graph, and @temp / $tempRange * $graphHeight finds the ratio of the temperature to the range of temperatures, and multiplies that by the height of the graph, producing a y value proportional to the temperature and contained within the height of the graph.

Back to top

Rendering a page of lines in PostScript using XSLT

The line graph introduced some rendering logic into the XSLT, because the source XML document didn't include all coordinate information for the rendered graphics; the stylesheet had to calculate the x and y values of each line in the graph from the supplied temperature values. A similar problem occurs when rendering a flowing page of text. For example, if you had an XML document of <line> elements of the form <line height="15">hello there</line>, you could render them down the page with the stylesheet in Listing 7.

<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

 <xsl:output method="xml" omit-xml-declaration="yes"/>

  <xsl:variable name="pageHeight" select="720"/>

  <xsl:template match="/">
    <xsl:apply-templates select="//line[1]">
      <xsl:with-param name="y" select="0"/>
    </xsl:apply-templates>
    showpage
  </xsl:template>

  <xsl:template match="line">
    <xsl:param name="y"/>

    /Helvetica findfont <xsl:value-of select="@height"/> scalefont setfont

    0 <xsl:value-of select="$pageHeight - $y"/> moveto

    (<xsl:value-of select="text()") show

    <xsl:apply-templates select="following-sibling::line[1]">
      <xsl:with-param name="y" select="$y + @height"/>
   </xsl:apply-templates>

  </xsl:template>

</xsl:stylesheet>

This stylesheet demonstrates a number of things. The net result is that of taking a set of <line> elements, of the form <line height="20">some text</line>, and generating PostScript commands that render the lines one after the other down the page, allowing the lines to vary in font size with their height variable, specifying the height of the text.

This stylesheet solves the biggest problem of how to maintain the y coordinate value for the next line of text, a value that increases by a potentially different amount for each line added to the page. This is a different problem to solve than that of the line graph, where all the data points are an equal distance apart and therefore can be easily positioned using a declarative formula. In this case, the distance between adjacent elements can differ depending on data in each element, and a cumulative y value must be maintained as the stylesheet moves through the lines of data in the source document. A recursive template taking a parameter solves this problem. An <xsl:param> element specifies an argument you can pass into a template when you call it, adding a lot of power to XSLT. In this case, it lets you maintain the y coordinate value, passing an updated y value to the next recursive call of the line template.

The line template accepts a y parameter, meaning that when you call the line template you pass a value for this parameter to it, analogous to passing an argument to a function call. The template sets the font for the line of text (and, therefore, the height of the line) using the <line> element's height attribute. The next line of the template moves the PostScript graphics cursor to an x of 0 (the left edge of the page), and a y value of $pageHeight - $y, because a PostScript y value is relative to an origin at the lower left corner of the page, while the <line> elements in the data are ordered top-to-bottom. The $y value here is that of the y parameter of the template. Then the template displays the text of the <line> element using the PostScript show command; a string of PostScript text is contained in parentheses.

The last clause of the template handles the recursion, calling this same template with the current <line> element's next sibling in the data, passing in a y value updated with this line's height, to position the next line of text directly under this one. Note that the root-level template also calls this template with a y parameter value of 0 to start the recursive flow down the page.

Back to top

Moving the rendering logic from the XSLT into the PostScript

The line graph stylesheet included a fair amount of calculation, and the stylesheet rendering lines of text also included a fair amount of logic to calculate the y coordinate. Since these stylesheets are really compilers, translating XML data into a procedural programming language (that is, PostScript), an alternative to putting all that rendering logic in the XSLT is to put the rendering logic in the generated PostScript, and let PostScript perform the rendering calculations at runtime rather than doing it all at compile time. This is a choice that is always present when you compile from one programming language into another: how much work to do in the compiler, and how much to leave for the generated language at runtime. Usually you want to do as much work as possible at compile time for performance. Since PostScript was designed to make it easy to render pages of graphics and text, and XSLT was designed to perform translations of XML data into other formats, it simplifies everything to let each language do what it does best, and move the rendering logic out of the XSLT and into the generated PostScript.

For example, an alternative to the text-rendering stylesheet of Listing 7, which maintains the y coordinate value in the XSLT, is that of Listing 8, which does so in the generated PostScript.

<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

  <xsl:output method="xml" omit-xml-declaration="yes"/>

  <xsl:template match="/">

    /y 72 11 mul def

    /text_line 
    { 
      /height exch def
      /text exch def 
      /y pop def
      /Helvetica findfont height scalefont setfont
      /y y height sub def        
      0 y moveto
      text show
     }
    bind def

   <xsl:apply-templates select="//line"/>
    showpage

  </xsl:template>

  <xsl:template match="line">
   (<xsl:value-of select="text()"/>) <xsl:value-of 
select="@height"/> text_line
</xsl:template> 

</xsl:stylesheet>

The root-level template defines a PostScript variable called /y, set to the height of the page in points (72 per inch), and defines a function called text_line. /text_line refers to an entry in the PostScript lookup dictionary, the contents in curly braces ({}) contain the function definition to bind to that entry, and the bind def at the end binds the entry name text_line to that function definition.

text-line sets local variables to values on the stack—the text value and the height—meaning you call text_line in the format text height text_line (for example, (hello there) 20 text_line to position the text "hello there" with height 20 at the current value of y). text_line sets the font, using the supplied height value as the scale value for the font. Then it moves the graphics cursor to an x-coordinate of 0 (the left edge) and the supplied y coordinate, and shows the given text string. It then adds the given height to the given y value and sets the global /y variable to the sum, keeping a running y counter down the page as text_line is called.

To finish, the root-level template pushes a 0 onto the stack as the starting y value, calling the line template with all the <line> elements in the source document. Since all the logic is now in the text_line PostScript function, the line template itself is trivial—each <line> element translates directly into a call to the text_line PostScript function.

With the PostScript handling all the rendering logic, the stylesheet is free to easily define a much richer language, for example the entirety of XHTML, letting you specify documents as XHTML and compile them into PostScript documents (which can be readily converted into PDF).

Back to top

Layers of abstraction

In developing a stylesheet for a language like XHTML, you again have a choice about how much each of your stylesheet templates knows about PostScript, meaning how much PostScript logic each template contains to render itself. One solution is to create templates for the various XHTML tags like <h1_>, <h2>, <h3> and <div>, each outputting PostScript commands, like calls to text_line, to render itself. This solution tightly couples the language defined in the stylesheet (XHTML) with that of PostScript. As an alternative, you could define functions like /h1, /h2/, /h3 and /div in the rendered PostScript, translating each XHTML tag into a call to its respective function, the same way the code in Listing 8 translated <line> tags directly into calls to the text_line PostScript function. In this case, the XSLT stylesheet truly defines an XML wrapper language around the language you've defined in the PostScript in terms of available functions, and the PostScript generated is tightly coupled to the definition of XHTML. In both cases—putting lots of knowledge of PostScript in the XHTML tags, or lots of knowledge of XHTML in the PostScript functions (by creating a PostScript function for every XHTML tag)—the solution combines two concerns that should remain separate. One is the problem of rendering a page of flowing text, a problem better handled by the page-rendering language PostScript, and the other is the problem of defining the XHTML language, a problem better handled by XSLT, which defines XML dialects.

In short, you have room for another layer of abstraction here, implemented as two XSLT stylesheets to be applied in sequence. The first stylesheet defines templates for the XHTML language, but instead of translating them into PostScript commands or PostScript function calls, it translates them into an intermediate XML dialect defined by the second stylesheet. The second stylesheet defines an intermediate language between XHTML and PostScript, creating the tags necessary to define a page of flowing elements. The second stylesheet translates these tags into a core set of PostScript functions necessary to render a page of flowing text. The core set of functions include behavior like management of x and y cursor values, word wrap, pagination, and the rendering of text elements. Listing 8, which translates <line> elements into calls to the text_line PostScript function, is an example of that second intermediate stylesheet; it defines a wrapper element, <line>, around a PostScript function text_line. The first stylesheet defines templates for all the XHTML tags, each of which outputs tags defined in the second stylesheet, like <line>. For example, Listing 9 shows a subset of the XHTML stylesheet.

<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:output method="xml" omit-xml-declaration="yes"/>

  <xsl:param name="h1_height"/>
  <xsl:param name="h2_height"/>

  <xsl:template match="/">
    <lines>
      <xsl:apply-templates/>
    </lines>
  </xsl:template>


  <xsl:template match="//h1">
    <line height="$h1_height"><xsl:value-of select="text()"/></line>
  </xsl:template>

  <xsl:template match="//h2">
    <line height="$h2_height"><xsl:value-of select="text()"/></line>
  </xsl:template>

</xsl:stylesheet>

This stylesheet defines a small subset of XHTML, translating it into the intermediate page-rendering XML dialect of the second stylesheet, a "flowing text" language. The stylesheet in Listing 9 takes two parameters, h1_height and h2_height, letting the caller specify the font sizes of the <h1> and <h2> tags. For example, the caller might parse a CSS stylesheet and pass in values like h1_height and h2_height based on the defined CSS styles. The //h1 and //h2 templates translate the XHTML-specific <h1> and <h2> tags into the generic <line> tag, which just defines a line of text in the page with a specified height.

This decoupling principle, motivating the use of two stylesheets to begin with, allows for the reuse of either stylesheet, for example to translate XHTML into some other format like RTF, or to translate some other format like RTF into the intermediate "flowing page" dialect defined in the second stylesheet, perhaps in order to render RTF documents as PostScript. When you keep the rendering logic in the PostScript itself , the XSLT stylesheet can freely define the source XML dialect, and separate the roles of target functionality (the PostScript rendering logic), and language definition (the XSLT stylesheet).

Back to top

Summary

XSLT is not often seen as a language compiler, but in defining the translation of one data structure into another, that is exactly what it is. And as a compiler, an XSLT stylesheet implicitly defines the language of the source document. Therefore, you can use it to bridge languages like XHTML with unrelated languages like PostScript, or XML and Java, to render documents in other formats by stepwise translation into the target language.

Resources

Learn

• PostScript from Wikipedia: Get the history behind this description language often used in electronic and desktop publishing.
  
  
• Adobe PostScript 3: Visit the home page of this printing and imaging technology.
  
  
• PostScript Language Reference: Read about this interpretive programming language used to describe the appearance of text, graphical shapes, and sampled images on printed or displayed pages.
  
  
• Adobe Mars Project: Learn about the XML-friendly representation for PDF documents called PDFXML.
  
  
• XSLT 2.0 recommendation, maintained by the World Wide Web (W3C) Consortium: Read more about the syntax and semantics of XSLT 2.0, a language for transforming XML documents into other XML documents.
  
  
• What kind of language is XSLT? (Michael Kay, developerWorks, February 2001, updated April 2005): What kind of a language is XSLT, what is it for, and why was it designed the way it is? Find answers to those questions.
  
  
• An XSLT style sheet and an XML dictionary approach to internationalization (Laura Menke, developerWorks, April 2001): Get an example of how XSLT can be useful in real-world problems.
  
  
• How an XSLT processor works (Benoit Marchal, developerWorks, March 2004): Learn more of the theory behind XSLT and the recursive nature of its coding for faster programming in XSLT.
  
  
• Create multiple files in XSLT 2.0 (Jack Herrington, developerWorks, March 2005): Explore examples of xsl:result-document in action in this developerWorks tip.
  
  
• XSLT: Working with XML and HTML (Khun Yee Fung, Addison-Wesley, December 2000): Explore a comprehensive reference and tutorial to XSLT.
  
  
• XSLT Functions: Check out the extensive reference from the w3school.com.
  
  
• IBM XML certification: Find out how you can become an IBM-Certified Developer in XML and related technologies.
  
  
• XML technical library: See the developerWorks XML Zone for a wide range of technical articles and tips, tutorials, standards, and IBM Redbooks.
  
  
• developerWorks technical events and webcasts: Stay current with technology in these sessions.
  
  
• The technology bookstore: Browse for books on these and other technical topics.
  
  
• developerWorks podcasts: Listen to interesting interviews and discussions for software developers.
  
  

Get products and technologies

• ps2pdf: See how this PostScript-to-PDF converter works.
  
  
• Preview: Try this Mac OS X application for displaying images and Portable Document Format (PDF) documents.
  
  
• IBM trial software for product evaluation: Build your next project with trial software available for download directly from developerWorks, including application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  
  

Discuss

• Participate in the discussion forum.
  
  
• XML zone discussion forums: Participate in any of several XML-centered forums.
  
  
• XML zone discussion forums: Participate in any of several XML-related discussions.
  
  
• developerWorks blogs: Check out these blogs and get involved in the developerWorks community.
  
  

About the author

Jake Miles is Senior Technical Liaison at Twistage, Inc, a young company providing a full-stack video Web solution to businesses. He has experience with many languages and software technologies, has worked as a professional developer for 10 years, and has been an avid student and tinkerer since he was 10. He also teaches on a volunteer basis, and believes that anyone can learn anything if taught clearly enough.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• XSLT as a compiler
• XSLT defines new languages
• Producing Adobe PDF from XML
• A simpler example: producing PostScript from XML
• Adding rendering logic
• Rendering a page of lines in PostScript using XSLT
• Moving the rendering logic from the XSLT into the PostScript
• Layers of abstraction
• Summary
• Resources
• About the author
• Comments

Next steps from IBM

With the no-charge DB2 Express-C, pureXML, Zend Core PHP, and Java you can develope advanced Web 2.0 applications quickly that matter.

---

• Try: Download a free trial version of DB2 Express-C, which includes Zend Core PHP and pureXML technology that is ideally suited for managing both XML and relational data.
• Article: See how DB2 pureXML schema capabilities can evolve schemas without making any changes to your applications.
• Tutorial: This tutorial shows you how to use DB2's pureXML to expose the native XML capabilities of DB2.
• Buy: DB2 9 for Linux, UNIX and Windows

My developerWorks community

Dig deeper into XML on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers