Journal Publishing DTD Version 2.2

Version 2.2 was a minor dot release that added small changes (typically new attribute values) that were requested by NLM and other users based on operational concerns. The three DTDs for describing journal articles were all changed; the book, historical book, and book collection DTDs were not modified in this release.

Changes to the Entire Suite

Version Number and Date—The version number for all changed Suite modules, the Publishing DTD (Blue), the Archiving DTD (Green), and the Article Authoring (pumpkin) DTD was set to “v2.2 20060430”. This change was made in the initial comments for a module, in the formal public identifier in the module, in the Suite Module of Modules or the DTDs themselves where the modules were called, and in the XML and SOCAT catalogs.

That change was made in the following Suite modules:

articlemeta.ent
common.ent
default-classes.ent
display.ent
modules.ent
para.ent
references.ent
section.ent

Versioning Note: Only modules that have changed are marked as version 2.2. All modules change version numbers at a numbered release, but, for a dot release, a module that has not changed (for example %phrase.ent;) retains its previous version number.

Suite Element Changes

Long Description—Corrected the model for <long-desc> by adding an asterisk to the #PCDATA model.
Preformat Model—Added the Parameter Entity %phrase.class; to the content model for the <preformat> element to allow use of <named-content> inside <preformat>.
Price—Added new element <price> and made a new class for it %price.class; so that it can be added selectively to elements, initially to the <product> element. (Note: The Authoring DTD [Pumpkin] has overridden the base modules and so does not see this change.)
Section (Note: The Authoring DTD [Pumpkin] has overridden the base modules and so does not see these changes.)
- Section Metadata—Added new element <sec-meta> to the start of the content models for section (%sec-model;) and section optional title model (%sec-opt-title-model;). There are sections that are authored independently, even in journal articles, and this allows additional metadata for such sections, allowing contributors to be listed at the section level.
- Section Meta Model—Added New Parameter Entity %sec-meta-model; to hold the content of the new element.
Signature Block—Added new element <sig-block>. A <sig-block> may be located at the end of the <body> in journal articles.(Note: The Authoring DTD [Pumpkin] has overridden the base modules and so does not see this change.) This element will hold any graphic signatures, text describing the contributors, etc. A <sig-block> contains text plus face markup and the new element <sig>, which holds the information for a single contributor. A new default class %sig.class; was created to hold the Signature <sig>.
Verse Group—Added new optional <title> and <subtitle> elements to the beginning of <verse-group>, through the %verse-group-model; Parameter Entity.
Paragraph Attribute Parameter Entities — Added new Parameter Entities %caption-model; and %inline-graphic-model; to hold the complete content models for their respective elements so that the models can be more easily over-ridden.

Suite Attribute Changes

Related Article Type—Added a new suggested value “partial-retraction” to the “related-article-type” attribute of <related-article>.
Paragraph Attribute Parameter Entity—Added the new Parameter Entity %p-atts; to hold the attribute list for a Paragraph <p> so that it can be more easily over-ridden.
Person Group Type—Added "director" to list of suggested values for this CDATA attribute.

Specific Publishing DTD Changes (Blue)

In addition to the full Suite changes listed in Changes to the Entire Suite, the following changes were made to the Publishing DTD and its DTD-specific modules. Each changed module had its formal public identifier and comment date changed, which was reflected in the two catalog files and the module calls in the DTD. Modules changed include:

journalpublishing.dtd
journalpubcustom-models.ent
journalpubcustom-modules.ent

Publishing DTD Element Changes

Preformat Model—Added %phrase.class; to the model of <preformat>, mirroring what was done in the base Suite, to allow use of <named-content> inside <preformat>.
Publisher Location—Allowed <email>, <uri>, and <ext-link> inside <publisher-loc>; changed through the Parameter Entity %publisher-loc-elements;.
Section—Made all the changes needed to bring Blue along with the Suite and in addition, modified the use of <label>:
- Label—Added optional <label> element to the start of the content models for section (%sec-model;) and section optional title model (%sec-opt-title-model;). The change is to accommodate use of the Blue DTD for articles that have already been published.
- Section Metadata—Added new element <sec-meta> to the start of the content models for section (%sec-model;) and section optional title model (%sec-opt-title-model;). There are sections that are authored independently, even in journal articles, and this allows additional metadata for such sections, allowing contributors to be listed at the section level.
Signature Block—Added <sig-block> to the end of article <body>. Used Parameter Entity over-rides to modify the models of both <sig-block> (using %sig-block-elements;) and <sig> (using %sig-elements;) to include all phrase-level elements in the textual mix.
Sub-article and Response—Added a new element <front-stub> as an alternative to the typical <front> metadata inside a <sub-article>, so that not as much metadata is replicated between the article and sub-article. For example, a <sub-article> that uses a <front-stub> will inherit all of its <journal-meta> from the journal meta of the associated article. Also changed the model for %article-short-model;, which is used only for <response> to also use <front-stub>.

Publishing DTD Attribute Changes

Article Types Values—Added new values to “article-types” (which is used on both the element <article> and the element <sub-article>):
- collection
- dissertation
- rapid-communication
- partial-retraction
- reprint
- review-article
- translation
ID Attributes—Added to the elements <sub-article> and <response> through their respective attribute Parameter Entities.
Person Group Type—Added “director” to list of suggested values for this CDATA attribute, mirroring what was done in the base Suite.
Response Type Attribute—Changed the comment on this attribute to reflect actual usage. First, the use of the attribute is no longer discouraged. Second, there are a few suggested values.

How to Build A New Custom DTD

The Concept

The basic idea for a new DTD is that all lower-level elements (paragraphs, lists, figures, etc.) will be defined in modules, either the modules of the Suite or in new DTD-specific modules, not in the DTD itself. The DTD will be fairly short and include only definitions of the topmost element(s), at least the document element and maybe its children.

Modules are defined using External Parameter Entities in with the Suite Module of Modules or in the DTD-specific Module of Modules. Modules are called (referenced) in the DTD, in the order needed to define the Parameter Entities in sequence.

Version 2.1 of this Journal Publishing DTD was written as an example of the new best-practice customization technique. A new DTD that follows this plan will probably consist of the following modules:

A DTD module to define the top-level elements (e.g., yournew.dtd) ;
A DTD-specific definition of element classes to add new classes and over-ride the default classes; (for example, %yournew-classes.ent;)
A DTD-specific definition of element mixes to add new mixes and over-ride the default mixes; (for example, %yournew-mixes.ent;);
A DTD-specific module of content model over-rides (for example, %yournew-models.ent;).
A DTD-specific Module of Modules to name the non-Suite modules in the DTD (for example, %yournew-modules.ent;)
DTD-specific modules to hold new types of element declarations (e.g., %taxonomic-key.ent; or %help-topic-meta.ent;); and
All or most of the modules in the base Suite.

Example

To show the process, here is a series of instructions for making a new DTD, illustrated by showing how Journal Publishing DTD was created from the modules of the whole Suite.

Modules —Write a new DTD-specific Module of Modules, which defines all new customization modules the DTD needs. (As an example, the Publishing DTD created the module %pubcustom-modules.ent;, which contains the definitions of the class-over-ride module %journalpubcustom-classes.ent;, the mix-over-ride module %journalpubcustom-mixes.ent;, and the models-and-atttributes-over-ride module %journalpubcustom-models.ent;.)
Class Over-rides —Write a DTD-specific class-over-ride module, defining any over-rides to the Suite classes. These classes were defined in the default classes module. (As an example, the Publishing DTD created the module %journalpubcustom-classes.ent;, that redefines several classes to be more restricted than in the base Suite, for example, %date.class; is defined as just the element date although the Base Suite also allows the element string-date.)
Mix Over-rides —Write a DTD-specific mix-over-ride module, defining any over-rides to the Suite mixes. These mixes were defined in the default mixes module. (As an example, the Publishing DTD created the module %journalpubcustom-mixes.ent;, in which the mix %just-rendition; is changed form a group of elements to a null string, to make all content models that use this mix into plain #PCDATA.)
Model Over-rides —Create a DTD-specific content-model-over-ride module, defining any over-rides to the content models and attribute lists for the DTD Suite. (As an example, the Publishing DTD created the module %journalpubcustom-models.ent;, in which the model for the element <abstract> is greatly reduced.
New Elements —Write any new element modules needed. These will define any new block-level or phrase-level elements. (As an example, the Publishing DTD added one new element to Suite, <nlm-citation>, which is also in defined in a module of its own.)
DTD Module —Use the modules just described in the construction of a new DTD module. Within that DTD module, the following steps need to happen in the following order:
- Use an External Parameter Entity Declaration to name and then call the DTD-specific modules of modules (For the Publishing DTD, the module %journalpubcustom-modules.ent;.)
- Use an External Parameter Entity Declaration to name and then call the DTD Suite modules of modules, which names all the potential modules. (For the Publishing DTD, the module %modules.ent;.);
- Use an External Parameter Entity reference to call the DTD-specific class over-rides (For the Publishing DTD, the module %journalpubcustom-classes.ent;.);
- Use an External Parameter Entity reference to call the DTD Suite default classes (For the Publishing DTD, the module %default-classes.ent;.);
- Use an External Parameter Entity reference to call the DTD-specific mix over-rides (For the Publishing DTD, the module %journalpubcustom-mixes.ent;.);
- Use an External Parameter Entity reference to call the DTD Suite default mixes (For the Publishing DTD, the module %default-mixes.ent;.);
- Use an External Parameter Entity reference to call the DTD-specific content models and attribute list over-rides (For the Publishing DTD, the module %journalpubcustom-models.ent;.);
- Use an External Parameter Entity reference to call in the standard Common Module (%common.ent;) that defines elements and attributes so common they are used by many modules.
- Select, from the Module to Name the Modules, those modules which contain the elements needed for the DTD (for instance, selecting lists and not selecting math elements) and calling in each of the modules needed; (The Archive DTD calls these in alphabetical order, since the order does not matter.)
- Define the document element and any other unique elements and entities needed for this DTD. (For example, the Publishing DTD declares only six elements. In most cases, these high-level elements have the same content models they do in the Archiving DTD, but each DTD needs to define its own top elements. The elements defined include: <article> [the top-level element] and its components: <front>, <body>, <back>, <sub-article>, and <response>.)

Changes to the Base Suite

The section below lists the changes to the base Suite which is used to build the Publishing DTD. Most of the old class modules (%list.ent;, %references.ent;, etc.) look much the way they used to, although the default classes and mixes have been moved out of the individual modules into the new class-specific and mix-specific modules. A few elements have moved from one module to another, particularly to the common module, as their usage increased. There are more Parameter Entities to make it possible to over-ride even more content models and attribute lists.

Global changes include:

Changed the version number of every module in both the base Suite and the Publishing DTD to reflect a Version of 2.1 and a date of 08/30/2004;
Changed the formal public identifier of each module to that version and date, and
Changed the “dtd-version” in all the DTDs to #FIXED attribute to “2.1”.

Rationale and Philosophy for Changes

Regularizing Versus Strict Preservation

Two base DTDs were originally constructed from the Journal Archiving and Interchange DTD Suite: the Journal Archiving and Interchange DTD (nicknamed Green) and the Journal Publishing DTD (nicknamed Blue). The Publishing Blue DTD was to be prescriptive, to facilitate authoring. The Archiving Green DTD was to be moderately loose, to serve as a basis for interchange and repositories.

An understated, but very real, goal of the Archiving DTD was regularization of the archive itself. At the time of conversion from a publisher’s original DTD to the Journal Archiving DTD, a number of changes would be made to make all articles more alike. An alternate goal for the DTD might have been (but was not) preservation of a publisher’s content as exactly as possible. (As a small illustration of the difference such a design makes in a DTD, consider the ”article-type” attribute values for the <article> element. An archive-regularizing DTD would make this a closed list and would change the “research article” of one publisher, the “research paper” of another, and the “letter” of a journal such as Nature into a single value during conversion. In contrast, a preservationist approach might make this attribute a CDATA open list, to capture whatever the publisher had called the article.)

Three DTDs From Two

Many requests from the AIT Working Group were from preservationists asking that the Archiving DTD loosen up to allow representing a wider range of publishers’ input. As the Archiving DTD loosened, archives wanting to regularize the archive migrated to the Publishing Blue DTD. They found it a little too tight for their needs and requested loosening changes. At the same time, vendors wanting to establish an authoring environment felt that Blue needed tightening, to make it easier for authors. The solution has been to create three base DTDs from the Suite:

Journal Archiving (Green) DTD	a preservationist archival DTD (the current Archiving DTD, made even more flexible and non-enforcing
Journal Publishing (Blue) DTD	an archive regularization and interchange DTD (the current Publishing DTD loosened as necessary)
Authoring DTD	a tight, small subset that concentrates on best practice as an aid to authoring

Remodularization

New Customization Requirements

When the Base Suite was written, it was assumed that the major use of the Suite would be to make entirely new and distinct DTDs, so the modularization was done to make that convenient. All customization was concentrated in one module, and Parameter Entities were defined just before they were used. But very few original DTDs have been developed in the last year and a half. New DTDs are being created from the Suite not by DTD development but by DTD modification. Most organizations seem to want most of their models to be the same as the Suite, plus a few changes. People modifying the DTD have also requested more guidance in how to modify it properly. In light of actual Suite usage, we have observed the following DTD Suite customization requirements.

The published modules should act as a more complete model of how to build a modified DTD from the Suite. The modularization of the base Archiving and Publishing DTDs should provide a sample of best practice for making and modularizing new DTDs.
Customization modules should be small and list only what has changed from the Suite defaults.
It should be relatively easy to compare new DTDs developed from the Suite.
Parameter Entities that are not over-ridden by a new DTD should not need to be declared by it (so that everything in the customization module is a change from the base).
It is still useful to developers to have all the element classes listed in one place, grouped functionally (in functions that match the Suite modules) so that it is easy to see what in the Suite is designed to be changed easily and how to change it.

New Class and Mix Modules

Best practice for how to make a new DTD from the Suite has changed, and the Suite has been remodularized for the new style. Two Suite modules have been created to hold the declarations that were formerly part of each DTD’s customization. In place of the former single customization module, there are smaller function-specific modules:

Default definition of element classes (the module %default-classes.ent;); and
Default definition of element mixes (the module %default-mixes.ent;).

All the default class Parameter Entities have been removed from the individual modules and placed into the new classing module.

Modeling Conventions and PE Naming

These DTDs and 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. Version 2.1 of the Journal Publishing DTD (and the entire Verison 2.1 Archiving and Interchange 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. (Mixes should never contain element names directly.) Mix names have no set suffix. Some mixes are inline to be intermingled with #PCDATA and some mixes grouping of block-level elements. All inline mixes begin with an OR bar. For example:
```
<!ENTITY % rendition-plus
"| %emphasis.class;  | %subsup.class;" >
```
Content —Content models and content model over-rides use mixes and classes for all OR groups. Only sequences are made up of element names directly. Content models over-rides are of two types, defined separately to preserve the mixed-content or element- content nature of the models as an aid to interchange.
- -models —The over-ride of a complete content model will be named with a suffix “-model”. The over-ride includes the entire content model,including the enclosing parentheses, for example:
```
<!ENTITY % kwd-group-model
"(title?, (%kwd.class; | %x.class;)+ )" >
```
- -elements —A grouping of elements to be mixed with #PCDATA inside a content model will be named with a suffix “-elements”. For example “access-date-elements” would be used in the models for the elements <access-date>. All “-elements” over-rides begin with an OR bar, so that a model may exclude all elements and be reduced to #PCDATA . For example:
```
<!ENTITY % access-date-elements
"| %date-parts.class; | %x.class;" >
```
  Could be replaced by
```
<!ENTITY % access-date-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 DTDs, 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, not including the ATTLIST Declaration.
```
<!ENTITY % rendition-plus
"| %emphasis.class;  | %subsup.class;" >
```

4.4 Base Additions and Changes

New Classes

The ideal situation in a DTD is that mix OR-groups and OR-groups within content models do not name elements; they name classes. This makes DTD-customization easier and makes maintenance over time significantly easier. A few new classes were created to facilitate this:

%app.class;
%back.class;
%caption.class;
%corresp.class;
%date.class;
%date-parts.class;
%def.class; (used in both <def-item> and <abbrev>
%degree.class;
%fig-display.class;
%fn-link.class;
%front.class;
%front-back.class;
%id.class;
%just-base-display.class;
%just-para.class; (used in, for example, <author-comment>, <bio>, <def>, <caption>, <statement>, <fig>),
%just-table.class;
%kwd.class;
%name.class;
%ref-list.class;
%sec-back.class;
%table-foot.class; and
%tbody.class;.

Content models were rewritten to use the newly created classes. This rewriting did not lead to DTD changes, except in the following elements:

Modified %doc-back-matter-mix; (formerly named %doc-back-matter-elements;) to correct the historical error that had this Parameter Entity calling a mix (%sec-level;) and not a class (%sec.class;). Since there was nothing in %sec-level; but <sec>, this has no effect on the Publishing DTD as delivered, but it may change existing customizations.
%front-matter-model; rewritten to use new class Parameter Entity %front-back.class; and to use %list.class; rather than just <def-list>. This widens the model of <front-matter> by adding <list>.
Paragraph-related changes:
- %inside-para; was renamed %p-elements;
- Deleted %para.class; In the definition of the Paragraph <p> element, its place will be taken by %p-elements; .In other mixes, such as %para-level;, %para.class; was replaced by the combination of %just-para.class; and %rest-of-para.class; . (No DTD Changes)
- Inside the content model for Paragraph <p>, %rest-of-para.class; was renamed %p-elements;. The content model for <named=content> and the model for %p-elements; itself still use %rest-of-para.class;.
In %named-content-elements;, replaced the Parameter Entity %emphasized-text; with its constituent classes
In %copyright-statement-elements;, replaced the mix %rendition-plus; with its constituent classes
In %citation-elements;, replaced the mix %simple-text; with its constituent classes. This causes the apparent, but not real, deletion of %address-link.class;. These links are also in %references.class; so there was not DTD change.)

Link Classes

The link classes were reorganized to make future modification easier. Three classes were deleted; new link classes were added for a total of four, and everywhere the link classes were used was modified as follows:

All occurrences of %ext-links.class; were replaced with the new class %address-links.class;.
All occurrences of %link.class; were replaced with some combination of the new link classes named below.

These were not usually DTD changes, just parameterization changes.

The following link-related classes were deleted:

%link.class;
%inpara-address;
%ext-links.class;

The new link classes are:

%address-link.class; (external links used in addresses)
%fn-link.class; (footnote alone)
%simple-link.class; (the internal links, just as it used to be)
%article-link.class; (links for journal articles)

Specific changes this encompassed include:

Replaced the link PEs in %emphasized-text;, %inside-cell;, %p-elements;, %product-elements;, %simple-phrase;
In %aff-elements;, replaced %link.class; with %address-link.class;, %simple-link.class;, %article-link.class; (directly in the Suite base module and via the use of %all-phrase; in the Archiving customization) (No DTD Change)
In <author-notes>, “(corresp | fn)+” was replaced with the %fn-link.class; and the new class %corresp.class;
In %collab-elements;, replaced %ext-links.class; with %address-link.class; and deleted %inpara-address; (directly in the Suite base module and via the use of %all-phrase; in the Archiving customization) (No DTD Change)
In %copyright-statement-elements;, replaced %inpara-address; with %address-link.class; (directly in the Suite base module and via the use of %all-phrase; in the Archiving customization)
<email> is considered to be just another type of external link, as <ext-link> is, so it was added to: %collab-elements; and %copyright-statement-elements;.
In %inside-para; (which had been modified and renamed %p-elements;) (No DTD change since %address-link.class; covers it.), deleted the PE %inpara-address;
In %named-content-elements;, replaced %link.class; with %address-link.class;, %article-link.class;, and %simple-link.class; (directly in the Suite base module and via the use of %all-phrase; in the Archiving customization) (No DTD Change)(No DTD Change)
In <related-article>, deleted %ext-links.class; because %references.class; has the needed links. (No DTD Change)

Rename Existing Parameter Entities

In order to make customization and maintenance easier, the names of several existing Parameter Entities were changed to bring them in line with the naming practices. This entailed changing the PE declaration and every mix or context model that used the PE.

%address-elements; ==> to %address.class;
%author-notes-elements; ==> %author-notes-model;
%block-math; ==> %block-math.class;
%citation-model; ==> %citation-elements;
%contrib-info; ==> %contrib-info.class;
%copyright-statement-model; ==> %copyright-statement-elements;
%def-item-elements; ==> %def-item-model;
%display-back-matter; ==> %display-back-matter.class;
%doc-back-matter-elements; ==> %doc-back-matter-mix;
%inline-math; ==> %inline-math.class;
%list-item-elements; ==> %list-item-model;
%related-article-model; ==> %related-article-elements;
%sec-back-matter-elements; ==> %sec-back-matter-mix;

Inline Mix OR-Bars

INLINE MIX OR-BAR — All inline mixes begin with an OR bar. While not strictly conformant, all modern XML parsers tested allow this variant. This technique allows the PE to be set to the null string, cancelling out any element inclusions and leaving a model of #PCDATA. This could also have been accomplished by over-riding the entire content model with a PE. The disadvantage of that method is that it makes it very easy to change mixed-content models to block-level element-content models. Since that is a major barrier to interchange, keeping the level the same is the one area where this DTD attempts to enforce consistency.

Changed the following inline-mix Parameter Entities to use the OR-bar-first mechanism. This requires changing not only the Parameter Entity to add the OR-bar, but changing all content models that use the entity to remove the OR bar: %all-phrase;, %emphasized-text;, %inside-para; (Now renamed %p-elements;and used only inside the Paragraph element <p>), %just-rendition;, %preformat-elements;, %related-article-elements;, %rendition-plus;, %simple-phrase;, %simple-text;, and all the Parameter Entities with the suffix “-elements”, if they did not already start that way.

Mixed Content (`-elements`)

Changed nearly all models containing only data characters (i.e., #PCDATA models) to be over-ridden by a Parameter Entities suffixed “-elements” so that there is the potential for mixed content. The only purely #PCDATA elements left are

Various identifiers (such as <article-id>, <pub-id>, and <isbn>);
Date elements (such as <day>, <month>, <copyright-year>, and <year>);
Page number information (such as <fpage>, <lpage>, and <page-range>);
<Elocation-id>;
<country>;
<glyph-data>; and
The text alternative element <alt-text>.

Complete Content Models (`-model`)

Made the following new Parameter Entities to allow the models to be over-ridden:%bio-model;, %contrib-model;, %def-model;, %disp-formula-model;, %fn-group-model;,%fn-model; , %history-model;, %inline-formula-model;, %kwd-group-model;, %person-group-model;, %preformat-model;, and %verse-group-model;.
Complete Models. All model over-rides will include enclosing parenthesis, so that model can be replaced by EMPTY or ANY. Thus, added parentheses to the Parameter Entity and removed them from the Element Declaration for the following: %abstract-model;, %ack-model;, %app-model;, %app-group-model;, %array-model;, %article-full-model;, %article-meta-model;, %article-short-model;, %author-notes-model;, %author-comment-model;, %back-model;, %body-model;, %boxed-text-model;, %chem-struct-wrapper-model;, %contrib-group-model;, %contrib-model;, %counts-model;, %date-model;, %def-item-model;, %def-list-model;, %disp-formula-model;, %disp-quote-model;, %fig-group-model;, %fig-model;, %fn-group-model;, %fn-model;, %front-model;, %gloss-group-model;, %glossary-model;, %inline-formula-model;, %journal-meta-model;, %kwd-group-model;, %list-model;, %list-item-model;, %note-model;, %preformat-model;, %ref-list-model;, %ref-model;, %sec-model;, %sec-opt-title-model;, %statement-model;, %table-wrap-model;, %table-wrap-group-model;, %table-wrap-foot-model; ,%title-group-model;, and %trans-abstract-model;.
To make the DTDs more flexible and allow additional over-riding, the following new PEs were added:
- %access-date-elements;
- %chem-struct-elements;
- %copyright-statement-elements;
- %degrees-elements;
- %display-formula-elements; and %display-formula-model;.
- %edition-elements;
- %etal-elements;
- %ext-link-elements;
- %fax-elements;
- %font-elements;
- %given-names-elements;
- %gov-elements;
- %history-model;
- %issn-elements;
- %issue-elements;
- %issue-title-elements;
- %just-para.class
- %kwd-group-model;
- %label-elements;
- %long-desc-elements;
- %on-behalf-of-elements;
- %p-elements;
- %patent-elements;
- %phone-elements;
- %prefix-elements;
- %publisher-name-elements;
- %publisher-loc-elements;
- %role-elements;
- %self-uri-elements;
- %series-text-elements;
- %series-title-elements;
- %std-elements;
- %string-date-elements;
- %string-name-elements;
- %suffix-elements;
- %surname-elements;
- %time-stamp-elements;
- %uri-elements;
- %verse-line-elements;
- %volume-elements; and
- %volume-id-elements;.

Model Over-rides Permitted

New attribute Parameter Entities were added as well:

%article-id-atts; for <article-id>
%date-atts; for <date>
%object-id-atts; and “object-id-type”
%pub-date-atts; for <pub-date>
%pub-id-atts; for <pub-id>
%sub-article-atts; for <sub-article>
%volume-id-atts; for <volume-id>