Implementing This Tag Set
This Suite has been written as a series of XML DTD modules that can be combined into a number of different tag sets. The modules
are separate physical files that, taken together, define all element structures (such as tables, math, chemistry, paragraphs,
sections, figures, footnotes, and reference elements), as well as attributes and entities in the Suite.
Modules in the Suite are primarily intended to group elements for maintenance. There are different kinds of modules. A module
- Be a building block for a base Tag Set (such as the Module to Name the Modules module)
- Define the elements inside a particular structure. For example, the Bibliography References (Citation) Elements Module module names all the potential components of bibliographic reference lists.
- Name the members of a “class” of elements, where class is a named
grouping of elements that share a similar usage or potential location. For example, the Phrase-Level Content Elements Module module defines small floating elements that may occur within text, such as inside a paragraph or a title, or that describe
textual content, for example, a disease name, drug name, or the name of a discipline.
- Be a module of “editorial convenience”. For example, the Common (Shared) Element Declarations Module module holds elements and attributes used in the content models of the various class elements.
The major disadvantage of a modular system is the longer learning curve, since it may not be immediately obvious where within the system to find a particular element or attribute cluster. To help with this, each element page includes an expanded
content model and also names the module in which that element is defined.
There are many advantages to such a modular approach. The smaller units are written once, maintained in one place, and used
in many different tag sets. This makes it much easier to keep lower level structures consistent across document types, while
allowing for any real differences that analysis identifies. A tag set for a new function (such as an authoring tag set) or
a new publication type can be built quickly, since most of the necessary components will already be defined in the Suite.
Editorial and production personnel can bring the experience gained on one tagging project directly to the next with very little
loss or retraining. Customized software (including authoring, typesetting, and electronic display tools) can be written once,
shared among projects, and modified only for real distinctions.
If you want to learn about the Tag Set in order to write a new tag set based on this Tag Set or to modify the current Tag
- Skim the first two chapters of this Tag Library, the How to Use and the Tag Library General Introduction.
- Read the parameter entities that name the classes (the module default-classes.ent)
- If you do not know the symbols used in the Document Hierarchy diagrams, then read the “Key to the Near & Far® Diagrams”.
- Use the Document Hierarchy diagrams to give you a good sense of the top-level elements and their contents.
- Pick an element from one of the diagrams (Look up the element in the Elements Section to find the full name of the element,
the definition, usage notes, content allowed, and attributes list. Look up one of the attributes to find its full name, usage
notes, and potential values.).
- Read the Tag Set Modules. New Tag Sets are created by writing, at a minimum, a new DTD module and new
customization modules, so you might want to read the modules in this order: