Presents your 
XML E-NEWSLETTER for April 16, 2003

<------------------------------------------->

APPLY THE ROLE ATTRIBUTE DESIGN PATTERN

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.

----------------------------------------