1.5 Common XML Information-Modeling Pitfalls

We could easily arrange the XML fragments from the previous section in other, perfectly acceptable ways. There are many more, albeit syntactically correct, unfortunate ways to arrange the information. Common mistakes made when creating XML documents include:

Inadequate context describing what a data element is (incomplete use of tags)
Inadequate instructions on how to interpret data elements (incomplete use of attributes)
Use of attributes as data elements (improper use of attributes)
Use of data elements as metadata instead of using tags (indirection through use of name/value pairings)
Unnecessary, unrelated, or redundant tags (poor hierarchy construction)
Attributes that have nothing to do with data element interpretation (poor hierarchy construction or misuse of attributes)

These mistakes sap XML of its power and usefulness. Time devoted to good information modeling will be paid back many times over as other components of applications are developed. We can put a great deal of intelligence into XML documents, which means we do not have to put that intelligence, over and over again, into every system component.

Because XML is very flexible, it is easy to abuse. Sometimes the best way to illustrate how to do something is by counterexample. Much, if not most, of the XML we have seen is not well designed. It is not difficult to design XML with good grammar and good style, and doing so will save a lot of time and effort in the long run?to say nothing of how it will affect performance. The following sections contain a few examples of poorly constructed XML fragments.

1.5.1 Attributes Used as Data Elements

This may be the most common misuse of XML. Attributes should be used to describe how to interpret data elements, or describe something about them?in other words, attributes are a form of metadata. They are often used to contain data elements, and that runs counter to the purpose of attributes.

Listing 1.4 contains no data elements from readings at all; the attributes apply to nothing. Attributes that apply to nothing, obviously, describe how to interpret nothing.

Listing 1.4 XML with No Data Elements

<colorimeter_reading>
      <device> X-Rite Digital Swatchbook </device>
      <patch> cyan </patch>
      <RGB resolution=8 red=0 green=255 blue=255 />
</colorimeter_reading>

If we examine each attribute, especially the data portion (the part to the right of the equal sign), we can determine whether they actually represent data, or metadata:

resolution=8: This is a true attribute because the value "8" does not mean anything by itself; rather it is an instruction for interpreting data elements, and therefore it is metadata.
red=0: This is clearly actually data because it is a reading from the colorimeter; moreover, in order to be correctly interpreted, it requires the "resolution=8" attribute. This attribute does not tell us how to interpret data?it is data. Consequently it should be recast as a tag/data element pair.
green=255, blue=255: The previous analysis of "red=0" applies.

1.5.2 Data Elements Used as Metadata

This is often a result of emulating extensibility in a relational database. Instead of creating columns accounting for different fields, a database designer will create two columns: one for field type and one for field contents. This basically amounts to representing metadata in data element fields and is shown in Listing 1.5.

Listing 1.5 XML Data Elements Used as Metadata

<colorimeter_reading>
      <device> X-Rite Digital Swatchbook </device>
      <patch> cyan </patch>
      <RGB>
            <item>
                  <band> red </band>
                  <value> 0 </value>
            </item>
            <item>
                  <band> green </band>
                  <value> 255 </value>
            </item>
            <item>
                  <band> blue </band>
                  <value> 255 </value>
            </item>
      </RGB>
</colorimeter_reading>

If we decompose this document into an information context, we get Listing 1.6.

Listing 1.6 Information Context for Listing 1.5

<colorimeter_reading><device> X-Rite Digital Swatchbook
<colorimeter_reading><patch> cyan
<colorimeter_reading><RGB ><item><band> red
<colorimeter_reading><RGB ><item><value> 0
<colorimeter_reading><RGB ><item><band> green
<colorimeter_reading><RGB ><item><value> 255
<colorimeter_reading><RGB ><item><band> blue
<colorimeter_reading><RGB ><item><value> 255

Listing 1.6 translates to approximately the following in English:

This colorimeter reading is from an X-Rite Digital Swatchbook.
This colorimeter reading is for a patch called cyan.
This colorimeter reading item is RGB band red.
This colorimeter reading item is RGB and has a value of 0.
This colorimeter reading item is RGB band green.
This colorimeter reading item is RGB and has a value of 255.
This colorimeter reading item is RGB band red.
This colorimeter reading item is RGB and has a value of 255.

The last six lines are contextually weak. Lines 3, 5, and 7 don't contain any readings; they contain metadata about the lines following them. Lines 4, 6, and 8 don't adequately describe the readings they contain; they are informationally incomplete and ambiguous. In fact, lines 6 and 8 are exactly the same, even though the readings they represent have different meanings.

1.5.3 Inadequate Use of Tags

This is often a result of emulating extensibility in a relational database. Instead of building separate tables for different data structures, a database designer will create one table for many different data structures by using name/value pairs. This represents unnecessary indirection of metadata and an inappropriate grouping of data elements, to the detriment of performance (because what should be direct queries become joins) and reliability (because grouping is ambiguous). This is shown in Listing 1.7.

Listing 1.7 Use of Name/Value Pairs

<colorimeter_reading>
      <device> X-Rite Digital Swatchbook </device>
      <patch> cyan </patch>
      <mode> RGB </mode>
      <band> red </band>
      <value> 0 </value>
      <band> green </band>
      <value> 255 </value>
      <band> blue </band>
      <value> 255 </value>
</colorimeter_reading>

If we decompose this document into an information context, we get Listing 1.8.

Listing 1.8 Information Context for Listing 1.7

<colorimeter_reading><device> X-Rite Digital Swatchbook
<colorimeter_reading><patch> cyan
<colorimeter_reading><mode> RGB
<colorimeter_reading><band> red
<colorimeter_reading><value> 0
<colorimeter_reading><band> green
<colorimeter_reading><value> 255
<colorimeter_reading><band> blue
<colorimeter_reading><value> 255

Translated to English, Listing 1.8 becomes:

This colorimeter reading is from an X-Rite Digital Swatchbook.
This colorimeter reading is for a patch called cyan.
This colorimeter reading is in RGB mode.
This colorimeter reading is red.
This colorimeter reading has a value of 0.
This colorimeter reading is green.
This colorimeter reading has a value of 255.
This colorimeter reading is blue.
This colorimeter reading is has a value of 255.

The last six lines are contextually weak, and line 3 represents nothing but context. Lines 3, 4, 6, and 8 do not contain any readings; they contain metadata about the lines following them. Lines 5, 7, and 9 don't describe the readings they contain at all; they are informationally incomplete and ambiguous. In fact, lines 7 and 9 are exactly the same and contained within the same group, even though the readings they represent have different meanings and should belong to different groups. We could add tags to encapsulate reading elements into groups so that the bands and reading values are unambiguously related to each other. But first, we should determine whether each data element truly represents data. If we examine the data elements, we can determine whether they really represent data or metadata, and whether they have an adequate context:

X-Rite Digital Swatchbook: This is clearly data.
cyan: This is also clearly data.
RGB: Although this could be considered data in the academic sense, it is not of much value by itself. Furthermore, it is needed to understand the meaning of data elements following it.
red, green, and blue: These are also data in the academic sense only. They lack adequate context as well. For example, a colorimeter reading in the red band could mean a number of different things.
0, 255, and 255: These are the actual colorimeter readings; they are clearly data. They are, however, nearly devoid of critical context?namely the color mode and the color band they represent.