Skip to main content

skip to main content

developerWorks  >  XML  >

XML for Data: Styling with schemas

Using XML Schema archetypes and XSLT style sheets to simplify your code

developerWorks
Document options

Document options requiring JavaScript are not displayed


Rate this page

Help us improve this content


Level: Introductory

Kevin Williams (kevin@blueoxide.com), Chief XML architect, Equient (a division of Veridian)

01 Jul 2001

This column by developer and author Kevin Williams demonstrates how to use XML Schema archetyping (and style sheets) to control styling of data for various presentation modes. Ten code samples in XML, XML Schema, and XSLT show how the techniques work to reduce code bulk and simplify maintenance.

In my previous column, I described how simple and complex archetypes (see the sidebar What are archetypes?) may be used to simplify and streamline your XML schema designs. This column takes a look at one practical application of XML Schema archetypes: using style sheets to provide a consistent rendering of archetypes in the presentation layer.

Isn't presentation a fairly simple process?

How simple the presentation process is depends on how you define simple. When you work with XML for data, often you need to represent certain information in a consistent manner. For example, whenever you have a color display you might want to render balances for a bank account as black numbers if they are positive, and as red numbers if they are negative. It's easy enough to write XSLT code that takes a particular element value and renders it this way. The need to repeat that style code everywhere it is needed (for all the various views of your information, and for each piece of information that needs to be styled the same way) makes copy-and-paste errors a real danger. Let's take a look at a quick example. Say you had a document defined by the XML schema in Listing 1.

<?xml version="1.0" encoding="utf-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
   <xs:element name="customer" type="customerType" />
   <xs:complexType name="customerType">
      <xs:sequence>
         <xs:element name="customerID" type="xs:integer" />
         <xs:element name="checkingBalance">
           <xs:simpleType>
             <xs:restriction base="xs:decimal">
               <xs:totalDigits value="10" />
               <xs:fractionDigits value="10" />
             </xs:restriction>
           </xs:simpleType>
         </xs:element>  
         <xs:element name="savingsBalance">
           <xs:simpleType>
             <xs:restriction base="xs:decimal">
               <xs:totalDigits value="10" />
               <xs:fractionDigits value="10" />
             </xs:restriction>
           </xs:simpleType>
         </xs:element>  
      </xs:sequence>
   </xs:complexType>
</xs:schema>

In order to style the savingsBalance and checkingBalance elements properly, you might create a template in your XSLT style sheet that looks like Listing 2.

  <xsl:template match="savingsBalance | checkingBalance">
    <xsl:element name="{name()}">
      <xsl:value-of select="format-number(text(), '###,###,##0.00')" />
    </xsl:element>
  </xsl:template>

What are archetypes?

Archetypes are common definitions that can be shared across different elements in your XML schemas. In early versions of the XML Schema specification, archetypes had their own declarations; in the released version, however, archetypes are implemented using the simpleType and complexType elements. My previous column gives some examples.

However, you can see that if you add a new element that represents a balance, you'll need to change the template. This might be a problem if you have many different source document types and many different rendering targets (such as wireless platforms, other XML formats, and so on). What you'd like to be able to do is write one style sheet that handles all of the balance-type fields in the original document, without having to recode each new document type you create. The secret is to define simple archetypes in the XML schema and take advantage of them to save you effort.



Back to top


Taking advantage of archetypes

Let's revisit the XML structure from Listing 1 and add a simple archetype that represents balance information. The schema would then look something like Listing 3.

<?xml version="1.0" encoding="utf-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
   <xs:element name="customer" type="customerType" />
   <xs:complexType name="customerType">
      <xs:sequence>
         <xs:element name="customerID" type="xs:integer" />
         <xs:element name="checkingBalance" type="balance" />
         <xs:element name="savingsBalance" type="balance" />
      </xs:sequence>
   </xs:complexType>
   <xs:simpleType name="balance">   
     <xs:restriction base="xs:decimal">
       <xs:totalDigits value="10" />
       <xs:fractionDigits value="10" />
     </xs:restriction>
   </xs:simpleType>
</xs:schema>

Note that the XML schema declaration using archetypes is smaller and, arguably, easier to read. You gain other benefits from structuring the schemas that way, as you'll see later in this column. You can take advantage of the fact that an XML schema is just an XML document and write a style sheet that processes it into another form. Listing 4 illustrates a style sheet that takes the XML schema and creates another style sheet from it.

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xsl:strip-space elements="*" />
  <xsl:template match="/">
    <xsl:element name="xsl:stylesheet">
      <xsl:apply-templates />
    </xsl:element>
  </xsl:template>
  <xsl:template match="xs:element[@type='balance']">
    <xsl:element name="xsl:template">
      <xsl:attribute name="match"><xsl:value-of select="@name" /></xsl:attribute>
      <xsl:element name="xsl:element">
        <xsl:attribute name="name"><xsl:value-of select="@name" /></xsl:attribute>
        <xsl:element name="xsl:value-of">
          <xsl:attribute name="select">format-number(text(),
           '###,###,##0.00')</xsl:attribute>
        </xsl:element>
      </xsl:element>      
    </xsl:element>
  </xsl:template>      
</xsl:stylesheet>

There are a few things worth noting in the style sheet in Listing 4. First, it declares the XML schema namespace up front, because the XSLT processor needs to be aware that you intend it to match on elements in the original schema that are declared in the XML schema namespace. Next, space stripping for all elements is turned on. Because this style sheet is not intended to be human-readable, you can save space by compressing the result as much as possible. Also, note that matching is driven by the archetypes: No reference is made to the specific elements in the original schema document. Instead, it looks to match elements of the type balance. Additionally, you need to include the actual style code only once for an archetype. When you use this style sheet to style the original schema fragment, the resulting presentation style sheet would look something like Listing 5.

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="checkingBalance">
    <xsl:element name="checkingBalance">
      <xsl:value-of select="format-number(text(), '###,###,##0.00')"/>
    </xsl:element>
  </xsl:template>
  <xsl:template match="savingsBalance">
    <xsl:element name="savingsBalance">
      <xsl:value-of select="format-number(text(), '###,###,##0.00')"/>
    </xsl:element>
  </xsl:template>
</xsl:stylesheet>

By generating the style sheets dynamically whenever the schema changes, you greatly reduce code size and the chance of introducing copy-and-paste errors. For example, let's say you decide to change the document structure to look like Listing 6.

<?xml version="1.0" encoding="utf-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
   <xs:element name="customer" type="customerType" />
   <xs:complexType name="customerType">
      <xs:sequence>
         <xs:element name="customerID" type="xs:integer" />
         <xs:element name="checkingBalance" type="balance" />
         <xs:element name="savingsBalance" type="balance" />
         <xs:element name="moneyMarketBalance" type="balance" />
      </xs:sequence>
   </xs:complexType>
   <xs:simpleType name="balance">   
     <xs:restriction base="xs:decimal">
       <xs:totalDigits value="10" />
       <xs:fractionDigits value="10" />
     </xs:restriction>
   </xs:simpleType>
</xs:schema>

Since the system automatically regenerates the presentation style sheets for each new version of the schema, you just run the schema through the same style sheet (from Listing 4) to generate the following style sheet (again with whitespace added) that includes moneyMarketBalance.

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="checkingBalance">
    <xsl:element name="checkingBalance">
      <xsl:value-of select="format-number(text(), '###,###,##0.00')"/>
    </xsl:element>
  </xsl:template>
  <xsl:template match="savingsBalance">
    <xsl:element name="savingsBalance">
      <xsl:value-of select="format-number(text(), '###,###,##0.00')"/>
    </xsl:element>
  </xsl:template>
  <xsl:template match="moneyMarketBalance">
    <xsl:element name="moneyMarketBalance">
      <xsl:value-of select="format-number(text(), '###,###,##0.00')"/>
    </xsl:element>
  </xsl:template>
</xsl:stylesheet>

Thus, without modifying the style sheets, you can properly render changes in the source document (as long as you use archetypes properly). This makes it very easy to create new source document types or change the presentation format of archetypes without having to search and replace through hundreds of style sheets.



Back to top


Complex archetypes

The strategy of styling schemas also extends to the handling of complex archetypes. By using a style sheet to define a template that matches an element with a particular archetype, you can further simplify the code. Take a look at another example: Say you have a document whose schema looks like Listing 8.

<?xml version="1.0" encoding="utf-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
   <xs:element name="customer" type="customerType" />
   <xs:complexType name="customerType">
      <xs:sequence>
         <xs:element name="customerID" type="xs:integer" />
         <xs:element name="mailingAddress" type="address" />
         <xs:element name="shippingAddress" type="address" />
      </xs:sequence>
   </xs:complexType>
   <xs:complexType name="address">   
     <xs:sequence>
       <xs:element name="address1" type="xs:string" />
       <xs:element name="address2" type="xs:string" minOccurs="0" />
       <xs:element name="city" type="xs:string" />
       <xs:element name="state" type="xs:string" />
       <xs:element name="zip" type="xs:string" />
     </xs:sequence>
   </xs:complexType>
</xs:schema>

You can leverage the address archetype defined in the style sheet-generating style sheet to ensure that both mailing and shipping addresses are rendered consistently, as shown in Listing 9.

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xsl:template match="/">
    <xsl:element name="xsl:stylesheet">
      <xsl:element name="xsl:output">
        <xsl:attribute name="method">html</xsl:attribute>
      </xsl:element>
      <xsl:apply-templates />
    </xsl:element>
  </xsl:template>
  <xsl:template match="xs:element[@type='address']">
    <xsl:element name="xsl:template">
      <xsl:attribute name="match"><xsl:value-of select="@name" /></xsl:attribute>
      <xsl:element name="p">
        <xsl:element name="xsl:value-of">
          <xsl:attribute name="select">address1/text()</xsl:attribute>
        </xsl:element>
        <xsl:element name="br" />
        <xsl:element name="xsl:value-of">
          <xsl:attribute name="select">address2/text()</xsl:attribute>
        </xsl:element>
        <xsl:element name="br" />
        <xsl:element name="xsl:value-of">
          <xsl:attribute name="select">concat(city/text(), ', ', 
           state/text(), ' ', 
           zip/text())</xsl:attribute>
        </xsl:element>
      </xsl:element>
    </xsl:element>
  </xsl:template>
</xsl:stylesheet>

When the style sheet generator in Listing 9 is run against the original schema, it generates the following style sheet in Listing 10.

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="html"/>
  <xsl:template match="mailingAddress">
    <p>
      <xsl:value-of select="address1/text()"/>
      <br/>
      <xsl:value-of select="address2/text()"/>
      <br/>
      <xsl:value-of select="concat(city/text(), ', ', 
       state/text(), ' ', zip/text())"/>
    </p>
  </xsl:template>
  <xsl:template match="shippingAddress">
    <p>
      <xsl:value-of select="address1/text()"/>
      <br/>
      <xsl:value-of select="address2/text()"/>
      <br/>
      <xsl:value-of select="concat(city/text(), ', ', 
       state/text(), ' ', zip/text())"/>
    </p>
  </xsl:template>
</xsl:stylesheet>

Using this technique to style complex archetypes is particularly useful when trying to target the same source XML document type for different target media. For example, if you were sending the address information to a cell phone display, you might include only the city and state.



Back to top


Conclusion

This column outlines the way you can use archetypes to streamline your coding experience. This discussion really only scratches the surface. In a large system that must support many presentation targets (HTML, wireless, other machine consumers) and many different source-document types (for bandwidth reduction or security reasons), using archetypes properly makes it very easy to keep your style sheet output consistent and correct.



Resources



About the author

Kevin Williams is the chief XML architect for Equient, a division of Veridian specializing in XML design for information management systems. He has also co-written several books on XML from Wrox Press. He can be reached for comment at kevin@blueoxide.com. Random XML musings, tips, tricks, and opinionated rants may be found at his Web site www.blueoxide.com.




Rate this page


Please take a moment to complete this form to help us better serve you.



 


 


Not
useful		Extremely
useful
 


Share this....

digg Digg this story del.icio.us del.icio.us Slashdot Slashdot it!



Back to top