|
|
|
XML Pocket Consultant
|
|
|
Author
|
|
William R. Stanek
|
|
|
Pages
|
416
|
|
Disk
|
N/A
|
|
Level
|
All Levels
|
|
Published
|
01/16/2002
|
|
ISBN
|
9780735611832
|
|
Price
|
$29.99
To see this book's discounted price, select a reseller below.
|
|
|
|
|
|
|
|
|
Chapter 3: Creating DTDs continued
Understanding DTDs
DTDs have a formal—fairly rigid—syntax that precisely describes the elements and entities that may appear in a document, as well as the contents and attributes for acceptable elements. In a DTD you could specify that a purchase order must have one and only one order number but can have one or more requested products. You could go on to specify that each purchase order must have one order date and one customer identifier but no more. These details in the DTD would allow programs to determine if purchase orders are valid.
Validity is an important concept when DTDs are used. If a document is valid, it can be said that it conforms to its DTD. If a document is invalid, the document doesn't conform to its DTD. However, keep in mind that validation is an optional step in processing XML. Programs that use validating parsers can compare documents to their DTD and list places where the document differs from the DTD specification. The programs can then determine actions to take regarding noncompliance with the DTD. Some programs may mark the document as invalid and stop processing it. Other programs may try to correct problems in the document and reprocess it.
Although DTDs can help you specify constraints for documents, DTDs don't specify every nuance of a document's format. Among other things, a DTD doesn't control allowed values, the denotation of elements (explicit meaning), the connotation of elements (figurative meaning), or the character data that can be associated with elements. This allows for flexibility in the document structure so that you can create many types of documents using the same set of rules.
All valid documents include a reference to the DTD to which they conform. DTDs aren't mandatory, however. When a document lacks a DTD, the XML processor can't verify that the data format is appropriate, but it can still attempt to interpret the data.
DTDs can be specified in several different ways. An internal DTD is one that is defined within a document. An external DTD is one that is defined in a separate document and is imported into the document. Both types of DTDs have their advantages and disadvantages.
Internal DTDs are convenient when you want to apply constraints to an individual document and then easily distribute the document along with its DTD. They're also convenient when you're developing a complex DTD and want to test an example document against the DTD. Putting the DTD and the related markup in the same file makes it easy to modify the DTD and the example document as often as necessary during testing.
With an external DTD, you place a reference to a DTD in a file rather than the DTD itself. This makes it easy to apply the DTD to multiple documents. Because the DTD is referenced rather than included, you can make changes to the DTD later and you don't need to edit the DTD definition in each and every document to which it's applied. Two types of external DTDs are used:
- Public Public DTDs are DTDs that have been standardized and provide a publicly available set of rules for writing specific types of XML documents, such as those used by the airlines or insurance industries.
- Nonpublic Nonpublic DTDs are DTDs created by private organizations or individuals. Generally speaking, these DTDs aren't publicly available (or haven't become a public standard).
When you use an external DTD, you should set the standalone attribute of the XML declaration to no, such as:
<?xml version="1.0" encoding="US-ASCII" standalone="no"?>
Previous
| Table of Contents
|
Next
Last Updated: January 17, 2002
| 
