Pass 1: A DTD That Looks Like the Old Styles

We’ll start by setting up a chapter structure. Chapters will eventually themselves become part of the larger book structure. The Chapter will include a title, a brief introduction, and a series of sections marked by A heads. In the interest of ensuring a smooth transition, the original style names are used where possible, although spaces must be stripped out:

  <!ELEMENT CHAPTER (HEAD?,TOC0CT, INTRODUCTORY, ALEAF*)>

The HEAD element uses the DTD described previously to allow style sheet linking. The TOC0CT element performs the same duty as the TOC0 CT style: it identifies the chapter title. It contains only text:

  <!ELEMENT TOC0CT (#PCDATA)>

The INTRODUCTORY element is new, making explicit a chapter feature that wasn’t included in the previous definition. All chapters start with text after the chapter headline to introduce the material to follow. The INTRODUCTORY element is required and must consist of at least one body text (BT) paragraph. (No code listings or other subelements should appear in the introduction for now.)

  <!ELEMENT INTRODUCTORY(BT+)>

The BT element is a bit more complicated because the text in it can include italic items (like citations) and bold items (like keystrokes and menu clicks—user actions). To address these needs, we’ll create a few elements and a parameter entity that includes them, making it easier for us to include them in other elements.

  <!ELEMENT CITATION (#PCDATA)>
  <!ELEMENT USERACTION (#PCDATA)>
  <!ENTITY % textual-elements "(#PCDATA|CITATION|USERACTION)*">
  <!ELEMENT BT(%textual-elements;)>

The next target is the ALEAF element. To avoid confusion with the HTML tags A and B, I’ve added the word LEAF to the letters for all of these sections. Because the leaves may contain a variety of content types, it’s time to plan ahead and create a parameter entity. The content-elements entity will contain a list of all types of content available to a LEAF element, which includes only the PARAGRAPH element at present.

  <!ENTITY % content-elements "BT">

All the LEAF elements will contain a header and paragraphs or sublevels.

  <!ELEMENT ALEAF (TOC1A,BT,(%content-elements;|BLEAF)*)>
  <!ELEMENT BLEAF (TOC2B,BT,(%content-elements;|CLEAF)*)>
  <!ELEMENT CLEAF (C,BT,(%content-elements;|DLEAF)*)>
  <!ELEMENT DLEAF (D,BT,(%content-elements;|ELEAF)*)>
  <!ELEMENT ELEAF (E,BT,(%content-elements;)*)>
  <!ELEMENT TOC1A (#PCDATA)>
  <!ELEMENT TOC2B (#PCDATA)>
  <!ELEMENT C (#PCDATA)>
  <!ELEMENT D (#PCDATA)>
  <!ELEMENT E (#PCDATA)>

Note that we didn’t include the LEAF elements as part of the content elements entity. This would have allowed authors to put ELEAF elements directly below ALEAF elements, violating the desired hierarchy. Instead, they remain separate, making it easier for the designer to see the structure. Using the (%content-elements | XLEAF)* structure allows zero or more layers of content: ALEAFs aren’t required to have BLEAF elements, but you can’t have a CLEAF element unless it’s included in a BLEAF element. (Later in this chapter, we’ll change this, simplifying the structure considerably.)

This provides the basic structure for a chapter, building a basic outline form that can go five levels deep. (If a chapter moves beyond five levels, it will be either time to reconsider the chapter’s organization or add a level to the DTD.) It’s time to go back and add content beyond basic text paragraphs. The easiest type of information to manage in this context is code. The current style sheet uses four different styles for code, depending on the position of the line of code. In XML, what matters most is not the position of the code, but that the information is code. Style sheets get to clean up the presentation and apply the extra space before and after the code element. Our code element, to match the style sheet, will be named CC. By default, our CC element’s TYPE attribute will be “CODE” because very few books still have textual output. For those books that do, we provide an “OUTPUT” value option for the TYPE, allowing the designer to format these two similar types slightly differently. A CC element may contain a listing caption (LC) and must include at least one CLINE (code line) element, with multiple lines available to store code as necessary.

  <!ELEMENT CC (LC?,CLINE+)>
  <!ATTLIST CC TYPE (CODE|OUTPUT) "CODE">
  <!ELEMENT LC (#PCDATA)>
  <!ELEMENT CLINE (#PCDATA)>