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

The parameter entities AuthoringSwitch and FinalSwitch can then be declared as the keyword INCLUDE or IGNORE, according to which version of this entity you want to use. For the first, loose, version you would insert these declarations before these conditional sections:

<!ENTITY % AuthoringSwitch “INCLUDE”>
<!ENTITY % FinalSwitch     “IGNORE”>
<![%AuthoringSwitch; [
   <!ENTITY % body “chapter, intro?, section*”>
]]>
<![%FinalSwitch; [
   <!ENTITY % body “chapter, intro, section+”>
]]>

And for the second, tighter, version, you would insert these declarations before these conditional sections:

<!ENTITY % AuthoringSwitch “IGNORE”>
<!ENTITY % FinalSwitch     “INCLUDE”>
<![%AuthoringSwitch; [
    <!ENTITY % body “chapter, intro?, section*”>
]]>
<![%FinalSwitch; [
    <!ENTITY % body “chapter, intro, section+”>
]]>

This might seem to be a trivial feature because only a small section is affected like in the examples, but you can use pairs of parameter entities like this to control many separate sections of a DTD. By changing the values of these two parameter entities, you could radically change the whole DTD.

Optional Content Models and Ambiguities

When you review a DTD you are working on, take a close look at the occurrence indicators. If a lot of optional elements exist in a content model, this will often be an indication that something is wrong with the model.

An example of this comes from the SGML world of books. Consider the back part of a book. You might create an XML DTD for a book, for instance, and create a container element BACK to make it easier to process the parts together. The BACK element consists, as books often do, of any number (including zero) of appendixes, followed by an optional glossary and then an optional index. When you can describe a content model in plain English such as the following, it is quite easy to model:

<!ELEMENT BACK (appendix*, glossary?, index?)

The content model might look good, but a problem exists. Everything is now optional, making it possible for a document to have an empty BACK element, which certainly wasn’t the idea. Well, one way to get around this is to break the content model into inner groups, where each group explicitly describes one of the possibilities:

<!ELEMENT BACK ( (appendix+, glossary?, index?) |
                 (appendix*, glossary, index?) |
                 (appendix*, glossary?, index) )>

That seems to cover it. Now we’ll check:

•  Group 1—You can have one or more appendixes, followed by an optional glossary and then an optional index.

•  Group 2—You can have zero or more appendixes, which must be followed by a glossary and then an optional index.

•  Group 3—You can have zero or more appendixes, followed by an optional glossary and an index, which is required.

It seems pretty complete—and no empty BACK elements are allowed. But now an even bigger problem exists. This markup won’t work!

Parsers aren’t intelligent. They are not able to remember what they’ve seen; they can’t look ahead at what comes next and then backtrack to confirm that your markup agrees with content model. When the parser sees an appendix element, it really cannot tell what’s supposed to happen next. Should a glossary element be next? This content model is ambiguous.

One way to get around this problem is to adopt what is called the waterfall approach, where you take each element in turn and work out only the new cases you need to cover. For the first element, you’d have to consider a lot of possibilities; then you’d consider fewer for the second and even fewer for the third, until, with the last element, hardly any possibilities are left. We’ll adopt this approach here and follow the process step by step, re-examining the three groups defined earlier as we go:

•  Group 1—You can have one or more appendixes, followed by an optional glossary and then an optional index. The first group seems OK.

•  Group 2—You can have zero appendixes (we’ve already covered the one or more possibility), which must be followed by a glossary and then an optional index.

•  Group 3—You can have zero appendixes and no glossary, but then an index must be present.

This is much better, and after we write it out in the DTD, it turns out to be the answer:

<!ELEMENT BACK ( (appendix+, glossary?, index?) |
                 (glossary, index?) |
                 (index) )>