Changing JATS to enable tagging an article in more than one language added a new element, changed some element models, added many new attributes, and deprecated several elements. Why? Changing, or perhaps, more completely understood requirements.

When the predecessor to JATS, the NLM DTD, was created, user experience was with mono-lingual articles that had metadata in the same language as the article. An occasional article might contain phrases, quotations, examples, or boxed text in other languages, but the article as a whole was in one language. Similarly, the metadata for the article was in the language of the article. Translations of some key portions of the metadata, such as the article title or abstract, might be provided for the convenience of users in other language communities, but these were considered translations of the primary single-language metadata.

Over time, it became clear that JATS modeling of a single language, with a few translated metadata elements, was based on some faulty assumptions. The JATS Standing Committee learned that:

• There are articles that have much, or all, of their content in two or more languages.
• There can be more than one “original” language, both for article content and in article metadata. The assumption that any language(s) in addition to a primary language are “translations” is false.
• Whether a version of some portion of text or metadata is a “translation” is only one of many things we might know about that content, not a primary defining aspect of the content.

In modifying JATS to enable better modeling of multi-language materials, we have added the multi-lang attributes (see Multiple Languages/scripts), an extension mechanism to identify where the same content occurs in multiple languages. Also as part of the multi-language changes, we have deprecated the following elements:

<trans-abstract>, <trans-source>, <trans-subtitle>, <trans-title>, and <trans-title-group>

Instead of using any of the elements above named “trans-xxx” (<trans-abstract>, <trans-source>, etc.), the appropriate structure (<abstract>, <source>, etc.) should be repeated as many times as needed, with each repetition identified by language. Any translations can be explicitly identified.

Similarly, we have learned that the <history> element (which contains dates such as an article’s received-date and accepted-date) does not enable the recording of all the metadata users want to record concerning the important dates in the life of an article. Therefore, JATS has added <event>, which better models article development and life-cycle. In hopes that users will use the <event> element instead of <history>, JATS has deprecated <history>. While some article life-cycle events can be effectively recorded as a bare <date> within <history>, many cannot, and the Standing Committee believes that users will be better served if there is the opportunity for additional metadata about a date/event, and if all of this information is in the same place (<event>).

The same type of evolution can happen with attributes. The original JATS @pub-type attribute was intended to provide supporting information for <pub-date>s. As users requested more and more values be added to the suggested value list for @pub-type, it became clear that users were trying to record several types of information using the @pub-type attribute, and that there were times when more than one value was appropriate for the same element. So the @pub-type attribute was deprecated and replaced by two attributes: @date-type and @publication-format.