Platinum Edition Using HTML 4, XML, and Java 1.2
(Publisher: Macmillan Computer Publishing)
Author(s): Eric Ladd
ISBN: 078971759x
Publication Date: 11/01/98

Element Sequences

The simplest form of element content model is a sequence consisting of a list of the possible elements, enclosed in parentheses and separated by commas:

<!ELEMENT counting (first,second,third,fourth)>

This example means that a counting element must consist of a first element, followed by a second element, followed by a third element, and ending with a fourth element.

In this example, all four elements must be present in a counting element, and each may be present only once (you can specify how often an element may appear by using an occurrence indicator, which you will learn about later in this chapter).

An element model with a sequence such as this would be used whenever you have an element that must be made up of a specific number of parts, which must occur in a specific order, and all of which must be present. For instance, you could create a business.letter element defined as follows:

<!ELEMENT business.letter (date,address,greeting,body,salutation)>

A sequence such as this could also be used to count up the chapters in a book; however, remember that all the elements in the sequence must appear. Therefore, this will only work if you know precisely how many chapters you wish to use.

Choices

A choice of elements in an element content model is indicated by a | between the alternatives:

<!ELEMENT choose (this.one | that.one)>

so that a choose element consists of either a this.one element or a that.one element.

Notice once again that without an occurrence indicator, the chosen element can appear only once. Note also that only one element can be selected, no matter how long the list of alternatives is:

<!ELEMENT choose (this.one | that.one | the.other.one | another.one | no.that.one.silly)>

The choice element content model works best when a number of choices are available, one and only one of which must be selected. A correspondence element, for example, might include a number of choices to describe the type of correspondence:

<!ELEMENT correspondence (business.letter | personal.letter | quick.note)>

Combined Sequences and Choices

You can combine content sequence and choices by grouping the element content into model groups. For example:

<!ELEMENT lots.of.choice (maybe | could.be), (this.one, that.one)>

Here, a lots.of.choice element can consist of either a maybe element or a could.be element, followed by one this.one element and then one that.one element. This type of combination model could be used for address data, for instance:

<!ELEMENT return.address (business.name |
personal.name),(street.address,city,state,zip)>

In this example, the address can belong to either a business or a person, and then must include a street address, city, state, and zip code.

---

Ambiguous Content Models

Although you can combine sequences and choices like this, you need to be very careful. You can create compatibility problems if your content model can be interpreted in more than one way. Consider this possibility:

<!ELEMENT confused ((this.one, that.one) | (this.one, the.other.one))>

When the XML processor checks the content of the XML document to see whether the elements are in an allowed order (when it “validates” the document), it is going to be able to decide what is allowed and what isn’t. In this case, once it sees the this.one element, it’s impossible for it to work out which element is supposed to come next.

The XML processor could, of course, read further and then check to see if what occurs next is allowed, but XML processors are not meant to be able to look ahead. Remember, XML processors are meant to be simple and fast; if the processor has to look ahead, it is going to have to save what it has seen in memory, then look ahead, read in the next part, save that in memory, compare the two memory contents and then decide. All this takes extra processing and time.

By careful consideration, you can avoid ambiguous content models with a little rewriting:

<!ELEMENT unconfused (this.one, (that.one | the.other.one))>

Generally, any time that you start combining these two operators, you should be on the lookout for ambiguities. Consider another example:

<!ELEMENT confused.again (this.one, that.one, the.other.one) |
no.that.one)>

This could easily lead you (and the XML processor) to believe that the no.that.one element is an alternative for all the other elements, or is it an alternative for a the.other.one element? Again, some rewriting can resolve the ambiguity and make your intention clearer:

<!ELEMENT explained (this.one, that.one, (the.other.one | no.that.one))>

---

Occurrence Indicators

Using an occurrence indicator, you can specify how often (or not) an element or group of elements may appear in an element. Three occurrence indicators exist (without an occurrence indicator, the element or group of elements must appear only once):

•  The ? character indicates that the element or group of elements may be omitted or may occur only once (zero or one time). The following content model:

<!ELEMENT testing (one, two?, three)>

would allow you to have

<testing><one>tock</one><two>tock</two><three>tock</three></testing>

or

<testing><one>tock</one><three>tock</three></testing>

in your XML document.

•  The * character indicates that an element or group of elements may be omitted or may appear any number of times (zero or more times).

<!ELEMENT nice (mmm, mmmm*)>

would allow you to have

<nice><mmm>I can’t complain.</mmm></nice>

or

<nice><mmm>I like this one.</mmm><mmmm>More, </mmmm><mmmm>more, </mmmm>
<mmmm>more, </mmmm><mmmm>more, <mmmm>more.</mmmm></testing>

•  The + character indicates that an element or group of elements must appear at least once and may appear any number of times (one or more times).

<!ELEMENT funny (ha, haha+)>

would allow you to have

<funny><ha>Who?</ha><haha>is he?</haha></funny>

or

<funny><ha>I laughed </ha><haha>until </haha><haha>I </haha>
<haha>thought </haha><haha>I’d <haha>die!</haha></funny>