|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 2 of 6
A valuable XML concept is the ability to define your own XML vocabulary. An XML vocabulary is an industry-specific XML information model or document type that you define for XML data sharing. In other words, you define constraints that specify what a particular group of XML documents should always look like. Document creators, programmers, graphic designers, and database specialists use a constrained document type as the basis for creating compatible application pieces. This parallel collaboration around a document type is easy because everyone knows ahead of time what the constrained XML documents will look like.
You can define an XML vocabulary by constraining XML in two different ways. The original method from the XML specification uses a DTD. The new and improved approach uses the recently formalized W3C (World Wide Web Consortium) Recommendation, XML Schema.
For example, in this article, I will define an XML vocabulary for describing socks. I'm a sock expert, since I wear socks almost every day, and so I know exactly what information is needed to fully describe a sock collection. Every sock in my definition has the following descriptive properties: number, name, image, color, price, and smell.
Thus, I can create the following DTD to formally describe a sock collection:
Listing 1. socks.dtd
<!ELEMENT socks ( sock* ) > <!ELEMENT sock (name, image, color, price, smell) > <!ATTLIST sock number CDATA #REQUIRED > <!ELEMENT name (#PCDATA) > <!ELEMENT image (#PCDATA) > <!ELEMENT color EMPTY > <!ELEMENT price (#PCDATA) > <!ELEMENT smell (#PCDATA) > <!ATTLIST color value (white|black) #REQUIRED >
Listing 1 says simply that an XML document conforming to my socks.dtd constraints must have zero or more socks. Each sock has exactly one name, image, color, price, and smell -- in that order.
The color can only have the values white or black. Each sock has an attribute called number. Do you see why we say DTDs constrain conformant XML documents? (For more on DTDs, see Resources.)
An XML document that is valid against this DTD -- that is, one that follows the constraints correctly -- might look like this:
Listing 2. socks.xml
<?xml version="1.0"?>
<!DOCTYPE socks SYSTEM "socks.dtd">
<socks>
<sock number="1">
<name>black socks</name>
<image>blacksocks.jpg</image>
<color value="black"/>
<price>9.99</price>
<smell>7</smell>
</sock>
<sock number="2">
<name>white socks</name>
<image>whitesocks.jpg</image>
<color value="white"/>
<price>5.34</price>
<smell>2</smell>
</sock>
<sock number="3">
<name>old white socks</name>
<image>oldwhitesocks.jpg</image>
<color value="white"/>
<price>2.20</price>
<smell>9</smell>
</sock>
</socks>
DTDs have garnered some complaints, especially from programmers. The problem: DTDs really constrain only the document's structure, not the data it contains. All the elements and attributes are strings, and you can't specify allowed value ranges. The best data constraining you can do with a DTD is to require that attributes be strings from a constant list. Furthermore, DTDs are not in XML format themselves, so they don't seem to fit in too well.