This article originally appeared as an XML e-newsletter.
By Brian Schaffner
When designing your XML solution, you have to make many decisions. These decisions will help shape your solution and define how your XML documents are built. Let's look at some of these decisions; then, we'll offer tips for steering you in the right direction.
One of the first design areas to investigate is granularity. This defines how detailed your XML document will be. On the surface, the answer may be obvious—it needs to be as detailed as your data. The question, though, is how much data belongs in a single document. Will your document contain an item, a group of items or transaction, a group of transactions, or something else altogether?
For example, Listing A shows a document containing an item; Listing B shows a document containing a group of transactions.
Listing A: item.xml
Listing B: transgroup.xml
The granularity of your documents may be driven less by your ideal design and more by the systems you're integrating. For example, if the source or target system has a predefined granularity, you may have less flexibility.
Grouping and containment
Another common design decision is how you're going to arrange the data in your documents into meaningful, logical groups. You also need to decide whether to constrain the items in those groups with containers. The solution is a little more difficult depending on your particular data. There are many design patterns that you can apply to help define the internal structure of your document.
The grouping and containment will be somewhat related to the granularity of the document. At a higher level, you might have a series of sets, and even a container for that series, depending on if there is information outside of the transactions in your document.
It shouldn't be a design decision to be consistent—it should be a fact of life.
A key component of a successful design is consistency. This means having well-defined rules and patterns for your XML document. If you usually put a series of like elements in a container, then you should always try to do so. Listing C shows an example of what not to do.
Listing C: badexample.xml
Naming standards can be particularly problematic when it comes to consistency. Your documents should follow precise rules for element names with regards to capitalization and abbreviations. For instance, if you use an element called UserId in one spot, don't use ObjectID or ObjectIdentifier somewhere else—it's confusing and difficult to remember which is which. A single rule that says Identifier is always abbreviated as Id is much easier to remember.
Brian Schaffner is an associate director for Fujitsu Consulting. He provides architecture, design, and development support for Fujitsu's Technology Consulting practice.