Obviously, you are able to allow more than one of each element:

  <!ELEMENT jokebook (joke+)>
			

which means that a jokebook may contain one or more jokes:

  <jokebook>
    <joke></joke>
    ... more <joke> elements ...
  </jokebook>

Similarly, elements may be marked as optional (?) or as appearing none or more times (*). You can also use the keyword ANY to allow any defined tag or text at that point (though this is rarely used).

Alternatives can also be marked:

  <!ELEMENT joke (simplejoke | knockknockjoke | 
      doctordoctorjoke | limerick)>
			

so that a joke may contain one (and only one) of several types. A valid pattern might be:

  <joke><limerick></limerick></joke>

We can also allow multiple choices from a list in any order, by saying:

  <!ELEMENT myjokes (simplejoke | knockknockjoke | 
      doctordoctorjoke | limerick)+ >
			

which creates an unordered list of one or more jokes of the listed type, perhaps like this:

  <myjokes>
    <knockknockjoke></knockknockjoke>
    <limerick></limerick>
    <limerick></limerick>
    <simplejoke></simplejoke>
    <limerick></limerick>
  </myjokes>

Remember that, for these to validate, each of these individual element types will also need to be defined, even if only as #PCDATA.

Controlling and limiting multiple items is not always easy with DTDs, especially where there's a need to have a finite maximum or minimum that isn't zero or one. There are various tricks needed to work using these conventions, such as:

  <!ELEMENT limerick (line, line, line, line, line)>
				

to define a strictly five-line verse, or

  <!ELEMENT double-entendre (phrase, meaning, meaning+)>
				

to define it as a phrase followed by two or more meanings:

  <double-entendre>
    <phrase></phrase>
    <meaning></meaning>
    <meaning></meaning>
    ... more <meaning>s if required ...
  </double-entendre>

This method is quite a limitation if you wanted to define an element with, perhaps, twenty child elements. Both W3C Schemas and RelaxNG provide more effective ways of defining multiple child elements.

So far, we've only defined tags which contain other tags, so we need a way of allowing tags to contain arbitrary text. We can do this using a #PCDATA clause:

  <!ELEMENT phrase (#PCDATA)>
				

which allows any text except tags to be included as part of the phrase. Allowing a mixture of tags and text is trickier, and often confuses parsers and validators. You can mix #PCDATA with other elements in a choice list, but not in a sequence list, so:

  <!ELEMENT line (#PCDATA | emphasis | rhyme)*>
				

is valid, and could give the following markup:

  <line>There <emphasis>was</emphasis> a 
    young lady from <rhyme>Crewe</rhyme>
  </line>

but the next mixes #PCDATA within a sequence, so isn't a valid DTD definition:

  <!ELEMENT double-entendre (phrase, meaning, meaning+, #PCDATA)>
				

In this case, you'll need to define another element which then contains the arbitrary text itself. Generally, though, mixing text and elements is frowned upon as poor document design, unless the document calls for “inline” markup (as, for example, the inline elements in XHTML such as <strong>, <a>, etc.).

It's common to want to refer to a certain section of a document using some kind of identifier, so provision has been made for this using the special attribute 'ID'. This is reserved for use as a unique marker within each document (HTML has this feature, though it is little used). In particular, many database applications of XML will generate or read this attribute as a part of its key for the data.

  <!ATTLIST joke code ID #REQUIRED>
                

You can also define an attribute to be a list of such IDs, as cross-references:

  <!ATTLIST joke seealso IDREFS #IMPLIED>
                

Practical task

Develop a document type of your own. To begin, think of a type of document that has a simple structure, and that records the same information regularly within that structure. A simple example might be an address book - each entry follows a regular pattern and records the same type of information for each person. Begin by marking up a “typical” document, creating the tags as you go. Then deconstruct the marked up document into a series of element definitions in a separate file. As you go, try creating a new document using your DTD in <oXygen/>, using the validation facility to test your DTD. This works best with regular, well-structured documents, such as meeting minutes, restaurant menus, recipes, product specifications (e.g. cars, computers,...) and so on. As an example, I've created a DTD for the module outlines that we produce to define each module (e.g. this one) that you take (see the outlines folder for other related files).

Entities are used for several reasons:

Defining a text entity (an internal general entity) in the DTD:

  <!ENTITY uoe "University of Exeter">
                    

then using the entity in an XML document:

  <p>The &uoe; is a very rainy place</p>
                    

Inserting Accents and Symbols

Remember the encoding parameter in the XML declaration, which we mentioned way back in the introduction in Example 2, “An example of a home-made markup language in XML”?

  <?xml version="1.0" encoding="UTF-8"?>
                        

An XML document can be written as a Unicode document, which allows the use of a vast array of multinational characters. Unicode should be used wherever possible, and should cope with most situations you come across. However, when dealing with legacy data, it's sometimes necessary to deal with other encodings.

In the past, it was more usual to write XML as plain ASCII, a standard format that almost all text editors use. Since ASCII doesn't have provision for multinational and symbol characters, we need a way of defining them, and inserting them easily into our text.

Special characters are already part of the XML standard; any Unicode character can be inserted using a character reference, which looks similar to an entity and uses the character's Unicode reference number, e.g. an e-acute is é

As you can see, this isn't exactly an easy-to-remember way of inserting special characters, so we usually define entities as more memorable references. In XHTML, for example, we can use the entity é which is defined as:

  <!ENTITY eacute CDATA "&#233;" -- small e, acute accent -->
                        

There's a list of character references for commonly used characters in Appendix C of Castro (2001), and there are numerous more complete lists on the web.

Exercises

Using the DTD and XML data documents you created for the previous exercise, try the following: Add a few standard accented characters (e.g. umlauts or acute/grave accents) as entities to your DTD. Insert a lang="____" attribute to one of the elements in your DTD. Add some multilingual text to your documents, with the relevant language attribute set. Hint: you'll also need to allow multiple instances of the tag containing the multilingual text.

External Entities

An external entity defines a binary chunk of data for later use. It's commonly employed for regularly used data such as graphical logos or icons that are used frequently within all documents of the type being defined; it's not normally used for one-off graphics such as diagrams, illustrations or other “content-related” items. Here's how it works: :

                              <!ENTITY unilogo SYSTEM logo-large.jpg NDATA jpg>
  <!ENTITY cmitlogo SYSTEM cmit-logo.gif NDATA gif>
                

Creating an attribute that refers to that data:

  <!ELEMENT logo (alternatetext?)>
  <!ATTLIST logo image ENTITY #REQUIRED>
  <!ELEMENT alternatetext (#PCDATA)>
                        

then referring to that picture in the XML file:

  <logo image="cmitlogo">
    <alternatetext>Creative Media and 
      Information Technology.</alternatetext>
  </logo>
                        

Including images as entities

In practice, this method of including an image is clumsy and very restrictive, since the location of the image file must be defined in the DTD. It's much more usual to merely indicate a filename as a standard attribute and use a stylesheet or script to insert the image. The entity method can, however, be useful to include very commonly used items such as a corporate logo, or regularly used icons, as part of a the text of the document.

                            <!NOTATION jpg SYSTEM "image/jpeg">
                            <!NOTATION svg SYSTEM "image/svg-xml">