Presents your 
XML E-NEWSLETTER for May 21, 2003

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

IMPROVE CONSISTENCY WITH THE PARALLEL DESIGN PATTERN

A key problem that keeps XML from proliferating more than it has is
consistency. Having a standard, predictable, and possibly intuitive XML
grammar would make for faster and greater acceptance. One way to improve the
consistency in your XML documents is to use the Parallel Design pattern.

THE PROBLEM

Suppose you have a document that contains several elements that are
similar--or that, at least, have some similar characteristics. Often these
are items that are more concrete and less abstract.

When designing your document, you describe each item in a variety of
different ways. However, if you choose a different approach for each
element, then learning your document becomes more difficult.

Inconsistent structures within your grammar and, therefore, within your
document forces users to remember the complex structure or constantly
refer to the documentation--both of which can dissuade solution
implementation and cause problems with the documents.

THE SOLUTION

While you have the option to describe your XML data any way you want,
you will benefit from following some simple rules and, in particular, by
employing the Parallel Design pattern.

Like most design patterns, there aren't any hard and fast rules about
when to use them or how to use them. Instead, they are rough sketches 
of
solutions to abstract problems. Your job is to implement the pattern to
solve the particular problem you are having.

The Parallel Design pattern uses the concept of consistency to help your
documents feel more intuitive. For example, a CD player, a tape player,
and a DVD player all use the same basic controls--play, stop, fast
forward, rewind, pause, and eject. This is not an accident. It's a feature of
the Parallel Design pattern that makes each device intuitive to the user
once they know the rules. Let's look at how to apply this to XML documents.

AN EXAMPLE

We'll start with an example of a problem XML document. LISTING A shows
part of an order document that contains two customer addresses. The first
address is the shipping address and consists of two address line
elements. The second address uses a special Address element to describe the
information; it uses the street number and street name as separate elements,
as well as the city, state, and zip code.

Listing A: badorder.xml
<Order>
  <Customer>
    <ShippingAddress>
      <AddressLine1>900 N. Michigan</AddressLine1>
      <AddressLine2>Chicago, IL 60614</AddressLine2>
    </ShippingAddress>
    <Address type="billing">
      <StreetNo>900</StreetNo>
      <StreetName>N. Michigan</StreetName>
      <City>Chicago</City>
      <State>IL</State>
      <Zip>60614</Zip>
    </Address>
  </Customer>
</Order>

You immediately realize that this is a bad design, which you can fix by
employing the Parallel Design pattern. Rather than have inconsistent
elements and counter-intuitive rules for defining data, we should make our
design parallel so that similar information is conveyed in a similar way.

Since the second approach is a little more structured, we'll choose it
as our "standard." Next, we modify the first address section to be
parallel to the second by using the same structure. LISTING B shows our revised
document using the Parallel Design pattern.

Listing B: goodorder.xml
<Order>
  <Customer>
    <Address type="shipping">
      <StreetNo>900</StreetNo>
      <StreetName>N. Michigan</StreetName>
      <City>Chicago</City>
      <State>IL</State>
      <Zip>60614</Zip>
    </Address>
    <Address type="billing">
      <StreetNo>900</StreetNo>
      <StreetName>N. Michigan</StreetName>
      <City>Chicago</City>
      <State>IL</State>
      <Zip>60614</Zip>
    </Address>
  </Customer>
</Order>

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

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