Parameter entities are the major mechanism for customizing this Tag Set or creating a
new tag set from the modules in the Suite. Individual tag sets will be constructed by (1)
establishing element and attribute combinations and content models using parameter entities in one of the Tag-Set-specific
customizing modules and (2) choosing appropriate modules from the Suite that declare the elements needed. For example, if
the base tag set contained 6 kinds of lists and 2 table models, a more specific tag set, such as an authoring tag set, might
use a Customize Classes Module to redefine the List Class to name only 3 lists and redefine the Display Class to allow only
one table model.
The standard modules to create a customized tag set are: the DTD itself, a module to name its components, and as many override
modules and new elements modules as necessary. Typical modules for a new tag set are:
- DTD — The DTD module (.dtd) for the new tag set base DTD (At a minimum, this module declares the top-level element (such as article, book, or report)
and any other structural elements unique to the new document type.)
- Tag-Set-specific Module of Modules — Module to name all the new modules created expressly for the new Tag Set
- Class overrides — Tag-Set-specific overrides of the Suite default element classes
- Mix overrides — Tag-Set-specific overrides of the Suite default class mixes
- Model overrides — Tag-Set-specific content model overrides for the content models in the modules of the Suite (using “-elements” and “-model” parameter entities)
- New Models — Tag-Set-specific new elements (for example, a new Book Tag Set might add book-specific metadata elements)
Many of the elements in the Journal Publishing Tag Set have been grouped into loose element classes. There is no hard and
fast rule for what constitutes a class; each one is a design decision, a matter of judgment. These classes are designed to
ease customization to meet the particular needs of new tag sets. Base classes for the JATS DTD Suite are defined in a separate
Default Element Classes Module
These element classes can be viewed as building blocks that will be used to build larger parameter entities for element mixes.
A mix describes a usage circumstance for a group of elements, such as all the paragraph-level elements, all the elements allowed
inside a table cell, all the elements inside a paragraph, or all the inline elements. For example, to add another block display
item to the Block Display Class Elements
, you would edit the %block-display.class;
parameter entity in your Tag-Set-specific Class Override Module to override the default parameter entity that is defined
in the Suite’s Default Element Classes Module
and create a new module containing the Element Declaration of the new block display item.
PARAMETER ENTITY: SAME FUNCTION, SAME NAME — The Suite modules and initial Tag Sets have used a series of parameter entity naming conventions consistently. While parsing
software cannot enforce these parameter entity naming or usage conventions, these conventions can make it much easier for
a person to know how the content models work and what must be modified to make a Tag Set change.
— Classes are functional groupings of elements used together in an OR group. Each class is named with a parameter entity,
and all class parameter entity names end in the suffix “.class”:
<!ENTITY % list.class "def-list | list">
A class, by definition, should never be made empty; the class should be removed from all models where you do not want the
class elements included.
— Mixes are functional OR groups of classes; mixes should never contain element names directly. All mixes must be declared
after all classes, since mixes are composed of classes. Mix names have no set suffix; for example, they may end in “-mix” or “-elements”. Content models and content model overrides use mixes and classes for all OR groups. Only content model sequences are made
up of element names directly.
— Parameter entity mixes for overriding a content model are of two styles: (1)
inline mixes and (2) full content model replacements. These two groupings have been defined and named separately to preserve
the mixed-content or element-content nature of the models in Tag Sets derived from the Suite.
The inline parameter entities to be intermingled with character data (#PCDATA
) in a mixed content model are named with a suffix “-elements
”. For example, “%institution-elements;
” would be used in the content model for the element <institution>
<!ENTITY % institution-elements "| %subsup.class;" >
<!ELEMENT institution (#PCDATA %institution-elements;)* >
All inline mixes begin with an OR bar, so that the mix can be removed leaving just character data (#PCDATA):
<!ENTITY % rendition-plus "| %emphasis.class; | %subsup.class; |
The override of a complete content model will be named with a suffix “-model” and should include the entire content model, including the enclosing parentheses:
<!ENTITY % kwd-group-model "(label?, title?, (%kwd.class;)+ )" >
<!ELEMENT kwd-group %kwd-group-model; >