XML creation: Part 4

In this guide, I'll be creating an XML file to store the Playstation games I own, and ultimately make the XML file 'pretty' for Web browsers. I've done this in the past, with my vehicle gas XML document.

In part four, I'll be adding a DTD so our XML document validates.

Last time ...

Up until now we've decided what we want to store, and how we want to store it, in an XML file.

Then, in part three, we actually added some of the data we want to store.

While it displays, and is basically formatted correctly, the XML file won't validate. Time to fix this.


In order to make the file validate we can do a number of things. For now, we'll create a DTD file - a Document Type Definitions file - which is probably the easiest to make.

We'll need to create the DTD, as well as make a couple of modifications to the XML file.

XML file modifications

The modifications we'll be making to the XML file are pretty simple.

First, we'll state that the XML file requires another file. To do this we need merely change the first line from:

<?xml version="1.0"?>


<?xml version="1.0" standalone="no"?>

The addition is now in bold.

Next, we need to add a second line, as follows:

<!DOCTYPE games SYSTEM "http://strivinglife.com/files/xml_creation/part4.dtd">

Here I've actually already determined where I'll be storing the file.

You'll want to use a better filename than what I've used, when you really create your DTD.

You can view the source of the modified XML file to see this.

The Document Type Definitions (DTD)

Here it is. We'll go over the details after the code.

<!ELEMENT games (game*)>

<!ELEMENT game (title, system*, purchase*, sell*, own, notes)>

<!ELEMENT title (#PCDATA)>
<!ELEMENT system (console, version)>
<!ELEMENT purchase (date, price, place)>
<!ELEMENT sell (date, price)>
<!ELEMENT notes (#PCDATA)>

<!ELEMENT console (#PCDATA)>
<!ELEMENT version (#PCDATA)>

<!ELEMENT price (#PCDATA)>

<!ELEMENT place (#PCDATA)> 

First, we have <!ELEMENT games (game*)> .  We'll use ELEMENT for each element that is used within the XML document, so you'll notice one for each.

In this case, we're stating that the games element has the sub-element, or child, of game, which can occur zero or more times (note the asterisk). Since the other elements do not have an asterisk, that means that that element can only occur once. Other options include:

  • + : Minimum of one occurrence
  • ? : Zero or one occurrence

Further down, we have <!ATTLIST game id CDATA #REQUIRED> . In this case, we see that the game element has an id attribute, and consists of character data; CDATA signifies character data. This attribute is also required.

Following that we have <!ELEMENT title (#PCDATA)> . Instead of a listing of elements, we instead have #PCDATA, which means this element contains 'parsed' character data. Whatever parses, or reads, this XML data will also examine this element, in this case the title element, for entities and markup.

Once we save this file to the place denoted in the XML file, we're ready to run it past validation.

Validome has a great validator, which handles a number of different formats. You can view the results of validation by entering your own URL, or using mine.

You'll notice that both the XML and DTD will show under validated files. If both don't appear, then the DTD isn't 'linked to' from the XML file, or you're not validating the XML file.

Another way to work through the DTD

If you'd like, you can also work through the DTD by emptying the DTD and validating the XML file. Then, you can add lines as needed, to clear up errors.

Next time ...

In part five, we'll be using a CSS file to style our XML file.

Then, in part six, we'll be using an XSLT file to style our XML file, instead.

Each has it's benefits, and since they're both different, we'll cover them separate for ease.