- Introduction
- XML as an Information Domain
- How XML Expresses Information
- Patterns in XML
- Common XML Information-Modeling Pitfalls
- A Very Simple Way to Design XML
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.6 A Very Simple Way to Design XML
One great advantage of XML information modeling over traditional data modeling is that it serves as a much more intuitive analog of reality. Because of this, a very simple method for designing XML documents produces surprisingly good results. In fact, it will produce better results than many, if not most, "industry standard" XML schemas. Forget that you will be using a computer to manage information—in fact, forget almost everything you know about computers. Instead, imagine that you will be managing your information manually, and design simple forms accordingly. First, make the preprinted parts of the forms into tags; second, make the parts you fill in into data elements; and third, change things like units into attributes. Obviously, doing so will not produce totally optimum results, but it will serve quite well—and it's a good way to start.
Let's look at a simple example—a telephone number directory. We will start with a manual entry form.
|
Telephone Directory Listing |
|
|
Name: |
John A. Doe |
|
Address: |
123 Main Street |
|
City: |
Pleasantville |
|
State: |
Maryland |
|
Zip Code: |
12345 |
|
Telephone: |
(999) 555-1234 |
If we convert this directly into an XML document (spaces become underscores), we get Listing 1.9.
Listing 1.9 Telephone Directory Listing as XML
<Telephone_Directory_Listing>
<Name> John A. Doe </Name>
<Address> 123 Main Street </Address>
<City> Pleasantville </City>
<State> MD </State>
<Zip_Code> 12345 </Zip_Code>
<Telephone> (999) 555-1234 </Telephone>
</Telephone_Directory_Listing>
Now we will make some small changes. First, we will separate the name into first, middle initial, and last name, and group them together. We will also group the address and separate the telephone number and area code into its own group. Separating fields, such as the name, makes it possible to use the components as individual query terms that will be serviced with direct lookups instead of requiring partial content scans within fields. This significantly improves performance in cases where a query, for example, might be for "John Doe" instead of "John A. Doe". The resulting XML is shown in Listing 1.10.
Listing 1.10 Telephone Directory Listing in XML after Changes
<Telephone_Directory_Listing>
<Name>
<First> John </First>
<MI> A. </MI>
<Last> Doe </Last>
</Name>
<Address>
<Street> 123 Main Street </Street>
<City> Pleasantville </City>
<State> MD </State>
<Zip_Code> 12345 </Zip_Code>
</Address>
<Telephone>
<Area_Code> 999 </Area_Code>
<Number> 555-1234 <Number>
</Telephone>
</Telephone_Directory_Listing>
The XML document in Listing 1.10 would serve as a good basis for a telephone directory. When thinking about additional information that may have to be added to some listings (additional address lines, additional telephone numbers, etc.), it is important to remember that XML is extensible; a field has to be added only when it is necessary—not globally to all listings.
Many businesses are basically forms driven. For example, clinical trials in the pharmaceutical industry start with forms that have to be approved before the computer systems managing the information can be designed. Because forms can be converted into XML so easily, it is now possible to build systems that are driven primarily by business objectives in intuitive ways, rather than by abstract computing paradigms.