Validating the Document with the Document Type Definition (DTD)

 <  Day Day Up  >  

In this example, we will be sending an XML document from Beta Company to Alpha Company. The XML document will represent a transaction that contains the name of the company, the address of the company, and certain product information. Note that the information is nested. This is to say that the overall document, which can be described as an object, is that of a supplier. Nested within the supplier identification are the company name , the company address and the product information. Note that there is also information nested within the address and the product identifications. Before going any further, let's define a DTD that will drive all the transactions for this example. The DTD is presented in Listing 12.1.

Listing 12.1 The Data Definition Document for Validation
 <!-- DTD for supplier document --> <!ELEMENT supplier ( name, address)> <!ELEMENT name ( companyname)> <!ELEMENT companyname ( #PCDATA)> <!ELEMENT address ( street+, city, state, zip)> <!ELEMENT street ( #PCDATA)> <!ELEMENT city ( #PCDATA)> <!ELEMENT state ( #PCDATA)> <!ELEMENT zip ( #PCDATA)> 

The DTD defines how the XML document is built. It is composed of tags that look very similar to HTML tags. The first line is an XML comment.

 
 <!-- DTD for supplier document --> 

XML comments provide the same function as any other programming language comments ”to document the code. As with any comments, use XML comments to make the document easier to read and understand. Do not put too many comments in it, or the document will be more difficult to read. This document contains only one comment.

The remaining lines actually define the structure of the XML document. Let's look at the first line:

 
 <!ELEMENT supplier ( name, address, product)> 

This tag defines an element called supplier . As specified in the DTD above, a supplier contains a name , an address , and a product . Thus, when an XML parser actually parses an XML document, the document must be a supplier , which contains a name , an address , and a product .

Taking things to the next level, we see that the element name is made up of an element called <companyname> .

 
 <!ELEMENT name ( companyname)> 

The <companyname> element is then defined to be a data element designated by #PCDATA .

 
 <!ELEMENT companyname ( #PCDATA)> 

This tag terminates the hierarchy of the element tree. This DTD is named supplier.dtd . You can use any text editor to create the DTD. There are also many integrated tools that can be used to create this document as well. Figure 12.3 uses Notepad to show how a DTD for this application might look.

Figure 12.3. Creating the DTD in Notepad.

graphics/12fig03.jpg

Document Validity

An XML document that specifies a DTD is either valid or invalid based on the DTD. If a document does not specify a DTD, the XML document is not judged either valid or invalid. An XML document can specify a DTD internally or externally. Because external DTDs provide a very powerful mechanism, we will use an external DTD here.


PCDATA

PCDATA stands for parse character data , and is simply standard character information parsed from the text file. Any numbers , such as integers, will need to be converted by the parser.


 <  Day Day Up  >  


Object-Oriented Thought Process
Object-Oriented Thought Process, The (3rd Edition)
ISBN: 0672330164
EAN: 2147483647
Year: 2003
Pages: 164
Authors: Matt Weisfeld

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net