JATS Bundle

Download the core JATS bundle from the Sourceforge project page. Just click the big green "Download" button.

To use it, unzip it to any directory on your filesystem, and point your XML toolset to the root catalog.xml file. For example, To set up oXygen to use this catalog file, so that you can validate instance documents against any of the JATS DTDs, select "Options" → "Preferences". Then, in the tree on the left, "XML" -> "XML Catalog". Then add the main catalog.xml file from the jatspacks directory where you unzipped the bundle.

More information, as well as instructions on how to use the included test utility, are in the README.txt file in the download bundle.

What you get

This bundle includes the DTDs for each of the following, all conveniently packaged into one Zip file.

NLM JATS

NISO Z39.96 201x, Draft Standard, NISO JATS version 0.4.

The goal of this bundle is to make it very easy to set up an XML system that can recognize and use any of the various official versions of the JATS.

The NLM provides each one of the above flavors/versions of JATS as a separate downloadable Zip file (NLM JATS from here and NISO JATS from here). So, to set up a system that supports all of them requires that the user undergo a tedious process of downloading and extracting almost thirty Zip files, and then reconciling the OASIS catalog files that come with them.

Also, there is considerable overlap and redundancy among the Zip files that you get from NLM. Each DTD version on the NLM FTP site is downloadable as a single Zip file, which includes all of the files required for that version, including all the library and core files that the version depends on. This is suitable for someone who is only interested in downloading and playing with one or two different versions. Unfortunately, however, this method of distribution makes it difficult to implement a single system that's capable of processing instance documents that conform to any of the many different flavors and versions of JATS.

One problem is that there are a lot of duplicate files, and there are overlapping OASIS catalog files that each try to resolve a given public identifier to different instances of the files. Often, the files are different. If the same public identifier is used in multiple catalog files on one system, and point to document instances which are not identical, it is difficult and tedious for someone configuring the system to sort out whether the differences are substantive, and if so, which is the correct instance.

The JATS Bundle eliminates this redundancy, factors shared modules out into a core package, cleans up some ambiguities and inconsistencies, and fixes a few arcane and minor (but genuine) problems.

Furthermore, OASIS catalog files are provided that unambigously resolve all of the public identifiers. These catalog files are fully relocatable, so you can install the bundle to any location on your system without any extra work (this is another improvement over the NLM distributions). A top-level catalog file is provided that hierarchically includes all of the others.

So, all that is needed to set up a system to understand all of these JATS flavors and versions is to unzip the bundle, and then point your XML toolset to the top-level OASIS catalog file.

In addition to the core DTDs and OASIS catalog files, the bundle includes sample instance documents for each of the top-level DTDs. An automatic test script (written in Perl, in the jatspacks/test directory) is included that checks that each of these sample documents validates against the DTDs in the bundle, both with and without the use of the catalog files.

Finally, to bring these into alignment with the JATSPack specification, a package descripter file for each of the main flavors/versions has added. This file is named 'expath-pkg.xml', and resides in the root directory of every individual package directory. The bundle is "jatspan-ready", meaning that it should be the basis for a local jatspan repository, when that is eventually deployed, as described in the Balisage paper.

What you don't get

This bundle only includes the components described above, and does not (yet) include any of the Relax NG or XSD versions of the schema, or the documentation.

Are these the same as the NLM distributions?

If the question is, "Are the data models described by these DTDs exactly the same as those from the NLM?", then the answer is "Yes!". Unless I have inadvertently overlooked something, or introduced a bug, then any document that validates to an NLM distribution of the DTD will validate to the JATSPAN distribution of the same version, and any document that is invalid according to NLM will be invalid according to JATSPAN.

They are also identical in most other respects. The implementation was not changed in terms of which module files (.dtd and .ent) make up any given DTD. All the existing modularity, and layering of parameter entity definitions, is completely preserved.

The actual physical differences in the files were kept to a minimum, and are related to getting all the different versions and flavors of the DTDs to coexist together unambiguously on one system. These include eliminating redundant copies of files, moving shared files into different directories, and fixing the relative system-id links between files that refer to each other, so that these references don't break. There was also work done to clean up discrepencies among the versions, and fixing a few problems.

Note that I am in the process of making a detailed list of all of the specific changes that were made, and I will put it here as soon as it is finished. I would hope that before anyone suggests that this packaged distribution should not be used, because it is different, that they would first look over the differences, and let me know if they think there would have been a better way to accomplish the goal of having all these DTDs cohabitate nicely together in a robust and predictable way.

I am committed to making sure that this bundle does provide a completely faithful package of the JATS DTDs. I have done extensive testing to ensure that this is the case. If by some small chance some incompatibility has snuck in, please tell me about it, and I will correct it immediately!