In spring 2020, the International Organization for Standardization (ISO) adopted NISO STS for their standards publications. We asked Serge Juillerat of ISO to tell us all about their experience!

Background: A standard for standards

ISOSTS (the ISO Standards Tag Set) was originally developed in 2011 for ISO, based on NISO JATS, and has since been widely adopted by national standards bodies (NSBs).

NISO STS (the Standards Tag Suite) was released in 2017 and officially adopted as ANSI/NISO Z39.102:2017. An official member of the JATS family, NISO STS is designed for use by both NSBs and standards development organizations (SDOs) and is fully backwards compatible with ISOSTS.

→ For more on differences and similarities between ISOSTS and NISO STS, see “Standards for Standards: ISOSTS and NISO STS Compared.”

Why shift from ISOSTS to NISO STS?

Once ISOSTS had been developed and implemented, it took a few years for the standards world to get used to the idea of structuring standards. In the mid-2010s, NISO contacted ISO to discuss creating a “standard for standards” based on ISOSTS, and the NISO STS standard was published in 2017.

Shifting to NISO STS was part of ISO’s plans for continuous improvement, with the goal of enabling and encouraging interchange and collaboration between SDOs.

No SDO is an island

While ISOSTS was “built on a little island,” in Serge’s words, shifting to NISO STS was not a project that could be tackled in isolation. Working with a sister organization, the International Electrotechnical Commission (IEC), ISO shared documentation, migration plan, and concerns with their members, to make sure that everyone was on the same page throughout the initial step of shifting to NISO STS. This approach has worked so well that they are now at the point of considering future enhancements!

Challenge and change

The primary impact of the shift to NISO STS was on metadata; however, since ISO members were using ISOSTS in their workflows, it was important to give them sufficient time to adapt. ISO therefore decided to provide each standards package in both ISOSTS and NISO STS versions for the first several months.

A second challenge involved ISO’s satellite applications. To head off potential issues, ISO deployed a complete refactoring of their projects database in late 2019, and since then has ensured that every new component is optimally integrated, including using NISO STS.

No matter how much testing is done, every IT update has its unplanned hiccups. When they began converting the NISO STS XML generated from and for ISO’s production tools to an ISOSTS XML package, in order to provide both to members, they discovered that a <uri> element is allowed within an <std> element in NISO STS, but not in ISOSTS. Fortunately, this wasn’t a critical issue, and the production chain was affected only briefly; ISO’s workflow is now producing both ISOSTS and NISO STS packages for new standards.

Streamlining standards with eXtyles STS

With ISO adopting NISO STS, it makes sense for NSBs as well as SDOs to follow their lead! To make this shift as straightforward as possible, the NISO STS Working Group (now a NISO Standing Committee) designed NISO STS to be fully backwards compatible with ISOSTS.

For NSBs and SDOs looking to produce high-quality NISO STS XML in-house, Inera’s eXtyles STS provides an immediate and cost-effective solution. We can also customize or expand eXtyles STS to meet the unique needs of individual organizations! Contact us to discuss how eXtyles STS can help you streamline your standards workflow.