Improve consistency with the Parallel Design pattern

By Brian Schaffner

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.

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.