Introduction to Parameter Entities

Parameter Entity Pages

Although the parameter entities are declared in many different modules, they are described here in alphabetical order of their XML names (i.e., parameter entity type names). The XML name is the shorter machine-readable name used in XML vocabularies and by software; for example, the XML name %app.class; is used for the parameter entity named Just Appendix Class Elements. Parameter entity names always begin with a percent sign and end with a semi-colon.

Each parameter entity is described by a separate HTML page, where the heading for the page displays the parameter entity’s XML name followed by a more descriptive name. The rest of the parameter entity description page discusses aspects of the parameter entity and its usage. These sections within the page always appear in the following order although any given parameter entity description may not contain all the sections:

Parameter Entity Naming Conventions

This Tag Set and the Suite modules have used a series of design and naming conventions consistently. While parsing software cannot enforce these parameter entity usage or naming conventions, these conventions can make it much easier for a person to know how the content models work. The Journal Publishing Tag Set (and the entire Journal JATS DTD Suite) use the following usage and naming conventions.

• Classes — Classes are functional OR-groups of elements. All class names end in the suffix “.class”. For example:

  <!ENTITY % list.class   "def-list | list"             >

  
  Classes cannot be made empty; the class should just be removed from all models where you do not want the elements included.
• Mixes — Mixes are OR-groups of classes. All mixes must be declared after all classes, since mixes are composed of classes. (In best practice, mixes never contain element names directly.) Mix names have no set suffix, and only a few have been named “.mix”. Some mixes are inline to be intermingled with #PCDATA in a mixed content model while other mixes are grouping of block-level elements. All inline mixes begin with an OR bar. For example:

  <!ENTITY % rendition-plus
              "| %emphasis.class;  | %subsup.class; |
               %phrase-content.class;"                  >

• Content — Content models and content model overrides use mixes and classes for all OR groups. Only sequences are made up of element names directly. Content models overrides are of two types, which are defined separately to preserve the mixed-content or element-content nature of the models as an aid to interchange.
  • -models — The override of a complete content model will be named with a suffix “-model”. The override contains the entire content model, including the enclosing parentheses, for example:

    <!ENTITY % kwd-group-model
                "(label?, title?, (kwd | compound-kwd | 
                 nested-kwd)+ )"                          >

  • -elements — A grouping of elements to be mixed with #PCDATA inside a mixed content model will be named with a suffix “-elements”. For example, “%kwd-elements;” would be used in the model for the element <kwd>. All “-elements” overrides begin with an OR bar, so that a model may exclude all elements and be reduced to #PCDATA. For example:

    <!ENTITY % kwd-elements
                "| %emphasis.class; | %phrase-content.class; |
                 %subsup.class;"                          >
    

    
    Could be replaced by

    <!ENTITY % kwd-elements    " "                        >

• Attribute lists — Attribute lists for a particular element are named with the name of the element followed by the suffix “-atts”, so, for example, the attributes for the <abstract> element would be named “abstract-atts”. Such lists are not reused as frequently as they might be in many tag sets, to provide maximum flexibility. Attribute lists for different elements were rarely tied together. The parameter entities contain at least one complete line of an attribute list, excluding the ATTLIST Declaration.

  <!ENTITY % response-atts
              "%jats-common-atts;                                       
               response-type
                          CDATA              #IMPLIED
               specific-use
                          CDATA              #IMPLIED
               xml:lang   NMTOKEN            #IMPLIED"  >