This chapter is from the book
This chapter is from the book
This chapter is from the book
A Simple Airline Ticket Itinerary DTD
In this section, let's take a look at building a simple DTD, so that we have a solid understanding of the DTD's structure and the process of converting the DTD into an XML Schema. Because we have not dealt extensively with the mechanics of Schema yet, we will keep this example very straightforward and simple. But it's still a good idea to cover this kind of information now, so that you have these types of applications in mind going forward, as we learn about the finer details of XML Schema.
For this example, we are going to build a DTD that could be used to describe an airline ticket itinerary. This would include information about the flight and airline, including departure times, arrival times, seating information, flight duration, and so on. Of course, if we were actually building an application for the travel industry, this type of schema could be very complex, but for our application, we will limit the data to the basics, so it should be easy to follow.
Design Goals for a Ticket Itinerary XML Document
What kind of information needs to be contained in our ticket itinerary document? Well, let's start off by making our root element <itinerary>, and then creating a child element called <ticket> that contains the actual ticket information.
Within that ticket, we will need information about the airline, the flight number, departing information, arrival information, and some details about the flight.
So, let's create some elements for that information, say <airline>, <flight>, <departing>, and <arriving>, to deal with the details. It's also pretty common to have information about the seating arrangements, and some details like the mileage and duration of the flight.
Of course, there are more details that we need in the document. For example, we need the date and time of the departure and arrival. It would probably also be a good idea to include information about the gate and airport of the flights, since many areas have more than one airport.
We could also include some information about the seating arrangements for the flight, as that can also be known in advance. For this type of information, we'll use attributes. Is it better to use attributes for this information? Maybe, maybe not. There are no hard, fast rules for designing this kind of information. However, for detail-oriented information like this which describes an element (like an adjective describes a noun), attributes are certainly appropriate.
So, let's take a look at the elements we have for our document so far. The elements (and the attributes) are summarized in Table 3.2.
Table 3.2 An Overview of the Ticket Itinerary Elements
|
Element |
Attributes |
Description |
|
itinerary |
None |
The document root element. Parent to the <ticket> child element. |
|
ticket |
None |
The ticket serves as the parent element for all of the children containing information about the airline ticket. |
|
airline |
None |
The name of the airline. |
|
flight |
None |
The flight number for the ticket. |
|
departing |
date, time, airport, gate |
An element for the departing information about the flight, with attributes for the details. |
|
arriving |
date, time, airport, gate |
An element for the arriving information about the flight, with attributes for the details. |
|
miles |
None |
The total mileage of the flight. |
|
seating |
class, seat |
The seating assignment for the flight. |
|
duration |
None |
The duration of the flight in hours and minutes. |
Those elements will make up the bulk of our document. And the remaining information will be stored in attributes, as outlined in Table 3.3.
Table 3.3 An Overview of the Attributes for the Ticket Itinerary Elements
|
Attribute |
Description |
|
date |
An attribute describing the day, month, and year. |
|
time |
The time of the flight. |
|
airport |
The three-letter airport code. |
|
gate |
The boarding gate of the flight. |
|
class |
The seating class. |
|
seat |
The seat number assignment. |
Now that you have an outline, build an XML document which uses the elements and attributes outlined in Tables 3.2 and 3.3. It would look something like Listing 3.1
Listing 3.1 The XML Document for an Airline Ticket Itinerary
<?xml version="1.0" encoding="UTF-8" ?> <itinerary> <ticket> <airline>American</airline> <flight>4090</flight> <departing date="10-Apr-01" time="6:45AM" airport="IND" gate="A20" /> <arriving date="10-Apr-01" time="7:52AM" airport="ORD" gate="B64" /> <miles>168</miles> <seating class="Coach" seat="D3"/> <duration>1hr 7mn</duration> </ticket> </itinerary>
Describing the Ticket Itinerary XML Document in a DTD
Okay, now that we have an outline of the elements and attributes for our document, and we have an idea of what we want our final document to look like, let's take a look at the DTD.
The first thing we need to do is define the root <itinerary> element, which will contain the <ticket> element. We can do that with a simple element declaration:
<!ELEMENT itinerary (ticket*)>
The * following the ticket element simply indicates that the itinerary may contain more than one ticket. Next, we need to declare the ticket element, and specify the content model:
<!ELEMENT ticket (airline, flight, departing, arriving, miles, seating, duration)>
Here, the ticket element contains a number of elements which will hold the data about the ticket. Note that none of the *, +, or ? symbols were used, which indicates that each of these elements will be used exactly once per ticket element.
Now we can move on to declaring our other elements. These elements are very straightforward. Since they will all simply contain text, we can use a very simple element declaration:
<!ELEMENT airline (#PCDATA)>
For the elements such as departing which will not have any content, but instead use attributes, we could use the EMPTY keyword in place of #PCDATA. However, in order to keep this DTD (and the later conversion to a Schema) as simple as possible, we'll just leave them as #PCDATA. That gives us the following as the rest of our element declarations:
<!ELEMENT flight (#PCDATA)> <!ELEMENT departing (#PCDATA)> <!ELEMENT arriving (#PCDATA)> <!ELEMENT seating (#PCDATA)> <!ELEMENT miles (#PCDATA)> <!ELEMENT duration (#PCDATA)>
We now have all of our elements defined. Next, we need to declare our attributes. This is done with the ATTLIST declaration:
<!ATTLIST departing date CDATA #REQUIRED time CDATA #REQUIRED airport CDATA #REQUIRED gate CDATA #IMPLIED>
The ATTLIST declaration allows us to specify the element we are declaring attributes for, and then list the attributes, followed by the value type (CDATA) and then by a keyword which indicates whether an attribute is #REQUIRED or #IMPLIED. Of course, required attributes must be used, while implied attributes are optional. Our ATTLIST declaration for the arriving element is the same as our declaration for the departing element, since they have the same attributes:
<!ATTLIST arriving date CDATA #REQUIRED time CDATA #REQUIRED airport CDATA #REQUIRED gate CDATA #IMPLIED>
Finally, we declare the attributes for our seating element:
<!ATTLIST seating class CDATA #REQUIRED seat CDATA #IMPLIED>
Now all of the pieces for our DTD are done, and if we pull them all together, we get the final code for the Airline Ticket Itinerary as shown in Listing 3.2.
Listing 3.2 The DTD Describing an Airline Ticket Itinerary
<!-- A Simple Airline Ticket Itinerary DTD --> <!ELEMENT itinerary (ticket*)> <!ELEMENT ticket (airline, flight, departing, arriving, miles, seating, duration)> <!ELEMENT airline (#PCDATA)> <!ELEMENT flight (#PCDATA)> <!ELEMENT departing (#PCDATA)> <!ATTLIST departing
Listing 3.2 Continued
date CDATA #REQUIRED time CDATA #REQUIRED airport CDATA #REQUIRED gate CDATA #IMPLIED> <!ELEMENT arriving (#PCDATA)> <!ATTLIST arriving date CDATA #REQUIRED time CDATA #REQUIRED airport CDATA #REQUIRED gate CDATA #IMPLIED> <!ELEMENT miles (#PCDATA)> <!ELEMENT seating (#PCDATA)> <!ATTLIST seating class CDATA #REQUIRED seat CDATA #IMPLIED> <!ELEMENT duration (#PCDATA)>