To understand the advantages of using XML for encoding data, let's look at a typical example. We will encode product descriptions, so that they can be transferred to another computer. Your first attempt might be a naïve encoding like this:

Toaster
29.95

In contrast, here is an XML encoding of the same data:

<product>
   <description>Toaster</description>
   <price>29.95</price>
</product>

The advantage of the XML version is clear: You can look at the data and understand what they mean. Of course, this is a benefit for the programmer, not for a computer program. A computer program has no understanding of what a "price" is. As a programmer, you still need to write code to extract the price as the content of the price element. Nevertheless, the fact that an XML document is comprehensible by humans is a huge advantage for program development.

A second advantage of the XML version is that it is resilient to change. Suppose the product data change, and an additional data item is introduced, to denote the manufacturer. In the naïve format, the manufacturer might be added after the price, like this:

Toaster
29.95
General Appliances

A program that can process the old format might get confused when reading a sequence of products in the new format. The program would think that the price is followed by the name of the next product. Thus, the program needs to be updated to work with both the old and new data formats. As data get more complex, programming for multiple versions of a data format can be difficult and time-consuming.

When using XML, on the other hand, it is easy to add new elements:

<product>
   <description>Toaster</description>
   <price>29.95</price>
   <manufacturer>General Appliances</manufacturer>
</product>

Now a program that processes the new data can still extract the old information in the same way—as the contents of the description and price elements. The program need not be updated, and it can tolerate different versions of the data format.

If you know HTML, you may have noticed that the XML format of the product data looked somewhat like HTML code. However, there are some differences that we will discuss in this section.

Let's start with the similarities. The XML tag pairs, such as <price> and </price> look just like HTML tag pairs, for example <li> and </li>. Both in XML and in HTML, tags are enclosed in angle brackets < >, and a start-tag is paired with an endtag that starts with a slash / character.

However, web browsers are quite permissive about HTML. For example, you can omit an end-tag </li> and the browser will try to figure out what you mean. In XML, this is not permissible. When writing XML, pay attention to the following rules:

Moreover, there is an important conceptual difference between HTML and XML. HTML has one specific purpose: to describe web documents. In contrast, XML is an extensible syntax that can be used to specify many different kinds of data. For example, the VRML language uses the XML syntax to describe virtual reality scenes. The MathML language uses the XML syntax to describe mathematical formulas. You can use the XML syntax to describe your own data, such as product records or invoices.

Most people who first see XML wonder how an XML document looks inside a browser. However, that is not generally a useful question to ask. Most data that are encoded in XML have nothing to do with browsers. For example, it would probably not be exciting to display an XML document with nothing but product records (such as the ones in the previous section) in a browser. Instead, you will learn in this chapter how to write programs that analyze XML data. XML does not tell you how to display data; it is merely a convenient format for representing data.

In this section, you will see the rules for properly formatted XML. In XML, text and tags are combined into a document. The XML standard recommends that every XML document start with a declaration

<?xml version="1.0"?>

Next, the XML document contains the actual data. The data are contained in a root element. For example,

<?xml version="1.0"?>
<invoice>
   more data
</invoice>

The root element is an example of an XML element. An element has one of two forms:

<elementName> content </elementName>

or

<elementName/>

In the first case, the element has content—elements, text, or a mixture of both. A good example is a paragraph in an HTML document:

<p>Use XML for <strong>robust</strong> data formats.</p>

The p element contains

For XML files that contain documents in the traditional sense of the term, the mixture of text and elements is useful. The XML specification calls this type of content mixed content. But for files that describe data sets—such as our product data—it is better to stick with elements that contain either other elements or text. Content that consists only of elements is called element content.

An element can have attributes. For example, the a element of HTML has an href attribute that specifies the URL of a hyperlink:

<a href="http://java.sun.com"> ... </a>

An attribute has a name (such as href) and a value. In XML, the value must be enclosed in single or double quotes.

An element can have multiple attributes, for example

<img src="hamster.jpeg" width="400" height="300"/>

And, as you have already seen, an element can have both attributes and content.

<a href="http://java.sun.com">Sun's Java web site</a>

Programmers often wonder whether it is better to use attributes or child elements. For example, should a product be described as

<product description="Toaster" price="29.95"/>

or

<product>

<description>Toaster</description>
   <price>29.95</price>
</product>

The former is shorter. However, it violates the spirit of attributes. Attributes are intended to provide information about the element content. For example, the price element might have an attribute currency that helps interpret the element content. The content 29.95 has a different interpretation in the element

<price currency="USD">29.95</price>

than it does in the element

<price currency="EUR">29.95</price>

You have now seen the components of an XML document that are needed to use XML for encoding data. There are other XML constructs for more specialized situations—see http://www.xml.com/axml/axml.html for more information. In the next section, you will see how to use Java to parse XML documents.

<invoice>
    <address>
      <name>ACME Computer Supplies Inc.</name>
      <street>1195 W. Fairfield Rd.</street>
      <city>Sunnyvale</city>
      <state>CA</state>
      <zip>94085</zip>
    </address>
    <items>
       <item>
          <product>
            <description>Ink Jet Refill Kit</description>
            <price>29.95</price>
         </product>
         <quantity>8</quantity>
       </item>
       <item>
          <product>

<description>4-port Mini Hub</description>
            <price>19.95</price>
         </product>
         <quantity>4</quantity>
      </item>
   </items>
</invoice>

<product>
   <description>Ink Jet Refill Kit</description>
   29.95
</product>

<product>
   <description>Ink Jet Refill Kit</description>
   <price>29.95</price>
</product>

<product description="Toaster" price="29.95"/>

<product>
   <description>Toaster</description>
   <price>29.95</price>
</product>

<price currency="USD">29.95</price>

<price>
   <currency>USD</currency>
   <amount>29.95</amount>
</price>

<product description="Toaster" price="USD 29.95"/>

<a href="http://java.sun.com">The Java web page</a>

<p>Use XML for <strong>robust</strong> data formats.</p>

<price>
   <currency>USD</currency>
   29.95
</price>

<price>29.95</price>

<price>
   <currency>USD</currency>
   <amount>29.95</amount>
</price>

Random Fact 23.1 Word Processing and Typesetting Systems

You have almost certainly used a word processor for writing letters or reports. A word processor is a program to write and edit documents made up of text and images. The text can contain characters in various fonts. It can be arranged in paragraphs, tables, and footnotes.

Figure 23.1. A "What You See Is What You Get" Word Processor

Paragraphs can be formatted in various ways, such as ragged right (that is, the left ends of the lines of text are aligned under each other, but the right ends aren't), centered, and fully justified (that is, both the left and right ends of the lines are aligned). What is characteristic of modern word processors is their "what you see is what you get" operation. You enter text and commands, using the keyboard and the mouse. The computer screen instantly shows what the printed document will look like (see Figure 1).

However, there are disadvantages to the "what you see is what you get" (WYSIWYG, pronounced wis-ee-wig) nature of a word processor. You may labor to arrange various related images and tables on the same page. Later, you find that you need to add a couple of paragraphs on the preceding page. Now half of the material moves to the next page, and you have do the arranging all over again. It would have been more useful if you could have told the word processor your intention, namely: "Always keep these images and tables together on the same page". In general, "what you see is what you get" programs are very good in letting you arrange material, but they don't know why you arranged the material in a certain way. Thus, they can't keep the arrangement when your document changes. Some people call these programs "what you see is all you've got".

More fundamentally, "what you see is what you get" programs break down when you need to publish the same material in multiple ways. You may want to format product information as a product parts list and an advertising brochure. Or you may want to publish the information in printed form, on the Web, and in spoken form for telephone retrieval. Now you no longer want to "get" a single result, so it isn't as helpful to see what you get. Instead, it becomes much more important to visualize the structure of the information.

A program for editing structured text needs to capture three pieces of information:

• The text itself

• The structural element (paragraph, bulleted list, heading, and so on) to which each part of the text belongs

• The rules for formatting the structural elements

To make it easy to interchange structured documents between computer systems, the structural information is often encoded in markup tags. For example, XML and HTML use tags that are enclosed in angle brackets, such as the familiar <p>, <ul>, and <h1> tags.

In the 1970s, when publishers began to move away from traditional manual typesetting to computer-based typesetting, the result at first was inferior quality, particularly for mathematical formulas. Arranging the symbols in complex formulas in a way that makes mathematical sense is an art that requires practice and good judgment, and the first typesetting programs were definitely not up to the job. Frustrated by this situation, the famous computer scientist Donald Knuth of Stanford University decided to do something about it and invented a typesetting program that he called T_EX (pronounced "tek" because the "X" is a capital Greek chi). Input to that program consists of text with markup tags that start with a backslash; curly braces {} for grouping; and other special markup symbols, such as _ and ^ to indicate subscript and superscript. For example, to specify a summation, you type

sum_{i=1}^n i^2

The T_EX program typesets the summation as shown in Figure 2. Note that the expression is formatted one way when it occurs inside text and another way when it appears as part of a displayed formula.

A markup tag such as <h1> in HTML or sum in T_EX is mainly beneficial for exchanging documents among different computer systems. Only the most hardened HTML or T_EX authors produce the markup by hand. For HTML in particular, many programs are available that display the structure of an HTML document and allow authors to edit both text and structure in a convenient way that combines the benefits of visual feedback and structure editing.

Figure 23.2. A Formula Typeset in the T_EX Typesetting System

Consider a document of type items. Intuitively, items denotes a sequence of item elements. Each item element contains a product and a quantity. A product contains a description and a price. Each of these elements contains text describing the product's description, price, and quantity. The purpose of a DTD is to formalize this description.

A DTD is a sequence of rules that describes

Let us first turn to child elements. The valid child elements of an element are described by an ELEMENT rule:

<!ELEMENT items (item*)>

This means that an item list must contain a sequence of 0 or more item elements.

As you can see, the rule is delimited by <! ... >, and it contains the name of the element whose children are to be constrained (items), followed by a description of what children are allowed.

Next, let us turn to the definition of an item node:

<!ELEMENT item (product, quantity)>

This means that the children of an item node must be a product node, followed by a quantity node.

The definition for a product is similar:

<!ELEMENT product (description, price)>

Finally, here are the definitions of the three remaining node types:

<!ELEMENT quantity (#PCDATA)>
<!ELEMENT description (#PCDATA)>
<!ELEMENT price (#PCDATA)>

The symbol #PCDATA refers to text, called "parsed character data" in XML terminology. The character data can contain any characters. However, certain characters, such as < and &, have special meaning in XML and need to be replaced if they occur in character data. Table 2 shows the replacements for special characters.

The complete DTD for an item list has six rules, one for each element type:

<!ELEMENT items (item*)>
<!ELEMENT item (product, quantity)>
<!ELEMENT product (description, price)>
<!ELEMENT quantity (#PCDATA)>
<!ELEMENT description (#PCDATA)>
<!ELEMENT price (#PCDATA)>

Let us have a closer look at the descriptions of the allowed children. Table 3 shows the expressions used to describe the children of an element. The EMPTY reserved word is self-explanatory: an element that is declared as EMPTY may not have any children. For example, the HTML DTD defines the img element to be EMPTY—an image has only attributes, specifying the image source, size, and placement, and no children.

More interesting child rules can be formed with the regular expression operations (* + ?, |). (See Table 3 and Figure 8. Also see Productivity Hint 11.1 for more information on regular expressions.) You have already seen the * ("0 or more") and, (sequence) operations. The children of an items element are 0 or more item elements, and the children of an item are a sequence of product and description elements.

Figure 23.8. DTD Regular Expression Operations (E?)

You can also combine these operations to form more complex expressions. For example,

<!ELEMENT section (title, (paragraph | (image, title?))+)

defines an element section whose children are:

is not—there is no starting title, and the title at the end doesn't follow an image.

You already saw the (#PCDATA) rule. It means that the children can consist of any character data. For example, in our product list DTD, the description element can have any character data inside.

You can also allow mixed content—any sequence of character data and specified elements. However, in mixed content, you have no control over the order in which the elements appear. As explained in Quality Tip 23.2 on page 912, you should avoid mixed content for DTDs that describe data sets. This feature is intended for documents that contain both text and markup instructions, such as HTML pages.

Finally, you can allow a node to have children of any type—you should avoid that for DTDs that describe data sets.

You now know how to specify what children a node may have. A DTD also gives you control over the allowed attributes of an element. An attribute description looks like this:

<!ATTLIST Element Attribute Type Default>

The most useful attribute type descriptions are listed in Table 4. The CDATA type describes any sequence of character data. As with #PCDATA, certain characters, such as < and &, need to be encoded (as <, & and so on). There is no practical difference between the CDATA and #PCDATA types. Simply use CDATA in attribute declarations and #PCDATA in element declarations.

Rather than allowing arbitrary attribute values, you can specify a finite number of choices. For example, you may want to restrict a currency attribute to U.S. dollar, euro, and Japanese yen. Then use the following declaration:

<!ATTLIST price currency (USD | EUR | JPY) #REQUIRED>

You can use letters, numbers, and the hyphen (-) and underscore (_) characters for the attribute values.

There are other type descriptions that are less common in practice. You can find them in the XML reference (http://www.xml.com/axml/axml.html).

The attribute type description is followed by a "default" declaration. The reserved words that can appear in a "default" declaration are listed in Table 5.

For example, this attribute declaration describes that each price element must have a currency attribute whose value is any character data:

<!ATTLIST price currency CDATA #REQUIRED>

To fulfill this declaration, each price element must have a currency attribute, such as <price currency="USD">. A price without a currency would not be valid.

For an optional attribute, you use the #IMPLIED reserved word instead.

<!ATTLIST price currency CDATA #IMPLIED>

That means that you can supply a currency attribute in a price element, or you can omit it. If you omit it, then the application that processes the XML data implicitly assumes some default currency.

A better choice would be to supply the default value explicitly:

<!ATTLIST price currency CDATA "USD">

That means that the currency attribute is understood to mean USD if the attribute is not specified. An XML parser will then report the value of currency as USD if the attribute was not specified.

Finally, you can state that an attribute can only be identical to a particular value. For example, the rule

<!ATTLIST price currency CDATA #FIXED "USD">

means that a price element must either not have a currency attribute at all (in which case the XML parser will report its value as USD), or specify the currency attribute as USD. Naturally, this kind of rule is not very common.

You have now seen the most common constructs for DTDs. Using these constructs, you can define your own DTDs for XML documents that describe data sets. In the next section, you will see how to specify which DTD an XML document should use, and how to have the XML parser check that a document conforms to its DTD.

When you reference a DTD with an XML document, you can instruct the parser to check that the document follows the rules of the DTD. That way, the parser can check errors in the document.

In the preceding section you saw how to develop a DTD for a class of XML documents. The DTD specifies the permitted elements and attributes in the document. An XML document has two ways of referencing a DTD:

A DTD is introduced with the DOCTYPE declaration. If the document contains its DTD, then the declaration looks like this:

<!DOCTYPE rootElement [ rules ]>

For example, an item list can include its DTD like this:

<?xml version="1.0"?>
<!DOCTYPE items [

<!ELEMENT items (item*)>
<!ELEMENT item (product, quantity)>
<!ELEMENT product (description, price)>
<!ELEMENT quantity (#PCDATA)>
<!ELEMENT description (#PCDATA)>
<!ELEMENT price (#PCDATA)>

]>
<items>
    <item>
       <product>
         <description>Ink Jet Refill Kit</description>
         <price>29.95</price>
       </product>
       <quantity>8</quantity>
    </item>
    <item>
       <product>
         <description>4-port Mini Hub</description>
         <price>19.95</price>
       </product>
       <quantity>4</quantity>
    </item>
</items>

However, if the DTD is more complex, then it is better to store it outside the XML document. In that case, you use the SYSTEM reserved word inside the DOCTYPE declaration to indicate that the system that hosts the XML processor must locate the DTD. The SYSTEM reserved word is followed by the location of the DTD. For example, a DOCTYPE declaration might point to a local file

<!DOCTYPE items SYSTEM "items.dtd">

Alternatively, the resource might be an URL anywhere on the Web:

<!DOCTYPE items SYSTEM "http://www.mycompany.com/dtds/items.dtd">

For commonly used DTDs, the DOCTYPE declaration can contain a PUBLIC reserved word. For example,

<!DOCTYPE faces-config PUBLIC
   "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN"
   "http://java.sun.com/dtd/web-facesconfig_1_0.dtd">

A program parsing the DTD can look at the public identifier. If it is a familiar identifier, then it need not spend time retrieving the DTD from the URL.

When you include a DTD with an XML document, then you can tell the parser to validate the document. That means that the parser will check that all child elements and attributes of an element conform to the ELEMENT and ATTLIST rules in the DTD. If a document is invalid, then the parser reports an error. To turn on validation, you use the setValidating method of the DocumentBuilderFactory class before calling the newDocumentBuilder method:

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setValidating(true);
DocumentBuilder builder = factory.newDocumentBuilder();
Document doc = builder.parse(...);

Validation can simplify your code for processing XML documents. For example, if the DTD specifies that the child elements of each item element are product and quantity elements in that order, then you can rely on that fact and don't need to put tedious checks in your code.

If the parser has access to the DTD, it can make another useful improvement. By default, the parser converts all spaces in the input document to text, even if the spaces are only used to logically line up elements. As a result, the document contains text nodes that are wasteful and can be confusing when you analyze the document tree.

To make the parser ignore white space, call the setIgnoringElementContentWhitespace method of the DocumentBuilderFactory class.

factory.setValidating(true);
factory.setIgnoringElementContentWhitespace(true);

Finally, if the parser has access to the DTD, it can fill in default values for attributes. For example, suppose a DTD defines a currency attribute for a price element:

<!ATTLIST price currency CDATA "USD">

If a document contains a price element without a currency attribute, then the parser can supply the default:

String attributeValue = priceElement.getAttribute("currency");
   // Gets "USD" if no currency specified

This concludes our discussion of XML. You now know enough XML to put it to work for describing data formats. Whenever you are tempted to use a "quick and dirty" file format, you should consider using XML instead. By using XML for data interchange, your programs become more professional, robust, and flexible. This chapter covers the most important aspects of XML for everyday programming. For more advanced features that can be useful in specialized situations, please see http://www.xml.com/axml/axml.html. Furthermore, XML technology is still undergoing rapid change at the time of this writing. Therefore, it is a good idea to check out the latest developments. Good web sites are http://www.w3c.org/xml, the W3C XML web site, and http://java.sun.com/xml, the Sun Microsystems XML web site.

<!ELEMENT elementName (#PCDATA)>

<!ELEMENT name (#PCDATA)>
<!ELEMENT street (#PCDATA)>
<!ELEMENT city (#PCDATA)>
<!ELEMENT state (#PCDATA)>
<!ELEMENT zip (#PCDATA)>
<!ELEMENT quantity (#PCDATA)>
<!ELEMENT description (#PCDATA)>

invoice
•  address
•  items
address
•  name
•  street
•  city
•  state
•  zip
items
•  item
item
•  product
•  quantity
product
•  description
•  price

<!ELEMENT elementName child1 count1, child2 count2, ...>

<!ELEMENT items (item*)>

<!ELEMENT invoice (address, items)>
<!ELEMENT address (name, street, city, state, zip)>
<!ELEMENT item (product, quantity)>
<!ELEMENT product (descripton, price)>

<xsd:element name="quantity" type="xsd:integer"/>

<xsd:complexType name="Address">
   <xsd:sequence>
      <xsd:element name="name" type="xsd:string"/>
      <xsd:element name="street" type="xsd:string"/>
      <xsd:element name="city" type="xsd:string"/>
      <xsd:element name="state" type="xsd:string"/>
      <xsd:element name="zip" type="xsd:string"/>
   </xsd:sequence>
</xsd:complexType>

<xsd:element name="shipto" type="Address"/>
<xsd:element name="billto" type="Address"/>

element quantity { xsd:integer }

<xsd:element name="city" type="xsd:string"/>

<xsd:schema xmlns:xsd="http://www.w3.org/2000/08/XMLSchema">

http://www.w3c.org/xml.

Describe the purpose of XML and the structure of an XML document.

Use a parser and the XPath language to process an XML document.

Write Java programs that create XML documents.

Explain the use of DTDs for validating XML documents.

javax.xml.parsers.DocumentBuilder          org.w3c.dom.DOMConfiguration
     newDocument                              setParameter
     parse                                 org.w3c.dom.DOMImplementation
javax.xml.parsers.DocumentBuilderFactory      getFeature
   newDocumentBuilder                      org.w3c.dom.Element
   newInstance                              getAttribute
   setIgnoringElementContentWhitespace      setAttribute
   setValidating                           org.w3c.dom.ls.DOMImplementationLS
javax.xml.xpath.XPath                         createLSSerializer
   evaluate                                org.w3c.dom.ls.LSSerializer
javax.xml.xpath.XPathExpressionException      getDomConfig
javax.xml.xpath.XPathFactory                  writeToString
   newInstance
   newXPath
org.w3c.dom.Document
   createElement
   createTextNode
   getImplementation

R23.1 Give some examples to show the differences between XML and HTML.

R23.2 Design an XML document that describes a bank account.

R23.3 Draw a tree view for the XML document you created in Exercise R23.2.

R23.4 Write the XML document that corresponds to the parse tree in Figure 5.

R23.5 Write the XML document that corresponds to the parse tree in Figure 6.

R23.6 Make an XML document describing a book, with child elements for the author name, the title, and the publication year.

R23.7 Add a description of the book's language to the document of the preceding exercise. Should you use an element or an attribute?

R23.8 What is mixed content? What problems does it cause?

R23.9 Design an XML document that describes a purse containing three quarters, a dime, and two nickels.

R23.10 Explain why a paint program, such as Microsoft Paint, is a WYSIWYG program that is also "what you see is all you've got".

R23.11 Consider the XML file

<purse>
    <coin>
      <value>0.5</value>
      <name lang="en">half dollar</name>
   </coin>
   <coin>

<value>0.25</value>
      <name lang="en">quarter</name>
   </coin>
</purse>

What are the values of the following XPath expressions?

R23.12 With the XML file of Exercise R23.11, give XPath expressions that yield:

R23.13 Design a DTD that describes a bank with bank accounts.

R23.14 Design a DTD that describes a library patron who has checked out a set of books. Each book has an ID number, an author, and a title. The patron has a name and telephone number.

R23.15 Write the DTD file for the following XML document

<?xml version="1.0"?>
<productlist>
    <product>
      <name>Comtrade Tornado</name>
      <price currency="USD">2495</price>
      <score>60</score>
   </product>
   <product>
      <name>AMAX Powerstation 75</name>
      <price>2999</price>
      <score>62</score>
   </product>
</productlist>

R23.16 Design a DTD for invoices, as described in How To 23.3 on page 936.

R23.17 Design a DTD for simple English sentences, as described in Random Fact 23.2 on page 920.

R23.18 Design a DTD for arithmetic expressions, as described in Random Fact 23.2 on page 920.

P23.1 Write a program that can read XML files, such as

<purse>
   <coin>
      <value>0.5</value>
      <name>half dollar</name>
   </coin>
   ...
</purse>

Your program should construct a Purse object and print the total value of the coins in the purse.

P23.2 Building on Exercise P23.1, make the program read an XML file as described in that exercise. Then print an XML file of the form

<purse>
    <coins>
       <coin>
         <value>0.5</value>
         <name>half dollar</name>
       </coin>
       <quantity>3</quantity>
    </coins>
    <coins>
       <coin>
         <value>0.25</value>
         <name>quarter</name>
       </coin>
       <quantity>2</quantity>
    </coins>
</purse>

P23.3 Repeat Exercise P23.1, using a DTD for validation.

P23.4 Write a program that can read XML files, such as

<bank>
   <account>
      <number>3</number>
      <balance>1295.32</balance>
   </account>
   ...
</bank>

Your program should construct a Bank object and print the total value of the balances in the accounts.

P23.5 Repeat Exercise P23.4, using a DTD for validation.

P23.6 Enhance Exercise P23.4 as follows: First read the XML file in, then add 10 percent interest to all accounts, and write an XML file that contains the increased account balances.

P23.7 Write a DTD file that describes documents that contain information about countries: name of the country, its population, and its area. Create an XML file that has five different countries. The DTD and XML should be in different files. Write a program that uses the XML file you wrote and prints:

P23.8 Write a parser to parse invoices using the invoice structure described in How To 23.1 on page 909. The parser should parse the XML file into an Invoice object and print out the invoice in the format used in Chapter 12.

P23.9 Modify Exercise P23.8 to support separate shipping and billing addresses. Supply a modified DTD with your solution.

P23.10 Write a document builder that turns an invoice object, as defined in Chapter 12, into an XML file of the format described in How To 23.1 on page 909.

P23.11 Modify Exercise P23.10 to support separate shipping and billing addresses.

P23.12 Write a program that can read an XML document of the form

<rectangle>
   <x>5</x>
   <y>10</y>
   <width>20</width>
   <height>30</height>
</rectangle>

and draw the shape in a window.

P23.13 Write a program that can read an XML document of the form

<ellipse>
   <x>5</x>
   <y>10</y>
   <width>20</width>
   <height>30</height>
</ellipse>

and draw the shape in a window.

P23.14 Write a program that can read an XML document of the form

<rectangularshape shape="ellipse">
   <x>5</x>
   <y>10</y>
   <width>20</width>
   <height>30</height>
</rectangularshape>

Support shape attributes "rectangle", "roundrectangle", and "ellipse".

Draw the shape in a window.

P23.15 Write a program that can read an XML document of the form

<polygon>
   <point>
      <x>5</x>
      <y>10</y>
   </point>
   ...

</polygon>

and draw the shape in a window.

P23.16 Write a program that can read an XML document of the form

<drawing>
    <rectangle>
      <x>5</x>
      <y>10</y>
      <width>20</width>
      <height>30</height>
    </rectangle>
   <line>
      <x1>5</x1>
      <y1>10</y1>
      <x2>25</x2>
      <y2>40</y2>
   </line>
   <message>
      <text>Hello, World!</text>
      <x>20</x>
      <y>30</y>
   </message>
</drawing>

and show the drawing in a window.

P23.17 Repeat Exercise P23.16, using a DTD for validation.

Project 23.1 Following Exercise P12.7, design an XML format for the appointments in an appointment calendar. Write a program that first reads in a file with appointments, then another file of the format

<commands>
    <add>
       <appointment>
          ...
       </appointment>
   </add>
    ...
   <remove>
       <appointment>
          ...
       </appointment>
   </remove>
</commands>

Your program should process the commands and then produce an XML file that consists of the updated appointments.

Project 23.2 Write a program to simulate an airline seat reservation system, using XML documents. Reference Exercise P12.8 for the airplane seat information. The program reads a seating chart, in an XML format of your choice, and a command file, in an XML format of your choice, similar to the command file of the preceding exercise. Then the program processes the commands and produces an updated seating chart.