XML DTD Modules Part One

French | Spanish | Portuguese | Italian | German | Japanese | Chinese | Korean | Russian | Arabic

XML DTD Modules DTD modules are better defined than abstract modules, although not quite as flexible. structures. Parameterization is extremely powerful, but it does take some getting used to.

Tip XHTML 1.1 DTD modules are a lot harder to read than many XML DTDs. If you can't penetrate the formal description of a given module, the abstract module should help you. If you write your own modules, it is critical that you include abstract modules.

XREF The rules for creating XHTML 1.1's XML DTD modules are presented in Section 5 of the Building XHTML Modules draft and demonstrated in Section 6. There are a few additional conventions used in Modularization of XHTML that Building XHTML Modules doesn't describe, which I cover here as well. They appear useful and help explain some of the syntactical shortcuts (such as the Common attributes) used in abstract modules. Parameterization just means putting all the contents of declarations into param-eter entities. This makes the declarations easier to manage, and at the same time makes it much easier to modify them. While you can modify attribute declarations and parameter entities by making the declaration again, XML prohibits multiple declarations for element types. By putting the contents of those declarations into parameter entities, the creators of XHTML modules can provide a lot more flexibility. Let's look at examples of each of these suffixes taken from the W3C draft DTD, building from the smallest atomic pieces to the largest.

.datatype The data types in XHTML 1.1 are direct descendants of those in XHTML 1.0, and they are declared in Section B.2.1. Most of the data types are simply more precise names for CDATA, textual content:

   <!-- a Uniform Resource  Identifier, see [URI] -->
 <!ENTITY % URI.datatype  "CDATA" >

These data types are then used in attribute declarations:

   <!ATTLIST a
   %Common.attrib;
   href %URI.datatype; #IMPLIED
   charset %Charset.datatype; #IMPLIED
   type %ContentType.datatype; #IMPLIED
   hreflang %LanguageCode.datatype;  #IMPLIED
   rel %LinkTypes.datatype; #IMPLIED
   rev %LinkTypes.datatype; #IMPLIED
   accesskey %Character.datatype;  #IMPLIED
   tabindex %Number.datatype; #IMPLIED
   > 

All of these data type declarations actually resolve to CDATA when an XML processor reads the DTD, but they make the content that should be stored in these attributes much more identifiable.

Tip

While XML 1.0 processors can't do much to enforce data typing today, schema processors should be capable of accomplishing more with this information in the future. Think of this approach as adding information to the DTD so it's ready for the next version. These data type names are used in the abstract modules for XHTML 1.1 as well, supplementing the core XML 1.0 set of types.

.attrib The .attrib suffix is used on parameter entities that represent one or more attribute specifications – the part of an attribute list declaration that defines individual attributes, their types, defaults, and possible values. These entities sometimes describe only one attribute, like this one for the id attribute:

   <!ENTITY % Id.attrib
   "id ID
   #IMPLIED"
   > 
   They may specify multiple  attributes, like this one for xml:lang and dir:
   <!ENTITY % I18n.attrib
   "xml:lang  %LanguageCode.datatype; #IMPLIED
   dir ( ltr | rtl ) #IMPLIED"
 > 

These entities also may include other entities with the .attrib suffix, as in the ubiquitous Common.attrib entity:

   <!ENTITY % Common.attrib
   "%Core.attrib;
   %I18n.attrib;
   %Events.attrib;"
   > 

This just includes all of the attribute specifications declared in the Core.attrib, I18n.attrib, and Events.attrib entities, building a large list of common components. The quotes need to be used even though all of the contents of the entity are contained in parameter entities.

.attlist The .attlist suffix (not documented in Building XHTML Modules) is used in the XHTML 1.1 DTDs to turn ATTLIST declarations on and off. Parameter entities that have the .attlist suffix take one of two values: INCLUDE or IGNORE. These function with a feature of XML 1.0 DTDs not used in XHTML 1.0: conditional sections.

Tip For a much more detailed explanation of conditional sections and their use in other XML contexts, see Article 16 of XML Elements of Style by Simon St. Laurent (McGraw-Hill, 2000). Conditional sections may appear in DTDs only; they enable DTD designers to turn sets of declarations on and off. By using parameter entities to determine whether to include or ignore a section, developers make it possible to use portions of a DTD or even choose among different variations on a single DTD. For example, this DTD fragment includes the attributes for the title element type:

   <!ENTITY % Title.attlist  "INCLUDE" >
   <![%Title.attlist;[
   <!ATTLIST title
   %I18n.attrib;
   > 
 <!-- end of Title.attlist  -->]]>

The first line creates a parameter entity named Title.attlist whose value is INCLUDE. In the next line, the entity is substituted with %Title.attlist; to produce these resulting declarations:

   <![INCLUDE[
   <!ATTLIST title
   %I18n.attrib;
   > 
 <!-- end of Title.attlist  -->]]>

 <!ATTLIST title
 %I18n.attrib;
 > 

 <!ATTLIST title
 xml:lang %LanguageCode.datatype;  #IMPLIED
 dir ( ltr | rtl ) #IMPLIED
 > 

 <!ATTLIST title
 xml:lang NMTOKEN #IMPLIED
 dir ( ltr | rtl ) #IMPLIED
 > 

 <!ENTITY % Title.attlist  "IGNORE" >

 <![IGNORE[
 <!ATTLIST title
 %I18n.attrib;
 > 
 <!-- end of Title.attlist  -->]]>

.content The .content suffix functions for parameter entities that describe content models for particular element types. The simplest example, for an EMPTY content model, looks like this:

   <!ENTITY % Input.content  "EMPTY" >
 <!ELEMENT input %Input.content;  >

When processed, this resolves to:

   <!ELEMENT input EMPTY >

and defines the input element as having an empty content model. By redeclaring entities with a .content suffix, other modules easily can modify the content model of an element.

.class (and .extra) The .class suffix functions for parameter entities that may be used repeatedly in content models for multiple elements, but only when the contents are element type names that all share something in common. In XHTML, this tends to mean that block elements are one class, while inline elements are another class. These entities aren't defined (with one exception, noted next) in the Modularization of XHTML draft. They are defined in the customization file, another module, in Appendix C of XHTML 1.1 - Module-based XHTML. For example:

 <!ENTITY % Inlstruct.class  "br | span" >

Through the abbreviations, you can see that these are structural element types that may appear as inline elements. br is used for line breaks within block elements, while span is an abstract element mostly useful for marking off inline content in ways that aren't reflected by other inline content. This entity and several of its siblings get combined into a larger Inline.class entity:

   <!ENTITY % Inline.class
   "%Inlstruct.class;
   %Inlphras.class;
   %Inlpres.class;
   %I18n.class;
   %Anchor.class;
   %Inlspecial.class;
   %Ruby.class;
   %Inline.extra;"
 > 

One oddity here is Inline.extra – Building XHTML Modules describes no "official" convention for .extra. Inline.extra has this declaration:

   <!ENTITY % Inline.extra
 "| input | select | textarea |  label | button" >

The DTD comments describe how to use this .extra suffix: While in some cases this module may need to be rewritten to accommodate changes to the document model, minor extensions may be accomplished by redeclaring any of the three *.extra; parameter entities to contain extension element types as follows:

%Misc.extra; whose parent may be any block or inline element. %Inline.extra; whose parent may be any inline element. %Block.extra; whose parent may be any block element. If used, these parameter entities must be an OR-separated list beginning with an OR separator ("|"), eg., "| a | b | c" While .extra is undocumented (so far) in Building XHTML Modules, it is a critical piece for developers who want to add their own extensions to XHTML 1.1. The .class suffix also functions in at least one place for attributes. The following entity includes all of the input types:

   <!ENTITY % InputType.class
   "( text | password | checkbox |  radio | submit
   | reset | file | hidden | image  )"
 > 

This is then used in an attribute declaration:

   <!ATTLIST input
   %Common.attrib;
 type %InputType.class; 'text'

This anomaly probably derives from the input element's unusual use of an attribute to signify its "real" content.