Developer

Apply the Role Attribute design pattern

Use the Role Attribute pattern when designing document type definitions (DTD) and schemas for new XML grammars. Here's how.

This article originally appeared as an XML e-newsletter.

By Brian Schaffner

When designing document type definitions (DTD) and schemas for new XML grammars, it's often difficult to know exactly how all the pieces of data will be used. Sometimes you simply need a more precise or specific way of defining a particular element. In these types of situations, the Role Attribute pattern can help.

A sample problem

Let's start with a sample problem that you can solve using the Role Attribute pattern. Suppose you have an XML document, like the one shown in Listing A. This document shows a simple customer record with several address components:

Listing A: customer.xml
<Customer>
  <Name>Widgets R Us</Name>
  <Address>
    <Street>1234 Broadway</Street>
    <City>New York</City>
    <State>NY</State>
    <ZipCode>10010</ZipCode>
  </Address>
  <Address>
    <Street>900 N Michigan Ave</Street>
    <City>Chicago</City>
    <State>IL</State>
    <ZipCode>60614</ZipCode>
  </Address>
  <Address>
    <Street>3000 Cumberland Blvd</Street>
    <City>Atlanta</City>
    <State>GA</State>
    <ZipCode>30039</ZipCode>
  </Address>
</Customer>

The problem with this document is that there are three addresses. It's difficult to discern the difference between these elements without looking at the data.

The pattern basics

The building blocks of this pattern are a basic element and attribute. In our example above, we demonstrated the need to further define the use of the Address element. To solve the problem, we'll apply the Role Attribute pattern.

In essence, the solution is to add a new attribute to the Address element, which will be used to define the role of the element in the particular context. In our example document, we have used three Address elements. The role for these addresses could be different departments or simply different branch offices.

For our purposes, we'll define these addresses as a corporate address, an accounting address, and a shipping address. It's not uncommon for businesses to have this many or even more addresses attached to their customer record.

The DTD

In order to define and reinforce our pattern, we'll use a DTD to spell out the rules. Listing B shows the customer.dtd file and illustrates our use of the Role Attribute pattern. In addition to rules regarding our element structure, we've also included an attribute list item identifying the attribute called Role, attached to the Address element:

Listing B: customer.dtd
<!ELEMENT Customer (Name, Address+)>
<!ELEMENT Address (Street+,City,State,Zip)>
<!ATTLIST Address Role CDATA>
<!ELEMENT Street (#PCDATA)>
<!ELEMENT City (#PCDATA)>
<!ELEMENT State (#PCDATA)>
<!ELEMENT Zip (#PCDATA)>

Final solution

Now we can apply this DTD to our previous XML example to create a more meaningful document. Listing C shows our new customer.xml document, with the added Role attributes defined for each Address element.

Listing C: customer2.xml
<Customer>
  <Name>Widgets R Us</Name>
  <Address Role="Corporate Office">
    <Street>1234 Broadway</Street>
    <City>New York</City>
    <State>NY</State>
    <ZipCode>10010</ZipCode>
  </Address>
  <Address Role="Billing Office">
    <Street>900 N Michigan Ave</Street>
    <City>Chicago</City>
    <State>IL</State>
    <ZipCode>60614</ZipCode>
  </Address>
  <Address Role="Receiving Office">
    <Street>3000 Cumberland Blvd</Street>
    <City>Atlanta</City>
    <State>GA</State>
    <ZipCode>30039</ZipCode>
  </Address>
</Customer>

Brian Schaffner is an associate director for Fujitsu Consulting. He provides architecture, design, and development support for Fujitsu's Technology Consulting practice.

Editor's Picks