Standardizing Standards 1: Introducing NISO STS


CHANDI PERERA: Hello. Welcome to the Standardizing Standards webinar.

This is a webinar series presented by Typefi and Inera. It’s the first webinar in the series and we’re going to be introducing NISO STS.

My name is Chandi Perera, I’m the CEO of Typefi Systems. Typefi Systems is an Australian company, headquartered in Australia with customers in 35 countries. We have offices in Australia, US, UK, Netherlands, and Sri Lanka, and we have about 10,000 users around the world.

We produce a single-source publishing platform that fully integrates print, online, and mobile. We take single-source content in any format—specifically for this webinar in NISO STS format—and then output it to all 30 different formats.

We leverage industry standards for fast implementations and ease of use.

And now I want to introduce you to my co-presenter, Bruce Rosenblum, CEO of Inera Incorporated. Bruce has been working in the standards space for a long time but he was also the Co-Chair of the NISO STS Standards Committee.

BRUCE ROSENBLUM: Thank you very much, Chandi. I’m Bruce Rosenblum, CEO of Inera Incorporated, and also Co-Chair of the NISO STS Working Group, a working group that I’ve been honored to co-chair with Rob Wheeler of ASME for the past two years. And it’s that working group that’s created the NISO STS standard that you’ll be hearing more about today.

Inera is located just outside of Boston in Belmont, Massachusetts. We have customers, however, in 27 countries, so we really have a global focus, and our offices are in the US, UK, and Canada.

Inera serves thousands of publications and hundreds of publishers worldwide every single day with our eXtyles and Edifix software.

What we do is provide a suite of editorial and XML tools for Microsoft Word called eXtyles, and we’ve just introduced our brand new product, eXtyles STS, which is a special version of eXtyles for standards publishers.

eXtyles allows publishers to automate the most time-consuming aspects of document cleanup, formatting, and editing, and at the end of doing all of that, they’re able to produce high quality XML—such as XML according to NISO STS—at the click of a mouse.

And like Typefi, eXtyles leverages industry standards, wherever possible, for fast implementation, ease of use and, of course, to have a standardized workflow.

CHANDI PERERA: Typefi and Inera have many joint customers in the standards space. We started working with ISO in 2010, in the initial implementation of what has become STS. We have joint customers like BSI and Standards Australia who are national standards bodies, and we also work with many standards development organizations, like IEEE.

In this webinar series, we are going to be covering how to implement either an ISOSTS workflow, or a NISO STS workflow.

So in this webinar, we’re going to tell you a little bit about STS, a brief history, the difference between ISOSTS and NISO STS, and why we should be looking at implementing an XML—and specifically an STS­—workflow for your standards publishing.

In the second webinar, Bruce is going to be talking about where to introduce your XML process. What are the different options? How do you convert content to XML? How do you publish it? What are the different options available for doing all of that?

In the third webinar, we are going to be focusing very specifically on covering how to convert Microsoft Word documents to STS, because we understand most standards bodies and their committees use Microsoft Word as their authoring platform. And you’re going to see a quick demonstration of the Inera product set.

In the fourth webinar, we are going to be talking about how to get your STS—which you have now converted from your Microsoft Word—into your publication in multiple distributable formats, be it PDF, EPUB, or HTML. We’re also going to be seeing a quick demonstration of Typefi in webinar number four.

Standards work with adoptions, so quite a few national standards bodies, or all the standards bodies, will often adopt standards created by other standards bodies. So adoptions is a big and important part of publishing standards.

And webinar number five is going to be focused on how adoptions work in an STS workflow; how an XML workflow will simplify and ease your adoptions process.

Webinar number six is going to be focused on what is now possible after you have adopted STS. Right now you might be publishing from Microsoft Word, or InDesign, or some other single output platform, but after going to STS and XML you’ll be able to do more with your content.

Webinar number seven and eight are going to be presented by guest presenters from ISO and Standards Finland. Both of them are going to be case studies.

The first one is going to be a case study on how ISO implemented their XML workflow, and the issues they’ve run across, and the benefits they’ve received.

The second case study is going to talk about publishing multilingual standards from SFS, or Standards Finland.

Over this webinar series we are going to help you understand NISO STS and how you can implement it, what the benefits are, and help you with some case studies so that you can make an informed decision if this is the right way for you to go.

BRUCE ROSENBLUM: Standards are everywhere. Unless you’re a standards professional, you may not recognize that standards are all around us. Whether it’s the size of shipping containers, or the thickness of railroad track, or even in fiction.

For example, in the popular Harry Potter series, Percy Weasley in book four is worrying about trying to standardize thickness of cauldron bottoms because there have been problems with leaks. So even J.K. Rowling was privy to the fact that standards are important for us in everyday life.

Of course, there’s one place where we haven’t had standards up until now, and that’s actually in the publication of standards.

Sure, standards have standard editorial styles, such as the ISO Directives or the IEEE Standards Style Manual, but that’s more about exactly how you put the standard together in terms of how it reads and how it’s structured, but there’s never been a standard for the XML markup of standards.

At least, until 2017 there wasn’t.

But now we have NISO STS. STS stands for Standards Tag Suite and what it is, is a standard for XML markup of standards, or another way to think about that is: How meta have we become?

It’s officially known as ANSI/NISO Z39.102-2017.

Where did this standard for standards come from? Well the start of it is actually in the ISO project that Chandi mentioned a few slides back. In 2010, ISO still had a very basic workflow for publication, which was to take Word files and make PDFs out of them. They had no full text XML, they had very slow publication times—often from FDIS to publication times in excess of six months for a standard.

And so they started a new XML project that was really very inwardly focused. They were not setting about making a standard. They were just trying to improve their own publication processes and, in the process, also try to have multiple output formats—not just PDF, but HTML, and EPUB, and have XML that they could load into a database.

What came out of that project is what’s known as the ISO XML model, or ISOSTS. Because when they started they didn’t have any DTD or Schema, and what they did as they started up their project is they contracted with Mulberry Technologies, a firm outside of Washington DC, to develop an XML model for them based on JATS.

JATS is the Journal Article Tag Suite, and this is also an ANSI/NISO Standard that originally dates from 2012, but the origins of it go back to 2002.

In fact, JATS has become pervasive in the journal publishing world. It’s pretty much the standard for full text tagging of journal articles.

But you may ask: “Why did ISO decide to base their XML model on JATS?”

Well they actually looked at several alternatives, including some standard models such as DITA, DocBook and TEI, and they also looked at building something from scratch. And when they compared all of these different models, they first of all decided that building something from scratch would be far more expensive, and really not necessary, and second of all, that all of these models had a lot of the structures they needed.

But in particular what JATS had, in addition to similar structures between journal articles and standards for things like sections, tables, figures and mathematics, JATS had far and away the strongest model for bibliographies and reference lists.

And it’s a very mature foundation; it was already an internationally recognized standard. It was actually already in use by many other standards organizations for publishing their journal material, such as IEEE.

And JATS also has extensive vendor and software support. So it almost became a no-brainer for ISO to go ahead and select JATS as their foundation, and have Mulberry take that foundation and modify it specifically to meet the needs of ISO.

So, with ISOSTS successful for the ISO project, and you’ll hear more about that in one of the later webinars when there’s a case study about ISO, why is there a need to create NISO STS?

Well, it turns out that ISOSTS has actually been quite successful for ISO and other national standards bodies, but it’s actually too limited for certain bodies outside of the national network—for example, many of the American standards development organizations or SDOs.

So what NISO STS provides to a much larger group of standards bodies is a stable standard that they can all use, and much enhanced guidance in the form of great documentation to both tool and conversion vendors about how to use the standard.

More importantly, it becomes a common format for sharing both metadata and full text, and a common XML model that can be used across publication types.

For example, many American SDOs publish not just standards, but journals and books and conference proceedings, and because STS is related to JATS, and also the BITS book model for XML, you can have a common core model that’s in use across all of those, and have a much greater leverage of your XML technology across all publications and groups in the organization.

And what all of this leads to is a lower barrier to entry for XML publication, for any standard body who now wants to get involved with XML.

What were the goals of the NISO STS project?

Well having established a need first for ISOSTS with ISO and their national standards bodies, and then NISO STS as a greater set of needs for standards development organizations, the working group that created NISO STS went ahead and moved to align the existing ISO work with the JATS 1.1 standard, because JATS had continued to evolve.

And by aligning more carefully, JATS and STS will be able to stay aligned into the future for updates to both JATS and STS.

What specifically was added to NISO STS? Well first of all, richer metadata structures. A tremendous amount of work went into this part of the project, to make sure that metadata requirements could be covered for just about any standard that we saw. And you’ll understand the breadth of this in a minute when we talk about the working group.

The second is much richer support for adoptions. The original ISO model was a flatter model, and the new NISO STS model has a much richer hierarchical model that can work not just for adoptions from the country level adopting an international or regional standard, but also for two standards organizations working together, where one may adopt the work of another.

And another very important addition is support for Digital Object Identifiers, or DOIs, because many American SDOs use DOIs to not only identify their standards, but to be able to link between standards.

And, of course, all of this was done with complete backwards compatibility for existing users of ISOSTS so that they can continue to work in a smooth way with the pre-existing model, and transition very smoothly to the new NISO model.

The timeline for the project was a two-year-long project. We had a call for working group members in August 2015, we had our first committee call two months after that, and we had a tremendous outpouring of interest.

We actually had so many people interested in the project that we broke the project into two groups, a steering group and a technical group, with the steering group setting policy and the technical group actually working out the technical details.

It took a year to get to a committee draft, and then we got tremendous feedback from the committee review of that draft, and ultimately brought the work to public comment in May 2017.

After a month of public comment we had just a few additional comments. We addressed those, brought the standard to NISO vote in September 2017 and, just weeks ago on October sixth, it became an official ANSI/NISO standard.

To give you an idea of the range of interest in this work, this slide shows the members of the steering group—so not the technical committee, just the steering group—and you can see it’s a wide range of people from national standards bodies, standards development organizations, vendors, libraries, other interested parties.

So it really was a tremendous range of people that we had. It wasn’t just a project of a few small people working on a team.

We also had a smaller technical group, and this group really focused in on the technical details of the work. And you’ll notice that the asterisks indicate people that are members of the JATS and BITS working groups as well, so this has created wonderful cross-pollinization between these different standards, to make sure that they can move properly forward in parallel.

And you can see that there are already a lot of adopters. These are many early adopters—of course ISO, with ISO being the organization that was behind ISOSTS. Many national standards bodies, but also many American SDOs are involved in this early adopting list.

And this list is not complete, we are aware of quite a number of other standards organizations at this point that are in the process of moving to either ISOSTS or NISO STS, or have actually started up projects already but aren’t yet ready to have their names publicly announced.

CHANDI PERERA: There are many benefits of adopting STS. One of the biggest benefits is it will help you streamline your production workflow.

Using STS, many of our customers and the standards organizations we’ve mentioned above have automated their production process.

But also, as part of that automation, they have started validating content much earlier in their production process. So traditionally, validation happens at either an editorial stage, or ideally at a proofreading stage.

So, for example, if there’s a figure citation for Figure 6, and figures stop at Figure 5, quite often it would get picked up at a proofreading stage. But when you have XML standards you can actually check if there’s a figure citation for Figure 5—does Figure 5 actually exist?

Or their might be a citation for an ISO standard, you know, ISO 1234:2013, and when you’re drafting the standard you’re expecting the other standard to be published in 2013, but something slipped and it went to 2014. Well, during the process, especially in the final cleanup phase, it didn’t get picked up, but XML validation can tell you very quickly—actually there is no 2013, there’s 2014.

A lot more of this is going to be explained in webinar number three when we’re talking about converting to STS, but you can do a lot more validation much earlier in the process by putting content into STS and actually validating that semantically.

You can reduce your time to publish. We mentioned ISO significantly reduced their time to FDIS—it used to be about a few months, about six to eight months, and now they’ve got it down to two weeks, with most publications being under one week. So that’s a significant time saving.

And it’s a significant benefit to the people who are using the standards, because standards are getting published faster.

There are improved tools. So not every single standards body can publish to every single platform out there. Fifteen to twenty years ago you published print—doesn’t matter where you were in the world, you got the same page size, same document.

Today there are many many many platforms. Obviously there is still print, but there is online PDF with different options, there’s HTML, there’s e-book. On top of e-book there are platforms like iBooks and Kindle, there are proprietary platforms, there are many many distribution systems, and not every single standards body can afford or be up to speed with all these different platforms.

But by going through to something like STS, you can actually publish to all of these using a set of tools, and do it at a lower cost than you could do by using a proprietary system or a system that is going to a single output.

By using a standard, it also means you’re sharing your risk of your workflow across multiple other organizations. So if you have a workflow that is proprietary to you, you are going to be fully invested in that, you are going to carry the full risk of that.

But if you use a workflow that’s used across the industry—a standard, for example—that means your implementation is going to be very similar to the implementation of other similar organizations. That means you can use the tools that are developed across all of these organizations, and therefore share the risk and the costs from these tools and the vendors.

STS is also going to help you with new products. Again, there’s going to be a later webinar that’s going to be covering this in much more detail, but going to XML, overall, will significantly reduce your effort and cost and complexity of producing HTML, EPUB, and mobile output.

XML and STS is also significantly going to enhance or help assist in producing accessible content, be it accessible PDF, DAISY, EPUB, or any other accessible formats.

It’s also going to help you develop new products. I would recommend after this webinar you go to your favourite search engine and type in ISO Online Browsing Platform, and go and take a look at that.

We are going to cover this browsing platform, the OBP, in a later webinar in a little bit more detail, but it is something that you can look at that is possible according to XML and STS, which is not possible or it’s going to be very difficult if you don’t have any underlying XML framework for your content.

It’s also going to help your customers, especially organizations that are going to be using standards from different organizations. So, right now, if you’re a customer and one person’s sending you PDF, another person’s sending you Microsoft Word, somebody else is sending you HTML, it is going to be difficult for you to have these standards in a single repository, a single interface.

By having a common standard across all standards bodies, it is going to help your customers access the standards and discover them much more easily.

Co-publishing standards and adopting standards are going to be a lot easier with ISOSTS or in NISO STS. You will see this in a later webinar.

And it’s going to help you interchange standards with your partners. So right now if you’re distributing standards in a proprietary format, or a closed format, you and your partner need to agree on exactly what’s being sent. Am I sending a Word file? Am I sending a PDF file? Am I sending an HTML file?

With STS there’s a defined set of metadata that you interchange, and it is a well understood standard.

And, of course, inter-standard linking is going to be very useful. Not only will you be able to link through to links within the document, so wherever you see ‘see Figure 5’ or ‘see Table 9’ you’ll be able to click through that and jump to the actual object, being the table or a figure.

You will also be able to link between standards, and those will be validated live links, and these things are going to be very useful. Again, there’s going to be another webinar on new products, but I want to get across—I want to stress—that going to STS will help you build new products faster and quicker.

If you’re a standards body that does a lot of adoptions, or your standards get adopted, using STS is going to significantly improve your adoption workflow.

You’re going to have consistent metadata in delivery to your partners who are doing adopting, or if you’re the organization adopting the standards you’re going to know exactly what you’re going to get, and it’s going to be really quick for you to adopt the standard and publish the adopted standard compared to dealing with proprietary formats.

Indexes and site-crawling are going to benefit because you’re going to have known metadata in known locations.

And it’s going to encourage adoption across industries that are currently maybe not thinking of adopting because it is a much harder workflow. As in if you are sending a Word file you need to know which type of Word file to send. Have you got the right fonts, because if you don’t have the exactly same set of fonts you open that Word file and everything is reflowing.

None of these are going to be an issue if you get an XML file and you render that based on your own set of requirements.

A much much bigger benefit for the wider community, and for you as a standards publisher, is it’s going to make your standards more discoverable. You will be able to deliver your products to many more devices. Today you might be producing a PDF file that might work very well on a big screen or a laptop, but probably does not work very well on a phone.

Or with new platforms coming you will be able to deliver your content either in a DRM format or a DRM-free format specific to that platform, using STS. So that means people will discover your standards from many many different platforms, not just having to come to your website and search there.

It’s also going to make aggregation of standards much simpler—so there are systems and portals where you can subscribe to or you can put your content on, who will aggregate your standards and cross-link your standards.

So, for example, if you’re from Standards Development Agency A, and you create a standard that refers to a standard from Standards Development Agency B, right now the only way to do that is go to your favourite search engine, find the URL for the other standards agency, go there, find that standard, and try and get a hold of it.

Now imagine if these standards are cross-linked. A, it’s going to be much more useful for the user of the standard, but B, it’s going to be much more commercially attractive to the standards agencies, because anybody reading the first standard might want to buy the second standard. So there is that benefit.

So, how can this impact your business? Well, it’s really up to you. STS is not a silver bullet, but it is enabling technology. It is going to help you update your workflow, modernize your workflow, it’s going to help you create new products, and it’s going to create a common new platform for vendors and users of your standards.

It is going to significantly increase the interoperability between your standards and your customers’ internal workflows, and your cooperating agencies and other people who produce and use standards.

But, at the end of the day, STS does not drive your business decisions. It is up to you how you want to implement it, and you will see some case studies later on standards bodies who have implemented STS, and their experiences and the benefits they have gained.

But, at the end of the day, it is a business decision you need to make on how to update your workflow, what new products you need to produce, and what your customers are demanding from you.

Typefi and Inera stand here ready to help you with making that decision.

BRUCE ROSENBLUM: So if you’re intrigued about NISO STS, where can you go to learn more about it? Well there are a variety of really really good sources.

First, the official standard has been published on the NISO site at this URL, it’s quite simple—

In addition, the STS Working Group has a public area on the NISO site—they’re workrooms/sts—and all of the minutes of the STS Working Group meetings have been made publicly available, so anyone who’s interested can follow the progress of the working group.

Finally, and actually most importantly, all the non-normative materials—including the DTDs, Schemas, RELAX NG models, and wonderful documentation—are available at, which is the site where all of the non-normative materials can be found. This site is a wealth of information.

In addition to all of this there is best practice information, there are sample documents to show how to take advantage of STS or there’s a sample adoption. There’s actually even a copy of STS in STS XML on that site.

So I recommend that you check out all of these resources, and also at the site you’ll find links off to a couple of full-day symposia that NISO has hosted about NISO STS.

So one of the great things about this is yes, it’s a brand new standard, but because it derives from work that’s already been publicly used in the standards world since 2010, and is derived from a pre-existing standard, JATS, that goes back to 2002, all of this work is mature. There’s a tremendous amount of information and best practice information about how to use this standard already.

So, have at it, and go use the standard.

CHANDI PERERA: Thank you for taking the time to watch this webinar. You can see the rest of the webinar series at the URL below.

I will be presenting some of the webinars, Bruce will be presenting some of them, and some of our consultants will be presenting the other webinars. This will help you understand the STS world.

If there’s any feedback, please send us feedback in that URL below. Thank you.