Skip to main content

If you don't have an IBM ID and password, register here.

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. This profile includes the first name, last name, and display name you identified when you registered with developerWorks. Select information in your developerWorks profile is displayed to the public, but you may edit the information at any time. Your first name, last name (unless you choose to hide them), and display name will accompany the content that you post.

All information submitted is secure.

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

XML for Data: XSL style sheets: push or pull?

A look at two authoring techniques for XSL style sheets and how they stack up for data

Kevin Williams (kevin@blueoxide.com), CEO, Blue Oxide Technologies, LLC
Kevin Williams is the CEO of Blue Oxide Technologies, LLC, a company that designs XML and Web service creation software. Visit the company Web site at http://www.blueoxide.com. He can be reached for comment at kevin@blueoxide.com.

Summary:  Columnist Kevin Williams examines the two most common authoring styles used to create XSL style sheets: push and pull. He takes a look at some simple XML and XSL examples and discusses the benefits and drawbacks of each approach.

View more content in this series

Date:  01 May 2002
Level:  Introductory

Comments:  

When authoring XSL style sheets, you can use either of two principal authoring styles:

  • The push style is structured around handlers that create output in the output document. The output is based on the type of elements encountered in the source document. Element content is pushed to the appropriate handler.
  • The pull style, on the other hand, builds up the output document by pulling content from the source document as it is needed.

The style you choose has a significant impact on the code complexity and maintainability of your style sheets.

Push style sheets

Push style sheets are the classic form of style sheets. All the major XSL generation tools produce them, and they are the forms usually discussed in XSL references. Style sheets in this form consist of a series of xsl:template elements, each of which handles a specific element type in the document. For example, suppose you have the following source document:


<Orders>
  <Invoice>
    <CustomerName>Kevin Williams</CustomerName>
    <Address>100 Nowhere Lane</Address>
    <City>Nowheresville</City>
    <State>VA</State>
    <Zip>24182</Zip>
    <Item>
      <ID>E38-19273</ID>
      <Description>3-inch Grommets</Description>
      <Count>37</Count>
      <TotalCost>37.00</TotalCost>
    </Item>
    <Item>
      <ID>E22-18272</ID>
      <Description>2-inch Widgets</Description>
      <Count>22</Count>
      <TotalCost>11.00</TotalCost>
    </Item>
  </Invoice>
  <Invoice>
    <CustomerName>John Public</CustomerName>
    <Address>200 Anywhere Street</Address>
    <City>Anytown</City>
    <State>VA</State>
    <Zip>24177</Zip>
    <Item>
      <ID>E22-18272</ID>
      <Description>2-inch Widgets</Description>
      <Count>27</Count>
      <TotalCost>13.50</TotalCost>
    </Item>
    <Item>
      <ID>E19-28376</ID>
      <Description>1-inch Bolts</Description>
      <Count>16</Count>
      <TotalCost>4.00</TotalCost>
    </Item>
  </Invoice>
</Orders>

Now suppose you want to transform it to the following XHTML document:

<html>
  <body>
    <h1>Kevin Williams</h1>
    <p>100 Nowhere Lane<br />
    Nowheresville, VA 24182</p>
    <table>
      <tr>
        <th>Description</th>
        <th>Cost</th>
      </tr>
      <tr>
        <td>3-inch Grommets</td>
        <td>37.00</td>
      </tr>
      <tr>
        <td>2-inch Widgets</td>
        <td>11.00</td>
      </tr>
    </table>
    <p />
    <h1>John Public</h1>
    <p>200 Anywhere Street<br />
    Anytown, VA 24177</p>
    <table>
      <tr>
        <th>Description</th>
        <th>Cost</th>
      </tr>
      <tr>
        <td>2-inch Widgets</td>
        <td>13.50</td>
      </tr>
      <tr>
        <td>1-inch Bolts</td>
        <td>4.00</td>
      </tr>
    </table>
  </body>
</html>

You need to create a series of templates in your style sheet. The templates handle each of the different elements that you want to carry over to the output document. Each template also has to create the supporting XHTML element structures, like the table headers and rows. A style sheet that uses the push method to create the output shown in Listing 2 from the source document (Listing 1) would look like this:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
    version="1.0">
  <xsl:template match="Orders">
    <html>
      <body>
        <xsl:apply-templates select="Invoice"/>
      </body>
    </html>
  </xsl:template>
  <xsl:template match="Invoice">
    <xsl:apply-templates select="CustomerName" />
    <p>
      <xsl:apply-templates select="Address" />
      <xsl:apply-templates select="City" />
      <xsl:apply-templates select="State" />
      <xsl:apply-templates select="Zip" />
    </p>
    <table>
      <tr>
        <th>Description</th>
        <th>Cost</th>
      </tr>
      <xsl:apply-templates select="Item" />
    </table>
    <p />
  </xsl:template>
  <xsl:template match="CustomerName">
    <h1><xsl:value-of select="." /></h1>
  </xsl:template>
  <xsl:template match="Address">
    <xsl:value-of select="." /><br />
  </xsl:template>
  <xsl:template match="City">
    <xsl:value-of select="." />
    <xsl:text>, </xsl:text>
  </xsl:template>
  <xsl:template match="State">
    <xsl:value-of select="." />
    <xsl:text> </xsl:text>
  </xsl:template>
  <xsl:template match="Zip">
    <xsl:value-of select="." />
  </xsl:template>
  <xsl:template match="Item">
    <tr>
      <xsl:apply-templates />
    </tr>
  </xsl:template>
  <xsl:template match="Description">
    <td><xsl:value-of select="." /></td>
  </xsl:template>
  <xsl:template match="TotalCost">
    <td><xsl:value-of select="." /></td>
  </xsl:template>
  <xsl:template match="*">
    <xsl:apply-templates />
  </xsl:template>
  <xsl:template match="text()" />
</xsl:stylesheet>

Notice two interesting additions that you should include in the style sheet:

  • A null template at the end ensures that unwanted content (such as the unit cost for items on the invoice) is omitted from the output document.
  • A template that processes all of its children in document order ensures that processing occurs all the way down the source tree. That way, you won't miss any invoice content simply because you don't have a specific invoice template.

As you can see, this structure is a little clunky. While authoring the code is straightforward enough, maintaining the code can be tricky. Even with this very simple example, if you want to find out how the XHTML table is populated, you must jump from template to template to discover where the td objects are created. In more complicated examples, you could have pages and pages of templates, many of which are called from other templates. Maintenance of this code is even more difficult.


Pull style sheets

Pull style sheets, on the other hand, rely on the coder's ability to know which elements are expected to appear next in the source document. The code explicitly iterates through repeating elements, creating the appropriate structures in the output and pulling values from the source as necessary. Here's a style sheet that performs the same translation as the one in Listing 2 but uses a pull strategy rather than a push strategy:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
    version="1.0">
  <xsl:template match="Orders">
    <html>
      <body>
        <xsl:for-each select="Invoice">
          <h1>
            <xsl:value-of select="CustomerName" />
          </h1>
          <p>
            <xsl:value-of select="Address" /><br />
            <xsl:value-of select="City" />
            <xsl:text>, </xsl:text>
            <xsl:value-of select="State" />
            <xsl:text> </xsl:text>
            <xsl:value-of select="Zip" />
          </p>
          <table>
            <tr>
              <th>Description</th>
              <th>Cost</th>
            </tr>
            <xsl:for-each select="Item">
              <tr>
                <td><xsl:value-of select="Description" /></td>
                <td><xsl:value-of select="TotalCost" /></td>
              </tr>
            </xsl:for-each>
          </table>
          <p />            
        </xsl:for-each>
      </body>
    </html>
  </xsl:template>
</xsl:stylesheet>

In this form of the style sheet, you only have one template, which corresponds to the root of the information that you are trying to retrieve. Nested information embedded in the source document is retrieved by using the xsl:for-each element to process all of the children of the current node of a specific type. As you can see, this style sheet is much easier to read. It is shorter than the push form of the style sheet, and its layout corresponds closely to the desired layout of the output document. When coding with the pull form, you can simply take a sample of the desired output, add it to a top-level template. Then, you can replace the values in the sample with appropriate code to retrieve the values from the source document.


So pull is always better than push, right?

While the pull form certainly has advantages over the push form (readability, brevity, and easy-to-read layout), you should choose your style sheet based on the characteristics of the source document. Look at this example of a structure that contains a narrative describing a fictional medical procedure:

<SurgeryLog>
  <Narrative>
    <section time="13:00:00">First, the surgeon used the <tool>3-inch 
    scalpel</tool> to make a <procedure>two-inch incision</procedure> 
    in the patient's <location>lower left abdomen</location>. 
    <procedure>Cautery</procedure> was then applied to the 
    <target>severed blood vessels</target> to stop the 
    bleeding.</section>
    <section time="13:14:23">The surgeon then <procedure>cleaned and 
    dressed the incision</procedure>, using <tool>four two-by-two 
    sterile gauze pads</tool> and <tool>medium sutures</tool>.</section>
  </Narrative>
</SurgeryLog>

In this narrative, information might appear in any order. The document might have two tool clauses followed by a procedure clause, or three location clauses in a row. Suppose you want to produce output that looks like this:

<html>
  <body>
    <h1>Surgery Log</h1>
    <p><b>13:00:00</b></p>
    <p>First, the surgeon used the <i>3-inch scalpel</i> to make a 
    <font color="#FF8800">two-inch incision</font> in the patient's 
    lower left  abdomen. <font color="#FF8800">Cautery</font> was 
    then applied to the severed blood vessels to stop the bleeding.</p>
    <p><b>13:14:23</b></p>
    <p>The surgeon then <font color="#FF8800">cleaned and dressed 
    the incision</font>, using <i>four two-by-two sterile gauze pads</i> 
    and <i>medium sutures</i>.
  </body>
</html>

The great thing about the push form of style sheets is that the order in which information appears no longer matters. The following style sheet processes the source XML in Listing 5 into the desired XHTML:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
    version="1.0">
  <xsl:template match="SurgeryLog/Narrative">
    <html>
      <body>
        <h1>Surgery Log</h1>
        <xsl:apply-templates />
      </body>
    </html>
  </xsl:template>
  <xsl:template match="section">
    <p>
      <b>
        <xsl:value-of select="@time" />
      </b>
    </p>
    <xsl:apply-templates />
  </xsl:template>
  <xsl:template match="tool">
    <i>
      <xsl:apply-templates />
    </i>
  </xsl:template>
  <xsl:template match="procedure">
    <font color="#FF8800">
      <xsl:apply-templates />
    </font>
  </xsl:template>
</xsl:stylesheet>

Notice how nested items are not a big concern now because the templates are automatically processed in the correct order. You can handle more complex cases, such as that in Listing 8, in which a procedure element contains a tool element:

<SurgeryLog>
  <Narrative>
    <section time="13:00:00">First, the surgeon <procedure>used the 
    <tool>3-inch scalpel</tool> to make a two-inch incision</procedure> 
    in the patient's <location>lower left abdomen</location>. 
    <procedure>Cautery</procedure> was then applied to the 
    <target>severed blood vessels</target> to stop the 
    bleeding.</section>
    <section time="13:14:23">The surgeon then <procedure>cleaned and 
    dressed the incision</procedure>, using <tool>four two-by-two 
    sterile gauze pads</tool> and <tool>medium sutures</tool>.</section>
  </Narrative>
</SurgeryLog>

When the style sheet is applied to this source, the result is just as expected: The tool that appears embedded in the procedure is both italicized and orange. Now, look at the same style sheet authored using the pull style:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
    version="1.0">
  <xsl:template match="SurgeryLog/Narrative">
    <html>
      <body>
        <h1>Surgery Log</h1>
        <xsl:for-each select="section">
          <p>
            <b>
              <xsl:value-of select="./@time" />
            </b>
          </p>
          <p>
            <xsl:for-each select="*|text()">
              <xsl:choose>
                <xsl:when test="name()='procedure'">
                  <font color="#FF8800">
                    <xsl:value-of select="." />
                  </font>
                </xsl:when>
                <xsl:when test="name()='tool'">
                  <i>
                    <xsl:value-of select="." />
                  </i>
                </xsl:when>
                <xsl:otherwise>
                  <xsl:value-of select="." />
                </xsl:otherwise>
              </xsl:choose>
            </xsl:for-each>
          </p>
        </xsl:for-each>
      </body>
    </html>
  </xsl:template>
</xsl:stylesheet>

Note how clunky this pull style sheet is. You have to check each node, and -- if that node requires special handling -- add the appropriate formatting to it. This doesn't even deal with the complex case cited in Listing 8. This code ignores the tool markup inside the procedure markup. If you extended the style sheet to properly handle all the possible nestings of tools, targets, procedures, and so on, the style sheet would quickly balloon to an unwieldy (and unmaintainable) size.


Conclusion

These examples demonstrate a point that I've made in most of my columns: A data document is intrinsically different from a narrative document in that:

  • Information in a data document appears in an order that can be anticipated in the code.
  • A data document contains no loose text, so no specialized code is required to transfer that text to the output document.

Mapping a source data document to a output document usually is no more complex than renaming elements, reordering them, and aggregating them up a level in the target tree (or pushing them down to a more detailed level). If you use the pull model, the mapping is simple and easy to maintain.

On the other hand, documents that are narrative-based are exactly the opposite.

  • Information appears in an order that cannot be anticipated easily.
  • Some text floats outside of the context of elements so it needs to be moved over to the output document properly.

To accurately reproduce the narrative in the output document, the style sheet must handle elements regardless of where they appear, and the push model excels at that.

In short, when designing style sheets for data documents, consider using the pull model first. For narrative documents, use the push model if possible. Becoming proficient at writing both kinds of style sheets -- and learning the strengths and weaknesses of each -- will enable you to handle any styling job you might encounter in the future.


Resources

About the author

Kevin Williams is the CEO of Blue Oxide Technologies, LLC, a company that designs XML and Web service creation software. Visit the company Web site at http://www.blueoxide.com. He can be reached for comment at kevin@blueoxide.com.

Report abuse help

Report abuse

Thank you. This entry has been flagged for moderator attention.


Report abuse help

Report abuse

Report abuse submission failed. Please try again later.


developerWorks: Sign in

If you don't have an IBM ID and password, register here.


Forgot your IBM ID?


Forgot your password?
Change your password


By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. This profile includes the first name, last name, and display name you identified when you registered with developerWorks. Select information in your developerWorks profile is displayed to the public, but you may edit the information at any time. Your first name, last name (unless you choose to hide them), and display name will accompany the content that you post.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

(Must be between 3 – 31 characters.)


By clicking Submit, you agree to the developerWorks terms of use.

 


Rate this article

Comments

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=XML
ArticleID=12106
ArticleTitle=XML for Data: XSL style sheets: push or pull?
publish-date=05012002
author1-email=kevin@blueoxide.com
author1-email-cc=

Tags

Help
Use the search field to find all types of content in My developerWorks with that tag.

Use the slider bar to see more or fewer tags.

For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.

For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.

Use the search field to find all types of content in My developerWorks with that tag. Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere). My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).