In our previous example, we explained that we had defined an element named CONTACT, that was allowed to include a single ELEMENT NAME, that in turn contained parsed character data.

    <?xml version = "1.0" encoding="UTF-8" standalone = "yes"?>
    <!DOCTYPE CONTACTS [
	<!ELEMENT CONTACTS ANY>
	<!ELEMENT CONTACT (NAME)>
	<!ELEMENT NAME (#PCDATA)>
	]>

    <CONTACTS>

    <CONTACT>
        <NAME>Roger Kaplan</NAME>
    </CONTACT>

    </CONTACTS>

Well, truthfully, we were "mostly" right in our explanation of the DTD. More correctly, the example defined an element named CONTACT that was REQUIRED to have a child NAME.

Remember that DTDs give you quite a bit of flexibility to specify exactly what elements can contain. Using regular expression pattern matching, DTDs allow you to specify very complex logical relationships between elements and their children

For example, you could specify such things as: an element may contain a child, one or more children, zero or more children, or at least one child, You could also specify more complex relationships such as element X is valid if it contains one or more children named Y OR one Child named Z.

Element definitions are described by their Element Content Models (ECM)....that is, all the stuff in the parentheses. :)

Thus, as we saw, the ECM of the CONTACT element specified the child element NAME:

	<!ELEMENT CONTACT (NAME)>

The contents of the ECM are governed by a set of regular expression rules very similar to those used in UNIX. But if you are not familiar with UNIX, don't worry, it is pretty easy. The idea of regular expressions is that certain characters are used to communicate matching logic. Take a look at the possible meta characters....

Of course, these are best seen by example. Let's consider the simplest case of defining an order of child elements.