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

WebWriter has played it safe in allowing every element to have mixed content (#PCDATA is allowed in all the content models), and it was wise not to guess about the nature of the element attributes. This gives you a good framework for your DTD. To complete it, you can tighten up the content models and fill in the attribute declarations. One possible end result is shown in Listing 14.4.

Listing 14.4 Home.dtd—Final Home.dtd DTD

<?xml version = “1.0”?>
<!ELEMENT home.page (head | body | footer)>
<!ELEMENT head (title | banner?)>
<!ELEMENT title (#PCDATA)>
<!ELEMENT banner EMPTY>
<!ATTLIST banner
          src CDATA #REQUIRED
          alt CDATA #IMPLIED
          align (top | middle | bottom) #IMPLIED>
<!ELEMENT body(main.title |rule | text)>
<!ELEMENT main.title (#PCDATA)>
<!ELEMENT rule EMPTY>
<!ATTLIST rule
          align (left|right|center) #IMPLIED
          size NMTOKEN #IMPLIED
          width CDATA #IMPLIED >
<!ELEMENT text(#PCDATA | para)*>
<!ELEMENT para(#PCDATA)>
<!ELEMENT footer EMPTY>
<!ATTLIST footer
          src CDATA #REQUIRED
          alt CDATA #IMPLIED
          align (top|middle|bottom) #IMPLIED>
<!ENTITY lt “<“>
<!ENTITY gt “>”>
<!ENTITY apos “‘“>
<!ENTITY quot “””>
<!ENTITY amp “&”>

---

NOTE:  In accordance with the XML specification, now that we are using a DTD, we have included the declarations of the default character entities (lt, gt, apos, quot, and amp).

---

Richness and Entropy

If you want to do something with a piece of information in an XML document, you must identify it. It doesn’t matter whether you mark it up using elements or attributes, but if you haven’t marked it up, you either won’t be able to find it at all, and even if you can find it, you won’t be able to do anything with it.

A DTD that contains a lot of (informative) markup is called a rich DTD. As the DTD designer, you will always face a difficult compromise between the complexity of the DTD and the information richness of XML documents that conform to that DTD. Where humans are the authors of those documents, the complexity of the DTD can become a major obstacle.

When you have the room to make choices, always choose the richest information model you can:

•  It is far easier to throw away information than it is to add it afterward.
Consider what happens when you go from XML, or even HTML, to plain text with no markup at all. It’s a simple conversion to make because you are moving from a higher information richness to a lower one. Going the other way is not easy at all. The same applies for moving from SGML to XML, and from XML to HTML. At each conversion you throw information away, moving from an information-rich level (SGML) to a relatively poor level (HTML).

•  You cannot always account for all media and all intended uses. No matter how carefully you research your application in advance, something you haven’t thought of will occur.
With SGML, it is often the case that it’s only after you’ve got all your data marked up that you really start to appreciate what you can do with it. If you limit yourself to the minimum necessary for the current application, you may design yourself into a corner where there is no room left for expansion.

Visual Modeling

Earlier in this chapter, you learned that one of the basic DTD design process steps is to construct the hierarchy, to use the content models in the DTD to arrange the elements in an XML document that uses the DTD in a hierarchical, tree-like structure. Many information modeling techniques are available, but detailed discussion of them falls outside the scope of this book. What is of interest to us here is that all recommend some kind of visual aid to help you. The same applies for DTD development, but each expert has his or her own set of symbols. Some prefer to model using the blocks familiar from flow diagrams, as shown in Figure 14.5.

FIGURE 14.5  Block diagram DTD modeling.

An alternative is the somewhat sparser representation form shown in Figure 14.6.

FIGURE 14.6  Simplified diagram DTD modeling.

Note that both types of modeling graphics try to represent the sequence and OR models by using different kinds of connecting lines between the objects (diagonal for an OR choice, straight lines for a simple relationship, and rectangular connections for sequences). This type of modeling graphics is also incorporated in the top-of-the-line SGML DTD modeling package, Microstar’s NEAR & FAR, an example of which is shown in Figure 14.7.

FIGURE 14.7  Visual modeling in NEAR & FAR.

It is difficult to think of a better way of modeling DTDs visually than these kinds of models (different is easy; better is hard), especially in a software package where you can expand and collapse branches of the DTD tree as you work on them. However, as the DTD gets larger and larger, it becomes harder and harder to maintain a sensible overview. You shouldn’t forget that these are primarily SGML tools where people are mostly working on a different scale than is probably useful in XML. Where an XML application might need a few tens of elements and a couple hundred lines in a DTD, SGML applications routinely think in terms of several hun-dred elements and several thousand lines of declarations in a DTD. It isn’t only the number of elements that makes the DTD bulky, though. Often, elements that have a presentational function (such as emphasized text) will be reused in almost every element. When you expand these models, as you can see from Figure 14.8, unless you start finding other ways to manage DTDs of this scale or complexity, even a well-designed visual presentation can become too cluttered for it to be of much use.

FIGURE 14.8  Reaching the limits of useful visual modeling.