NISO STS: Past, present, future

The Standards Tag Suite (ANSI/NISO Z39.102-2017), or NISO STS, provides a common format for standards bodies, organisations, publishers, and archives to publish and exchange standards documents.

In this session from the 2021 Typefi Standards Symposium, Bruce Rosenblum, VP Content and Workflow Solutions at Atypon and a co-chair of the NISO STS Working Group, offers a history and overview of NISO STS Version 1.0, and discusses what you can expect to see in a future Version 1.1.

Transcript | Q&A | Presenter

Transcript

---

00:00	Introduction
02:58	XML for standards
03:40	Case Study: ISO adopts an XML workflow
20:15	ASME gets behind a standard for standards
22:34	Why create NISO STS?
24:41	History: NLM, JATS, ISOSTS, NISO STS
26:01	Goals of the NISO STS Working Group
27:11	The NISO STS Steering Committee
28:23	NISO STS: A standard is born
29:36	Benefits of NISO STS
32:25	NISO STS Public Tools and Information
33:48	The Future of STS
37:51	Conclusions

---

NISO STS: Past, Present, Future (00:00)

BRUCE ROSENBLUM: Good afternoon and good morning, everyone, wherever in the world you may be. And thank you for joining us today.

I’d like to speak for a few minutes about NISO STS and XML in general and how it can benefit your workflow in a standards organisation. And we’ll cover the past, present, and the future of NISO STS. I’ll give you a little bit of a peek under the hood at what we have coming up.

So, remember when travelling around Europe meant constantly changing currencies, every time you crossed a border to another country? I remember doing this as a young backpacker and always trying to minimise what I had left over when I crossed any border, which sometimes meant starving the last 24 hours in a country.

Standards are kind of like that too. If you don’t have standards, if things don’t work together, then it actually makes life a lot more difficult.

And so the Euro, it can be thought of as one form of standardisation and interchange, because what it did is it lowered economic barriers, eased travel between countries around Europe. It increased the interoperability of economies through Europe and the economic opportunity for companies in individual European countries.

And so what STS is, is a standard for standards that ultimately will aid in production, facilitate interchange between organisations—for example, a national standards body adopting an ISO standard—and promote interoperability. And ultimately, STS and XML can be used to create new publication opportunities for your organisation.

Also, remember when standards were on paper and that was it? They might have been in a three-ring binder so that you could add in addendum pages when they were published, but fundamentally they were published on paper and read on paper.

Well, today we have transformative technologies. We have smart phones, we have specialised reading devices, we have generalised tablet devices, and the device market is constantly expanding, requiring not just support for new devices, but for a wider array of formats that are used by those devices.

All of that requires a new foundation in order to produce and publish your content. And ultimately, the best way to approach that foundation is to think about things from the perspective of having an XML workflow.

And it’s that XML workflow that enables multiplatform publishing, so that with a single source file, you can actually target PDF, e-books, Kindle, HTML, and so on.

XML for Standards (02:58)

Enter XML for standards. Starting in 2012, we started working with ISO for a project that would be the foundation for a new way for them to publish standards. And that new way was going to be based on XML.

It was not ISO’s first attempt to use XML, but this time we stepped back and we looked at a whole bunch of different factors. Ultimately for ISO, XML is the foundation for creating their PDF and for their Online Browsing Platform, and it facilitates all kinds of other things such as metadata sharing and additional formats.

Case Study: ISO adopts an XML workflow (03:40)

So let’s actually take a look at ISO as a case study because that’s really the foundation of where STS comes from.

Prior to 2012, what was being used in production was the ISO STD template, which was a Microsoft Word template. And that was used both for authoring and for production. It required a huge amount of in-house cleanup, and then ultimately the Word file was converted to PDF. But this workflow had lots and lots of issues.

First of all, the template itself was very large and complex. Just the template file had grown to be over 5MB of styles and macros and so on.

There was varying quality of use, some committees used it a hundred percent, some didn’t use it at all. Some kind of tried to use it, but didn’t do a very good job.

And in addition to all of this, there were increasing security issues with Microsoft Word, Microsoft Windows, even trying to install a template that had macros onto systems of end-users, of authors who were actually working on writing the standards.

Then, once the standard arrived in the editorial and production team, it took extensive time to format up the standard with the same macro, so that you could then very easily create a PDF from it.

But this had a couple of problems. First is, publication time is very slow because this took a huge amount of work.

The other is Microsoft Word is not a page layout application. I like to say that Word is a very good authoring tool, it’s an okay editing tool, and it is a lousy typesetting tool. And so essentially, what ISO was doing, was using Microsoft Word as a typesetting tool, something for which it’s not well-suited.

And the ultimate product that reached the customers was not suitable for e-readers. It wasn’t suitable for things like smartphones—anyone who’s ever tried to read a page-oriented PDF on a smartphone knows that that is not a fun task—and it had no rich hyperlinks. So there were no internal hyperlinks between different sections or different figures, and if one standard cited another standard, there were no external links that you could immediately jump to a PDF file that had that additional standard.

So, ultimately it wasn’t a very good workflow. But it was an expedient workflow because it had one huge benefit; because with standards, they always have to go back and be revised. And so what this meant is if the Word file was used to create that PDF, you could then hand the Word file back to the committee for the next round of revisions, knowing it had the exact same text as was in the PDF.

So, for that expedient reason, ISO had this Word-based PDF workflow, but it made it very hard to integrate XML into that workflow.

So, what ISO’s goals were in terms of going to an XML workflow? First to improve their publication process. They knew it was taking too long, they knew it was unwieldy.

Second, to have outputs in multiple formats, not just PDF, but HTML and EPUB.

And third, to be able to easily create redlines between different versions of standards.

And for a larger overview of this entire workflow, you can see this publication that I wrote almost eight years ago about XML Publication Workflows for Standards, and it is a much deeper case study of ISO and what they did.

So, when we started working with ISO back in 2011, one of the first questions we asked them is what’s your XML model going to be for your standards? And they said, “Well, we don’t really have one yet. We’d been thinking about TEI.”

And so we talked a bit further and realised that they might want to investigate a little bit further before locking in on a model. And we recommended that they talk with the team at Mulberry Technologies because they are among the world’s top experts in DTD development.

What Mulberry did is they came back and said a couple of things. First, it makes far more sense to base what you need on an already public schema or standard, because that will make it much easier to adopt and there will be a lot of lessons learned and a history already baked into that.

The second thing they said is for the kind of content you’ve got, there are probably four, sort of document, text, schemas out there to consider: DITA, DocBook, JATS and TEI.

So Mulberry went off and they did a formal analysis of ISO’s content. They already had quite a bit of experience with all four of these models and they came back and recommended that JATS be used for the foundation of a DTD for ISO’s requirements. And ISO looked at that work and said, “Okay, this makes sense.”

But then what they said is, “We can’t use JATS out of the box, we’re going to have to modify it for standards.” And I’ll talk a little bit more about the history of JATS further on, but just for those of you who don’t know it, JATS is designed for journal articles. It’s been a standard since 2012, but an ongoing project since 2003.

And so that’s why it made sense. And as we’ll see, what about it made sense as a foundation for STS?

Well, it turned out that standards and journal articles share a lot of common structures. They have sections, they have tables, they have figures, they have equations, they have bibliographies.

JATS was also a well-developed and well-tested model. It was already, by 2011, in use by thousands of journals around the world. And it’s also well-documented. It’s easily modifiable for use with standards—there’s actually documentation on how to modify JATS for your own needs—and there was also strong third-party support, both in terms of tools as well as vendors.

And while that should not necessarily be a sole reason for choosing a given XML model, it certainly helped in terms of ISO’s thinking that, gee, if we go in this direction, we’re not just forging completely new ground. There will already be third-party support for a very similar model.

So, what ISO had Mulberry do was take the then current version of JATS, which was version 0.4. It was actually what we consider a late beta version before the first 1.0 official standard. So this work was going on in 2011. JATS, actually, 1.0, became a standard in 2012, so just a year later. And made a few critical changes for standards.

First, the top level element of JATS was called <article>, but that didn’t make sense for standards. And so a new top level element was added, or we replaced article with an element called <standard>. So that what your top level element is in a standard is something called ‘standard’. And then within that, you have metadata, you have the body, you have any back matter.

The second thing that was done is to throw out the metadata for journal articles because that didn’t apply to standards, and to create new metadata elements that would work not only for ISO standards, so there was an ISO meta block, but for regional standards, for example, CEN or GCC in the Gulf States, for regional metadata, and then national metadata for individual national standards bodies, so that you could have metadata in a single document that would cover the full adoption chain.

For example, an ISO standard that becomes a regional standard, like CEN, that then becomes a BSI standard in the UK. So it would cover something like a BS EN ISO adoption chain, all within one XML file.

The third thing that was added was the TBX, a model based on TBX—an ISO standard—for defining terms and definitions. This was needed because terms and definitions have a much richer type of markup requirement and standards than anything that we’ve ever seen in journal articles or books. And so this way the terms and definitions section can have a very, very rich markup.

And the last is that standards tend to cite a lot of other standards and there was a need to create a better model for doing that. JATS did not have a very good model for citing other standards because they are not frequently cited in journal articles. And so elements were added to cite other standards.

There were other elements added at the detail level, but these were really the four main changes that were made in converting JATS to ISOSTS.

Another thing that ISO did, and this actually proved very important just as it had in 2003 with JATS when that was first made available, ISO made the DTD publicly available. They posted it on a website. In fact, it’s still available there, even though we now have NISO STS. And they put up the DTD, not only the DTD files, but also full documentation and other resources, and they made this available to other standards organisations.

In fact, ISO right from the beginning was thinking that this would be a great way to distribute their content to other national standards bodies, so they could use it for adoptions. And in fact, that has happened. So this, as with JATS, turned out to be a critical step of taking the work, making it freely available.

When ISO finally stepped back in 2014 or 2015, and looked at the value of what this project had been to the organisation, they realised at first, and most importantly, it had been a catalyst for positive change through the entire organisation.

Business rules were codified because they went to a much more electronic-driven workflow, a software-driven workflow, rather than individual editors doing what they thought was right.

It refocused the editorial team on high-value content editing, rather than just fighting with Microsoft Word to do formatting of standards.

And because all of this was codified, it actually permitted ISO to do some production outsourcing so they had more overflow capacity. They didn’t have that capacity or that opportunity in a largely manual workflow.

Ultimately—and while this was hoped for, the level of this was much bigger than expected—it allowed for much faster publication times; the average publication time, from the time a standard got from a committee into ISO prior to the XML workflow, had been about six months. And now as of 2015, it was down to about a month. I actually have not checked to see what the current publication time is.

And this also led to significant, significant cost savings. The editorial team was no longer wasting time doing things that could be done automatically in the XML workflow around format.

What this also led to were completely new opportunities in terms of products for ISO. They were able to build out what they call the Online Browsing Platform or OBP. And with this platform you can go—and this, by the way is completely public, anyone can go without an account—you can go and search on a word like “pasta” and you, again, get a list of all the standards that mention pasta.

Now, sure, with a PDF workflow, you could simply index the metadata and then the PDFs for all of these standards, but it gets more interesting because if we click in on one of these standards, you now see over here on the left, the table of contents for the standard.

And it may be a little hard to see, but you’ll notice things like scope, normative references, and terms and definitions are all in black because those are freely available, but once we get past terms and definitions, the rest of this is all in grey and it’s not available for free.

So, what this means is by having the foreword in the previous slide, and now the very tail of the terms and definitions available, with the XML markup, it’s very easy to create a sort of “freemium” model with the content and make more of it available for free without giving away the whole thing.

And what I’ve circled in red is, gee, you need to, this section is not publicly available, which is everything from the terms and definitions down to the bibliography. In other words, the heart of the standard, unless you actually pay for the standard.

So, XML has provided ISO a way to make much more information available for an end user to do a much more informed buy, make a much more informed buyer decision about that standard. Or if they simply need access to a definition for a term, they don’t actually have to go and purchase the whole standard for it.

Furthermore, we have very rich hyperlinking. So these upper circles above this ‘part not freely available’ section, these are section cross-references to section 6.11 and 6.12, and annex A. And these are clickable so that if you have the full text available, if you’ve paid for the standard, you can actually click through the standard and even in the PDF, they’re clickable.

So, we’re in section 3.4 here, optimum cooking time, and if you were to click on this link I’m hovering over, 6.11, that would take you directly to that section, even in the PDF that you can purchase.

There are also external links, and what we have here are mentions of other ISO standards. And this is actually particularly interesting because with the XML, we’ve got a standard in bibliography that was published in 2011, and then it can reference—I’m sorry, not 2011, 2008—but it can then reference newer standards.

So, if I click through on this standard, which is a much earlier year, it will actually take me to the current version, which is 2009. And so what XML allows us to do is actually resolve to the newest version of a standard when that’s published, if we choose, in a linking environment. Now that obviously wouldn’t happen in the PDF, but in a more dynamic web-based environment, we can do that.

The other thing is with search results, we can get much more deeply into the standard, and this is one of my favourite features of the Online Browsing Platform, is we can look at snippets so we can see exactly where the word pasta has appeared in all of these different cases.

The other thing, and this was really important for ISO, is they wanted to be able to do on-the-fly conversions, because anyone who’s ever tried to build a redline version between a previous version of a standard and the current version knows, that just simply is not fun.

It’s a very ugly task to do manually, but what ISO was able to do was partner with Typefi and a company called DeltaXML, so that what they could do is offer a redline button, and when you pop this down, you actually get all previous versions of the standard, so that then you can choose any two arbitrary versions to compare, which is another cool feature because with traditional redlining, you only got a red line between the most current version and the immediately prior version.

And when we select that, we now get an on-the-fly created redline showing you exactly what’s new in the most recent version of the standard. So these are things that you can do with STS XML, that have enabled ISO to have a much richer environment for their customers.

So ISO was off to the races. They went into full production with ISOSTS in 2012, and by 2015, they were cooking along nicely.

ASME gets behind a standard for standards (20:15)

ASME comes into the story around 2013. ASME, the American Society for Mechanical Engineers, has a huge standard called the Boiler Code. And I think it’s something like 31 volumes, and they had spent the previous six years working out an XML workflow for it—it was based on DocBook.

But what they’d found that because the Boiler Code was so, so huge, that their XML environment had become highly customised and was fragile and not sustainable.

So, when they finally got the 2013 edition out, they said, “Let’s step back and see if we can figure out a better way to do this.” So they had an all-day meeting and they decided let’s move forward with something completely new based on DITA.

And then the next day they happened to walk across the street to the annual Society for Scholarly Publishing conference, and that was where they learned that ISO, which had created ISOSTS, was actually considering making it a formal standard with NISO, so it would be a standard in parallel with JATS at NISO.

And ASME literally within hours, threw out the idea of DITA and said, you know what, this makes far far more sense, and not only that, we want to be a part of it.

And so, as Co-chair of the STS Standing Committee, I want to explicitly say I’m extraordinarily grateful for ASTM and ASME, together, not only submitting a work item proposal in May 2015 to NISO to create the NISO STS project, but also for sponsoring that project.

They have given us the funding that we’ve needed to do this project correctly, mostly in terms of building out the DTD properly and making sure it’s properly documented, and then maintaining the website for it.

And more recently they’ve both been funding, and IEEE has joined into that funding, and so I’d like to acknowledge and thank all three organisations for having provided the funding that’s so important for this project.

Why create NISO STS? (22:34)

So, let’s step back for a second and think about, well, why create NISO STS?

ISOSTS was already working successfully for ISO and a number of national standards bodies, NSBs, who had rapidly adopted it, but this was where ASME came in. They looked at it and said, you know, it works super well for ISO and a lot of it’s going to work well for us, but there are certain things that just are not ready for us, in particular around the metadata.

And so, what NISO STS provides, in contrast to ISOSTS, is a stable standard that should work for most standards publishers. We won’t guarantee it works for all, but we think it should work for most anyone out there.

And it provides a tool. It provides guidance to vendors of software tools that help in this space and also to conversion vendors—so the documentation has a lot about best practices.

But even more importantly than that, it provides a common format for sharing both metadata and full text, and a common XML model across standards publications, both across standards organisations.

So, I mentioned the adoption model before, but also within an organisation, it turns out a lot of standards organisations such as ASME publish both standards and journals. And it’s a lot easier if they share a common model in terms of JATS for journals and STS for standards, because there’s already familiarity from one in the organisation, if you use the other, then everything becomes much simpler.

And ultimately, what all this does is lower the barrier for entering XML publication for any organisation that’s interested in publishing their standards with an XML workflow.

So, I can assure you that what ISO had to spend to get going with this workflow 10 years ago, organisations can pay a lot less than that now and get going because there’s standardisation around it, and because vendors and tool vendors have also been able to standardise around.

History: NLM, JATS, ISOSTS, NISO STS (24:41)

So just a little bit of quick history—I keep mentioning JATS. The JATS project began actually as something called the NLM DTD in 2002, became publicly available in 2003, and just in those five years between 2003 and 2008, became so successful that the people in the community said, you know, we really need to make this a standard rather than a less formal community project.

And so that was when NLM moved to NISO, was in 2008, the moniker was changed from the NLM DTD to JATS, the Journal Article Tag Suite, and it became a formal NISO project.

At that point, we actually stepped back and wanted to update it, and so it took four years until 2012 to actually come up with the version 1.0 of JATS in 2012, that’s known as ANSI/NISO Z39.96.

JATS in turn begat ISOSTS in 2011, as I mentioned earlier, and then it’s the ISOSTS foundation that we used to create NISO STS starting in 2015 and that actually became a standard two years later in 2017, and that’s formally known as ANSI/NISO Z39.102.

Goals of the NISO STS Working Group (26:01)

So, the goals when we created the working group to turn ISOSTS into NISO STS were number one to expand it for use by standards development organisations and essentially think beyond the ISO and NSB case, but to think about all standards bodies.

The second was to update it with a more current version of JATS. By this point, JATS had been through another five years of iterations and we wanted to incorporate some of the updates through JATS that were actually quite useful.

The third is we wanted to add some additional structures that hadn’t been needed by ISO originally, but other organisations were finding they needed, such as tables of contents, index structures and a secondary table model.

But also very importantly, this was clear right from the get go with the committee that was working on this, is we had to maintain backwards compatibility with ISOSTS so that anyone who was already using ISOSTS could almost seamlessly transition to NISO STS.

The NISO STS Steering Committee (27:11)

We put out a call for interest in August of 2015, and actually we were overwhelmed with the number of organisations and people who were interested in being involved in this project. We ended up with 43 people.

We realised the only way to make it manageable was to split into two different groups; a steering committee that would determine policy, and a technical committee that would actually work on the technical models. These are people who were very comfortable down in the bowels of XML.

Both groups were co-chaired by myself and my colleague, Rob Wheeler at ASME. Tommie Usdin and Debbie Lapeyre, of Mulberry Technologies, participated in both—Debbie Lapeyre as the secretariat for the group, which is tremendous to have someone who actually takes wonderful minutes, prepares great agendas, and then can turn around and take the results and turn that into not only the XML model, but documentation.

You’ll notice I’ve highlighted a few people who overlap between both the JATS working group and the STS working group, that as I’ll come back to, has proven to be incredibly valuable over the long-term.

NISO STS: A standard is born (28:23)

So a standard was born. We had a first draft standard released in April 2017, quite happily on the day of an STS Symposium that was held at the Library of Congress in April of that year. We were able to sort of celebrate the first draft being made publicly available, and the final voted standard appeared in October, 2017, just a day before we had a Symposium in Geneva, also focused on STS.

And it has been pretty widely adopted, this is just a partial list:

*JATS-derived

I’m sure that there are many others I’ve forgotten. And if you would like to be on this list for a future version of this slide, please do not hesitate to let me know, but these are certainly ones that I knew just off the top of my head and they represent international standards bodies such as ISO and IEC, national standards bodies such as BSI or Danish Standards, and standards development organisations located in the US such as ASME or American Water Works Association.

Benefits of NISO STS (29:36)

So ultimately, what STS provides in terms of benefits are, first of all, the ability to create new workflows. It can streamline your production workflows, providing you the opportunity for greater automation, greater pre-publication content validation.

There are some tools that ISO was using that are making their standards more accurate than they used to be with much less manual work, because they can cross-check all kinds of things that just would have been too time-consuming before.

Ultimately, this all reduces time to publication, and the improved tools create a larger market for those tools and less customisation required from vendors and therefore, as I mentioned earlier, you can get into this workflow for a lot lower cost today than you could 10 years ago, when ISO was first starting this up.

STS allows you to create new products—the Online Browsing Platform is a beautiful example of how XML can be used to deliver all kinds of innovative services and features to your customers.

It makes it easier to co-publish standards. It makes it easier to interchange information, particularly metadata with distribution partners.

And it enables inter-standard click-through linking, which is something that end users love, because it means they don’t have to go shuffling around between documents or using Google, they can just click and they can get to the target standard that they want.

STS, and XML behind it also benefits discovery in that end-users—because they have better metadata, more consistent metadata across different publishers—can find it easier to discover standards that they might not know about and find useful.

Instead of having to know about a specific standard, you can, for example, search for all standards about wheelchairs, and then go browsing through to see what you might not already know about.

This also allows for improved library management. There was a wonderful talk at the Charleston Conference in 2015 that we do recommend looking at in terms of how a corporate librarian or in this case, a government librarian, views the management of standards for their users.

So ultimately, how can STS impact your business? That’s up to you. It’s an enabling technology. It allows you to update your workflow, create new products, have a common platform for vendors, and have greater interoperability, but ultimately remember STS doesn’t drive your business decisions. Your business requirements drive your technology decisions, not vice versa.

NISO STS Public Tools and Information (32:25)

I want to quickly point out some public information about NISO STS, where you can learn more.

There is the website NISO-STS.org, and that’s where we have all of the supporting materials for the standard.

The actual STS standard is simply a PDF document, but this is the site you want to look at if you’re working with the standard, because it has extremely rich detail, documentation about all the elements and attributes, it has best practices.

This new diamond control lets you automatically expand or contract an entire entry, which is a wonderful new addition recently.

There’s also the STS discussion list, maintained by Mulberry Technologies, and you can go to this list and sign up and see emails whenever people have questions or you can post your own questions to the list.

And then there’s an STS4i project, which encourages best practice use of STS or interchange, and this is maintained by Gerrit Imsieke in Germany, and this has a whole suite of tools as you can see here – all open-source and available.

The Future of STS (33:48)

So, like most standards, STS also is changing. Standards typically go out for review every few years, JATS is in a continuous update mode and so is STS.

And part of that is because electronic publishing is constantly changing, and so standards around electronic publishing need to be kept up to date. So we are accepting comments for suggestions, changes, requests for new types of support, new structures, at this URL which is on the NISO website. There’s a formal commenting process, as there should be for any standard, and what we follow is the ANSI/NISO continuous maintenance process. So we formed a standing committee in early 2019, and since October 2019, we’ve been meeting monthly and we expect that we’ll have a draft 1.1 version sometime later this year.

So, what’s coming up in NISO STS 1.1? A bunch of things.

First of all, JATS as I mentioned has not stood still, version 1.3 is at ballot right now so we’re catching up with a couple of new JATS versions to bring ourselves up to date with that.

And I’ll mention in saying this, that the JATS, STS, and BITS Standing Committees all work in close alignment with each other. There is membership overlap, but we’re actually very formal about if we discuss something in one group that we think may be of interest to another group, we’ll actually refer that over to the other group.

And all of them are actually guided by a common model called the JATS meta-model, which sort of organises conceptually how updates to the standards should be made. And it’s actually a wonderful framework document because it gives us a conceptual framework to work in for all three of these.

More specifically, what’s coming up in STS, and this is just a sampling of things, we’ve added @custom-type attribute for cross-references—it turned out that was needed to be able to cross-reference the terms and definitions from the body of the standard—and this actually made it into JATS 1.3, that’s currently at ballot.

We’ve added improved list attributes for bulleted lists.

We’ve added something completely new called processing meta, which actually sort of started in the JATS group, got worked on there, moved to the STS group, got refined there, and then the refinements from STS actually went back to JATS.

So this is where the two groups have worked in beautiful collaboration with each other. What this was designed to solve were some problems around DTD versioning information, but we expanded it to allow for other XML processing information. For example, you might want the name of a conversion vendor who’s worked on your XML. And there are more elements coming up.

The one thing that we’re not quite sure of in 1.1 is we’ve had requests to support markup of requirements. So “may”, “shall”, “must”, “should”, types of statements in standards, so that these can be extracted into a database.

Standards Norway is already doing some experimenting with the <named-content> element which has been in since the original version of JATS actually, all the way through into ISO and NISO STS. It may not work for all of their needs, and other NSBs and SDOs are discussing what their needs are both internally as well as cross-organisation.

But the bottom line is we’ve had a lot of discussion about this, and it turns out that so far, the requirements for XML markup, the requirements are still not clear. We will be very careful with how we proceed with this, so we’re not sure yet whether or not this is something that will make it into 1.1.

But it is something that is under discussion and if this is something that’s important to you, please do reach out because we’d like to hear what you’re doing and what your needs are.

Conclusions (37:51)

So, ultimately, ISOSTS has been successful for ISO and national standards bodies. NISO STS expands this into needs for a standards development organisation, and the benefits of using a standardised model have been found across the board in terms of production efficiencies, new product opportunities and easier interchange between development and distribution partners.

NISO STS will continue to have a standing committee that will meet regularly to address future needs and there will be future updates to the standard. So with that, thank you very much and I look forward to answering any questions that you may have.

---

Q&A

It looks as though there is a significant number of standards organisations now using NISO STS. Do think there’s a general trend in that direction?

BRUCE: I think about half of Inera’s standards customers have updated to NISO STS at this point. The update is actually quite easy, because it is 100% backwards compatible, so from our perspective in terms of production software, it’s a very easy upgrade.

There may be other impacts in other systems down the line such as if they’re using an XML database, but it should ultimately be a very easy upgrade because we’re so focused on that 100% backwards compatibility.

What sort of authoring tools are available for ISO STS environments?

BRUCE: Anja or Kylie may want to address this, but I’m pretty sure that their Fonto environment is working with NISO STS rather than ISO STS. Is that correct?

KYLIE RODIER (ISO): Yes, that’s correct. The difference between Fonto and an editor like Oxygen is that Fonto is a lot more intuitive. It reaches a middle ground between drafting tools that we’ve seen before—like a ‘what you see is what you get’ editor or a text processor like Word—and looking at the native XML in all its tagged and elemental glory, which is what Oxygen or other code editors do.

If you want to work with XML directly, there are editors and tools to do that, but you need to be familiar with tagging and code, and not everybody. Fonto is a nice kind of middle ground between that. You can use it quite intuitively and you don’t have to worry about the code if you don’t want to.

BRUCE: In theory, any XML editing tool—whether it’s Oxygen, Notepad ++, even a text editor in which you can manipulate XML—can be used for NISO STS, but the Fonto environment is very much fit for purpose. It has a lot of special controls specifically designed around the authoring process for standards.

And then there are also options as well that have been mentioned in terms of using conversion tools or conversion vendors, if your working groups or committees want to stay in something familiar like Microsoft Word and then have those converted to NISO STS.

Having worked across dozens of standards bodies, can you give everyone an overview of what they should be looking for if they’re considering adopting NISO STS in their workflow?

BRUCE: Well, I think one of the first questions you’ll want to look at is whether you want to be authoring natively in STS, or if you want to keep your working groups working in whatever tool they’re using today, which is likely Word. So that’s an initial splitting point.

The second is you’ll want to take a look at how you want to handle your back catalogue. I generally recommend that you use a conversion vendor for that, because there may be idiosyncrasies that might not show up in modern content. There may have been structural things done in the past.

That will be much easier to handle on a one-off basis by manual vendor, rather than trying to do yourself in-house. And I know quite a number of people who are attending this symposium who have experienced using vendors for back catalogue conversion.

Then you need to figure out what are your rendering targets? Do you want to have something in addition to PDF, such as HTML or EPUB, and then how are you going to make this available to your end users?

There are a number of different organisations that actually offer STS hosting services so that you can have your STS hosted on an online platform in parallel with PDF, so that’s not necessarily something you have to build in-house. It’s something that you can outsource.

Certainly, I think any of us who are speaking would be happy to help walk people through some of these questions. I know Chandi and I have spent quite a bit of time over the years helping organisations through what some of these initial questions are, and to help them get to answers that are going to work for each individual organisation.

We don’t think of all organisations as being identical—they each have unique needs and unique requirements, and we try to take those into account.