Disclosure: Inera has been actively involved in the development of the ANSI/NISO JATS and STS standards, and Inera CEO Bruce Rosenblum is co-chair of the NISO STS Working Group. Inera has provided software solutions for some, but not all, of the standards organizations mentioned in this article.
We’ve received some queries in the past year about whether DITA or STS is a more appropriate XML model for markup of international, national, and consensus standards. In this post, we give a little background on each model and then discuss their suitability for standards.
What is DITA?
DITA (Darwin Information Typing Architecture or Document Information Typing Architecture) is “an XML architecture for designing, writing, managing, and publishing information.” The DITA standard is maintained by OASIS.
DITA is designed for publishing workflows that involve reusing the same text fragment—which DITA calls a “topic”—in many contexts. For example, DITA is ideal for vehicle owners’ manuals, since many different vehicles may use some of the same components. Each component is a different topic (which may be made up of sub-topics), and a master document is created for each vehicle by combining the appropriate topics.
What is STS?
STS (Standards Tag Suite), known formally as ANSI/NISO Z39.102-2017, describes an XML model for normative standards documents produced by standards organizations (international and national standards bodies, standards development organizations, consortia, and others). The STS standard is maintained by NISO.
Intended to provide a common format in which standards bodies, standards producing organizations, publishers, commercial vendors, and archives can publish and exchange standards documents, NISO STS is an extension of an earlier XML model, ISOSTS, developed for the International Organization for Standardization (ISO).
STS is based on the JATS (ANSI/NISO Z39.96, Journal Article Tag Suite) model and is part of the JATS family of DTDs, along with BITS (Book Interchange Tag Suite). STS became an ANSI standard in October 2017.
Why choose STS over DITA?
A more compatible document model
DITA is one of four public XML models for text documents that ISO evaluated when they began their full-text XML project in 2011. The other models were DocBook, JATS, and TEI. JATS rather than DITA was ultimately chosen as the model because
- DITA lacks a model for bibliographies and normative reference lists, which already existed in JATS;
- JATS already had specialized structures for complex document elements such as figure groups and figure permissions; and
- overall, the JATS model had more in common than DITA with the structure of full-text standards.
DITA is designed for publishing workflows that involve reusing the same text fragment or “topic”—such as the vehicle owners’ manuals example described above. By contrast, our experience has been that aside from terms and definitions or front-matter boilerplate text about rights, this kind of content reuse is rare or nonexistent in standards publishing.
DITA works best when the topics are small (e.g., sections of a document, not entire documents). Standards tend to have many heavily nested sections, so it’s often not clear which level of a section (level 1, level 2, level 3, etc.) makes the most effective unit of a DITA topic.
Standards frequently cite other sections within the same standard (e.g., text in section 6.3 that says “see Section 3.5.2”). In STS, these section links are easy to establish and maintain, because the entire STS document is in one XML file. In a DITA environment, by contrast, such links are difficult to set up and maintain; in two of the four DITA implementations for standards publishers that Inera has examined, cross-references were rendered as plain text rather than hyperlinks for this reason.
The following international and national standards bodies (NSBs) have adopted STS to date: ISO, IEC, CEN, BSI, DIN, DS, NEN, SN, AS, ASI, SFS, and SIS. Standards development organizations (SDOs) that have adopted STS or a model substantially the same as STS include ASTM, ASME, ASCE, IEEE, API, and SAE.
The critical mass of NSBs and SDOs that have already adopted STS suggests that STS will be more widely adopted in the future. That critical mass also makes it likely that other participants in the standards information and distribution chain (e.g., SWISS) will coalesce around STS and request STS XML from standards publishers. This means that a standards publisher adopting DITA would likely still need to deliver STS to other organizations, and perhaps take in STS from SDOs with whom they co-publish standards. In other words, one likely cost of not using STS in your workflow is a need to write transformations to convert your XML to and from STS.
Designed for interchange
Each of the DITA implementations for standards publication that we’re aware of has been built independently, meaning that any customizations to adapt DITA to the unique aspects of standards content were also done independently, and DITA XML from different standards publishers can’t easily be interchanged. By contrast, STS was designed from the start with interchange in mind, and the adoption of a single model by multiple publishers means that STS XML can easily be interchanged.
But what if we have other types of publications, too?
You’re not alone! And STS is still your best choice.
Many SDOs, including IEEE, ASME, and ASCE, publish journals as well as standards, and these organizations find it helpful to use the same core XML model for both. This approach allows them to reuse tools and technology, and it means that publishing teams and IT need to learn only one primary XML model, not two. Why? Because JATS is the XML standard in journal publishing, and STS is based on JATS, so that anyone who is familiar with one will immediately be familiar with the other. From a technical perspective, JATS and STS share a common set of modules, so users of both are guaranteed to have cross-familiar models.
We hope these reasons clarify why the standards community has coalesced around STS rather than DITA.
Need more information?