Skip to content

DTD Versions

Jump to bottom
Wendell Piez edited this page Apr 8, 2016 · 8 revisions

Supported DTD versions

As delivered, JATSKit declares bindings (only) to the following FPIs (formal public identifiers):

  • -//NLM//DTD JATS (Z39.96) Journal Publishing DTD with MathML3 v1.1 20151215//EN ('Blue 1.1')
  • -//NLM//DTD JATS (Z39.96) Journal Publishing DTD with OASIS Tables with MathML3 v1.1 20151215//EN (1.1 Blue with both table types)
  • -//NLM//DTD JATS (Z39.96) Article Authoring DTD with MathML3 v1.1 20151215//EN ('Orange 1.1' or 'Authoring')
  • -//NLM//DTD BITS Book Interchange DTD v2.0 20151225//EN ('BITS 2.0')
  • -//NLM//DTD BITS Book Interchange DTD with OASIS and XHTML Tables v2.0 20151225//EN ('BITS 2.0' with both table types)

XML documents with DOCTYPE declarations that include these Formal Public Identifiers will work in JATSKit. This does not mean that all tagging for anything will be supported, only that things should "just work" without further configuration.

Additionally, the framework provides templates for documents invoking three of these, the versions with OASIS tables (which are supported in the JATSKit stylesheets).

This list of supported document types excludes many common varieties of JATS and NLM, which nonetheless may work well with JATSKit. Notably, the MathML2 variants of the DTDs, as well as the "Green" DTDs, fall into this category, as does any older variant and many or most adaptatations of earlier NLM models.

An easy solution, for many projects, may be to upgrade your document(s) to one of the preferred types. This is often a good idea in any case, and it may be as easy to do as modifying the FPI in the DOCTYPE declaration. JATSKit includes 'XML refactoring' stylesheets that will (re)assign a document's FPI, which you can always run on any document. This won't convert the document's tagging (until you improve the XSLT to do that also) but it gives you a place to start making whatever adjustments are needed.

Converting data to the current DTDs is not always possible or practical given requirements or other dependencies; for a document set that is very stable you may wish to keep it in its current form. Fortunately, the JATSKit may also be extend to provide support for any DTD for which you have a complete set of files, along with a working catalog file that can resolve references to them. While its utilities may require adaptation or adjustment to the quirks of the document type (the 'local usage profile'), this is not less true for publishing systems running with the newer DTDs as well - that is, this is not a cost you will not undergo in any case. Accordingly, even users of older NLM-like DTDs may find JATSKit or parts of it to be useful.

Extending the JATSKit for other DTDs

To support "NLM Green" (the 'Archiving DTD'), other JATS 1.1, JATS 1.0, or older NLM variants including local variants ...

oXygen will associate the JATSKit framework with any document whose FPI matches one of several patterns given in the framework. If your documents do not conform to one of the known types, you can retrofit JATSKit to support your DTD. (See oXygen documentation for customizing frameworks in oXygen.) In particular, the framework Extend option is appealing since it can simply acquire logic and components from the base framework without forking it; however making and modifying a local copy also works. In either an extension or a copy, you can then amend and supplement the framework's CSS, XSLT and Schematron, to support local requirements whatever they happen to be.

So, for example, to extend JATSKit for the JATS 1.1 "Green" (Archiving) DTDs, create a new framework extending JATSKit, give it your own name, and under its Catalogs tab, add a path to the catalog-jats-v1-1-no-base.xml file in your copy of the Green DTD distribution (or to some other catalog that you have tested).

Then, under the Associations tab, add the appropriate FPI(s), such as -//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD with MathML3 v1.1 20151215//EN, that belong to the declared document type you wish to support.

Use any or all DTDs and FPIs you like. As long as your framework extends JATSKit, you will get its functionality as well as any customizations you also provide. (Of course, the JATSKit as delivered will not do anything or anything special with your Green data.)

Before binding it into the framework, you should test your catalog file externally (for example, by trying it in an oXygen project) to ensure that it works outside the framework. (Keep in mind that especially older catalog files may require some adjustment of internal paths in order to work in oXygen. Newer catalogs provided with JATS simply drop in, and serve as good models for emulation for this reason.)

Note that when you do this, you should also consider extending CSS and/or XSLT to handle elements and usages in your data that are not (and cannot be) provided in the general-use "80%" of functionalities provided by the framework. Most likely, any local project will need eventually to do this anyway, but if you are extending to cover new (and old) DTDs you almost certainly fall into this category.

Also note that in any oXygen installation, as either a Global or Project option, frameworks may be turned on and off (Options > Preferences > Document Type Associations) - which is sometimes helpful if not necessary when testing.

Clone this wiki locally