Valid XML Instances
- Why Should You Care About Valid XML?
- Data Type Validation--Another Reason for Validity
- How Do You Recognize Data Structure?
- You Can Parse for Validity
- Is Validity All That You Need?
- Summary
- Q&A
This chapter is from the book
This chapter is from the book
This chapter is from the book
Why Should You Care About Valid XML?
You have learned that the use of XML requires strict adherence to syntax and that the parsers and processors used for XML will deal harshly with any violation of the rules. In fact, your document is considered "broken" by an XML parser if it has even the smallest of syntax errors. With such an exacting degree of constraint over XML, why do you need a more complex system of rules?
Validity in XML has to do with the structure of the document. You learned on Day 1 that XML provides a method of placing structured data into a text file. However, structure implies much more than syntax. An XML document, for instance, might be syntactically perfect, but include elements in the wrong order or exclude elements that might be required by a processor to complete an e-commerce transaction or to solve a particular business problem.
By way of example, imagine marking up this book in XML. You would probably have elements such as title, author, publisher, ISBN, date, toc (table of contents), and so on just for the front matter of the book. Within the body of the book, you might include markup for chapter, section, paragraph, emphasis, note, tip, table, and perhaps many more. You can see that the markup could become quite complex and elaborate. For purposes of this discussion, consider only the front matter elements just listed.
Listing 3.1 depicts an XML document that marks up sample front matter for this book.
Listing 3.1 Front Matter Marked Up in XML—MyXMLBook.xml
1: <?xml version="1.0"?> 2: <!-- listing 3.1 - myXMLBook.xml --> 3: 4: <book> 5: <title>Sams Teach Yourself XML in 21 Days, Second Edition</title> 6: <author>Devan Shepherd</author> 7: <publisher>SAMS Publishing</publisher> 8: <isbn>0-672-32093-2</isbn> 9: <date>June 2001</date> 10: <toc> 11: <day number="1">An Overview of the Internet and Markup Languages</day> 12: <day number="2">XML Syntax Explored in Detail</day> 13: <day number="3">Valid XML Instances</day> 14: </toc> 15: </book>
Analysis The book root element (lines 2-13) contains title, author, publisher, isbn, data and toc child elements. All are well-formed with start and end tags shown in matching case. Child elements are properly nested in parent elements with no start and end tags overlapping. The toc element has three-day child elements with text content. The number attributes on the day elements serve to modify day elements in the same way that an adjective modifies a noun in a spoken language.
Not only is the XML document shown in Listing 3.1 well-formed and logical machine-readable code, but it truly is human intelligible. The structure of this document could be represented with a simple tree diagram, like the one shown in Figure 3.1. However, you have no rules in place yet to enforce that structure.
){kind=link}
Figure 3.1 Tree structure for the Sams Teach Yourself XML in 21 Days, Second Edition front matter XML example.
Now examine the document in Listing 3.2. This is also a well-formed XML document. You can prove that by running it through an XML parser. Note that Microsoft Internet Explorer does not report errors and shows a formatted listing of the instance, as shown in Listing 3.2. Remember that this is because Internet Explorer has a built-in parser. Even though the document is well-formed, it no longer bears much resemblance to the structure diagrammed in Figure 3.1 and wouldn't serve to mark up the front matter of this book.
Listing 3.2 Well-Formed But Poorly Structured XML Document—mixed_front_matter.xml
1: <?xml version="1.0"?> 2: <!-- listing 3.2 - mixed_front_matter.xml --> 3: 4: <book> 5: <toc> 6: <day number="1">An Overview of the Internet and Markup Languages</day> 7: <title>Everything You Ever Wanted to Know About XML</title> 8: <title>XML an Why Cats Chase Laser Pointers</title> 9: <date>July 2001</date> 10: <date>June 2001</date> 11: <date>August 1908</date> 12: <author>Devan Shepherd</author> 13: <publisher>Sams Publishing</publisher> 14: <title>Sams Teach Yourself XML in 21 Days, Second Edition</title> 15: <day number="1">An XML Overview of the Internet and Markup Languages</day> 16: <title>Sams Teach Yourself XML in 21 Days, Second Edition</title> 17: <date>June 2001</date> 18: <day number="2">XML Syntax Explored in Detail</day> 19: <isbn>0-672-32093-2</isbn> 20: <day number="3">Valid XML Instances</day> 21: </toc> 22: </book>
The well-formed instance in Listing 3.2 contains multiple dates and titles and an illogical order of elements, and it no longer makes intuitive sense. For instance, the toc element contains dates and other elements that are not typically part of a table of contents. This is not at all what was intended when you set out to markup the front matter for the book.
You need a mechanism to ensure constraint beyond well-formedness. If you are describing this book using XML markup, it makes sense to use a mechanism to enforce some simple constraints. In many cases, the constraints enforce document content rules, business rules or stricture that determines the order of elements, the presence of elements and attributes, and an indication of the number of occurrences expected. For the book's front-matter instance, you might want to establish structural guidelines, such as
There is one and only one book element—the root element—that contains all others.
The book element contains one each of title, author, publisher, isbn, date, and toc elements in that order.
toc should contain as many day elements as needed.
Each of the day elements has a required number attribute indicating which day is being encoded.
These simple content rules can be incorporated into a schema that acts to define the structure of the XML instance. Think of a schema as being like a contract that you enter into with XML to ensure that the desired structure is maintained. As a programmer, you will create a schema to apply to your document that maps well on the business problem you are addressing, or perhaps you might be able to select one from a public repository of schemata. Most schemata, like other parts of the XML family, are extensible by nature. Therefore, if a preexisting schema is only 80% right for your business, you might choose to extend it to make it fit your specific needs. Then, when you share data with others, you can include your extended schema to ensure that they adhere to the structure of your XML data stream.
TIP
It is not always necessary to create a unique schema. There are large repositories of public schemata maintained on the Web for use by particular industries.
There are several forms of schemata that are used in XML programming. During Day 4 you will learn to create, use, and interpret Document Type Definition (DTD) schemata. The DTD approach originated with SGML and has carried over to XML, but suffers from some shortcomings with regard to data type constraints and a syntax that is not the same as XML. On Days 5 and 6, respectively, you will learn about the very powerful XML Data Reduced (XDR) Schema dialect of XML and the XML Schema Definition (XSD) Language recommended by the W3C. All three of these technologies offer a means by which you can enforce the business rules that define the structure of your document. Each approach has advantages and disadvantages, but in time, the disparate methods should be coalesced into a single standard by the W3C and widely supported by industry and software tool developers.
NOTE
Data Type Validation enforces the classification of data values. Data Type Validation provides a means for a computer to make distinctions between such types as integers, percentages, floating point numbers, dates and strings, to name only a few.