Standardizing Standards 1: Introducing NISO STS

Webinar Transcript

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: 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: 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: 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: 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—www.niso.org/standards/z39.102-2017.

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 www.niso-sts.org, 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 niso-sts.org 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: 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.

Standardizing Standards 3: Getting Your Content from Word to STS XML

Transcript

BRUCE ROSENBLUM: In this session we’re going to talk about getting your content from Microsoft Word to NISO STS XML.

My name is Bruce Rosenblum, I’m the CEO of Inera Incorporated and Co-Chair of the NISO STS Working Group.

Inera Incorporated has been around since 1992. Our focus is to develop systems for editorial and XML to automate the process of getting from Microsoft Word to XML.

We have a combination of expertise in software, technology, publishing, and workflow, and we apply that to help publishers develop single-source workflows to publish their content, usually using XML as a key part of that single-source workflow.

Ultimately what we’re trying to do is help our customers gain efficiencies through the publishing process, and leverage industry standards such as JATS, BITS, STS, and MathML.

eXtyles is a suite of editorial and XML tools for Microsoft Word. It facilitates not just converting from Word to XML, but a lot of the editorial preparation that you have to do in your document whether or not you’re creating XML.

eXtyles helps to clean up and mould Word documents into a standard visual and editorial style, helps to automatically edit references to external content, integrate metadata into the file, check and link normative references and their designations to other databases, correct content in the document through looking up information in databases, validate URLs, check internal cross-references, and finally, after all that’s been done as an aid to helping the editor, all of that work also helps to convert the document from Word to valid XML according to NISO STS and other schemas.

And of course, all of this can be completely customized for any publisher requirements. So if you have unique requirements, eXtyles is an open framework that can be customized to meet those needs.

We have customers in 26 different countries on six different continents. This is a small sampling; you can see that we work with quite a number of standards organizations, including organizations like ISO and IEEE.

We also work with very high-profile publishers of content in other realms such as journal publishing, where we work with many of the top journals around the world, and also governments such as the US Government Printing Office.

Fundamentally we have three key design principles behind eXtyles.

The single most important one is that the content authors are subject matter experts, and that’s all. They aren’t editorial experts, they aren’t production experts, they aren’t going to do your production and publication work for you.

They know Microsoft Word, they’re used to working in Word—actually they’re often used to working badly in Word, so often the documents you get in from them are not exactly the best-constructed documents in Microsoft Word—but they’re not going to do the editorial and production work for you.

So, you’re going to have to do that yourself and, most importantly, they’re not going to give you XML.

But interestingly, the next one of our key design principles is that most editors actually prefer working in Microsoft Word over specialized XML tools. Again, just like the authors, they know Word, they’re used to it, and they can focus on the content rather than focusing on the underlying technology that you’ll be using in the publication process.

And our final key design principle is that what we’re trying to do is automate any repetitive process in the editorial and production stage, but to do so safely. Anything that risks making an incorrect change in the content is well beyond the scope of what we’re trying to do.

But what we are trying to do is help the editors get through a lot of the technical editing of the content so they can focus on making sure that the content is readable and correct. And ultimately, that’s what’s most important to the consumers of your content.

What our proven approach has shown is that it increases productivity, improves quality of the published output, and lowers overall costs. Many of our customers have seen their time to publication drop by more than half once they’ve implemented an XML workflow with eXtyles.

So now let’s move onto the fun part, which is a demonstration of eXtyles.

We have a Microsoft Word document that was published by CEN a couple of years ago. CEN is the European Union standards organization.

This one is about cereals and, like most standards documents, it has a foreword, scope, normative references, terms and definitions. Then we get into the body of the standard, and then in the back it has a bibliography, it has four annexes, A through D, so it’s a very typical standards document.

When eXtyles is installed in the environment, you have an extra ribbon within Microsoft Word that gives you the eXtyles options. And initially all of them are greyed out, because the main thing we want you to focus on first is the Activate and Normalization step. This is the first step in preparing the document.

And for CEN what we’ve actually done is automated much of their metadata collection. So what I can do is actually fill in, in this dialogue, the work item number for this document, and then I can click the Get Metadata button and what this is actually doing is looking up this metadata on a server located in Brussels at CEN and automatically adding it to the document.

So I click OK, and this information is now being stored with the document, and in fact there’s additional information that we didn’t even show onscreen. But this avoids rekeying of information—this avoids errors that can come with rekeying information—and provides a much easier mechanism for updating much of the front matter metadata in the document.

Once this is done, we can then move on to the next step of preparing the document, which is document cleanup.

Oh, and you’ll notice even before I move on, that all of a sudden the font has changed in this document because CEN changed styles a few years ago from using Arial for their documents to using Cambria, and automatically eXtyles has loaded and applied the new Cambria-based template.

So this is just a small example of how eXtyles can automate much of the formatting of your documents.

The next step is a Cleanup step where we have a large variety of options, including white space cleanup, we can control whether or not we’re removing white space from sections of the document that might have computer code—clearly we wouldn’t want to do that.

And we can remove some of Word’s typographic controls because InDesign has much better typographic controls. We can do a whole bunch of other cleanup operations that help prepare this document.

I’m just going to click OK with this group of settings, and this will take just a moment to run on the document. In addition to all of that, there’s one item that’s not a checkbox item, and that’s Recovery of Special Characters.

One of the biggest problems we’ve seen publishers have over the years, particularly if they move content from Word to InDesign, is loss of special characters because of oddball font issues.

eXtyles works to make sure that every character is automatically recognized and reinserted into the document with a Unicode value, although visually it appears as a special character, so you’ll see where we have any accented letters such as these e-acutes, they are visually correct.

But more importantly they are structurally correct so that you’ll always have the correct special character when you go to XML or when you go to InDesign, or to any other environment.

Having done that Cleanup step, the next step is the single most critical one for preparing the document for XML.

If we change to Draft view in Microsoft Word, you can see that we have some styles here, but some paragraphs in fact aren’t styled correctly. And if we were to start with the foreword we could, if we wanted to, go to Microsoft’s Home ribbon and use Microsoft style controls to actually set up styles for this document.

So, we can go looking through here for a Foreword Title, and there’s my Foreword Title, but that’s actually a challenging interface to use.

And so in fact what we do instead is we provide the end users with a palette organized by logical sections of the document or logical clustering of styles such as title styles, ten point body styles and so on. And each organization can have their own organization styles.

Each time you click a button it applies a style and automatically highlights the next paragraph. And so this palette makes it much much easier to accurately and quickly apply styles.

So here we have a Heading 1, here we have Body Text, another Body Text paragraph, four List Continue paragraphs, Body Text again, another Heading 1, more Body Text. So you can see on the Body Text styles have gone actually from Normal to Body Text. This paragraph is actually a normative reference, and so we have a special style for that.

And what we’re doing by adding these styles is providing all of the critical structural information that we ultimately need to create the XML.

Here we have terms and definitions, within this we have notes, and by the way there are hotkeys for all of these characters, so by pressing N here I also get a Note style applied.

I’ve actually pre-styled the rest of this document but you can see that this is a very easy and intuitive process, and in fact many of your organizations may have already been doing this kind of styling to prepare a document in Microsoft Word to make PDF anyhow.

So this is actually a natural extension of it, but it’s better because the styles are organized in a more logical fashion, number one. And number two, you may have occasionally through the years seen a case where you had a bit of italic or bold in the middle of a paragraph and applying a style with Microsoft Word tools actually obliterated that font change.

That’s actually a bug in Microsoft Word; Microsoft refused to fix that bug. But using the eXtyles palette you will never experience that bug because we’ve managed to program around it.

So this provides you a much better model for templating a document.

As I said, the rest of the document I’ve pre-styled so you don’t need to watch me do the entire document, but you can imagine that most documents would actually go through this styling process fairly quickly.

Now, once we have those styles we actually have the foundation to create XML, but there’s much much more that eXtyles can do before we create the XML.

The first thing, as we move from left to right across our menu or our ribbon, is we have a feature called Auto-Redact. And the idea behind Auto-Redact is that it’s a large Find and Replace with thousands of rules pre-programmed to your editorial style.

It will go through and not replace the copy editor, because a copyediting task is a human task which can’t be replaced by a computer even with artificial intelligence, but it will do a lot of technical cleanup on the document.

I won’t dive into all of these rules, but I’ll just click OK and let this run and describe, for example, that we have rules that can convert American English spellings to British English if that’s your style. Or the other way around, if you’re working with an international working group but you use standardized spellings.

We have rules that can clean up callouts to figures and tables. We have rules that can clean up units of measure so, for example, if your standard is to always abbreviate ‘Hour’ as ‘H’ we can automatically go through and do that.

But here’s the cool thing. We can do it in a context-sensitive fashion, so we would only do it if there’s a number preceding the unit of measure. So the expression ‘the experiment took 3 hours’ or ‘the test will take 3 hours’ can be converted to ‘the test will take 3H’. But a sentence that has ‘the test should take several hours’ will not be converted because that would be a nonsensical change.

So eXtyles can be very very context-sensitive in these rules. It can also be sensitive to specific paragraph styles when applying these rules. So it’s almost like having regular expressions that you can apply to the document.

Now for those of you who worry about what’s going on with automated changes, we actually make a backup copy of the document immediately before we run Auto-Redact, and then we can use Word’s Compare feature and we can see exactly what’s changed in the document.

So here, for example, you can see a non-breaking space has been added in the middle of the designation. And in fact you’ll see that throughout this document, that wherever we have a designation, a non-breaking space has been added just to make sure that you don’t get a bad break across lines.

We’ve actually added non-breaking spaces in lots of places. Per European style or Continental style, non-breaking spaces have been added between numbers and percent signs wherever those appear.

Here’s more of an editorial type of change. Fig abbreviated has been changed to Figure spelled out.

This is an interesting one that CEN asked us to make. Any time they have words like ‘recommend’, ‘must’, ‘shall’, ‘may’, those are all highlighted in yellow so that the editor’s attention is drawn to those expressions and make sure that they’re used correctly.

That’s absolutely critical with standards, that it’s clear what’s a recommendation versus what’s a requirement, and by doing this automatically throughout the document we guarantee that the copy editor will actually see all of those cases.

We have lots more cases of non-breaking spaces being added; that seems a be a lot of the work that’s been done here. We have spaces added around equals signs, so we’re cleaning up the content around mathematical operators.

And that looks like it’s about it, so not a huge number of changes, but you can see a lot of bulk cleanup being done. And if you can imagine with all of these non-breaking spaces having been put in, it automatically saves time during the typesetting phase of the operation because you don’t have to go in and manually start putting in non-breaking spaces everywhere you need them in order to avoid having bad line breaks.

Once we’ve reviewed the results from Auto-Redact, we can actually turn our attention to some other parts of the document, for example, the normative references and the bibliography.

What we have in eXtyles is actually an open hook for advanced processes, and you can do all kinds of really cool things with the editorial content.

The first one is Advanced Processing for Bibliographic and Normative References, and what this is going to do is go through and identify the normative references and bibliographic entries primarily by the paragraph style that was applied.

And then it’s going to both do some content cleanup—although in this case this reference was already formatted correctly—and also indicate what type the reference is, and add these character styles which are later used for creating XML that can be used for linking through to external sources.

So you can see in the bibliography as well that we’ve not only taken care of marking up and cleaning up these references to other standards, but also we’ve handled this reference to a book completely correctly, even recognizing the organizational author in it.

Once we’ve gone through and dealt with the normative references and the bibliography, the next thing that we can do we can check all of the in-text citations.

So, for example, FprEN, that’s an in-text reference to another standard, and we actually will go through and mark up all of those so that we know where we need to potentially have external links when this content might be posted online.

In addition we do some cross-checks of all of these items, and we’ll warn using Word comments if there are problems.

The first cross-check we do is we check to make sure that every item in the normative reference list is, in fact, cited at least once from within the body of the document. This standard was, because we didn’t receive a warning.

However, we did receive a different kind of warning. Let me just quickly close the Word Style palette so it’s easier to read the warning. And what we have here is that inline citation checking or matching detected that we have a reference to an object within a standard, but it’s an undated reference.

This is the kind of thing an editor might overlook but it’s actually quite important. If you’re referring to an object within a standard it should always be a dated reference so, for example, ISO 5223:2008 or whatever the year is. Because what Table 4 is may change over time if a new table is inserted or a table is deleted, and you want to make sure you’re referring to the right Table 4.

So these are the kinds of warnings that eXtyles can give during the editorial process that actually help make sure that the content is as accurate as possible.

We can actually go a step further with all of this, and for all of the ISO and CEN standards we can actually now take these references to them and check them against databases located at ISO and CEN to make sure that, in fact, these are valid references and current references to these standards.

So we’re actually going through right now and taking every reference to an external standard in this document, and doing a web service query against an ISO server in Geneva and a CEN server in Brussels to make sure that, in fact, these are correct and valid references to standards.

And it’s done, it says it’s checked thirteen standards, and it’s found problems with five. Let’s see, we have on this first one an invalid reference. If you look at the date this is 2013, and the Fpr means that this is a final proof, not the final standard, so in fact this should be modified, probably to be EN 16378. And the same right here.

So immediately we’ve been able to detect some problems with this and, of course, I could double check against the database; I do happen to know that that is final. And then we can delete the comment very quickly and easily once we’ve resolved the problem.

But again we have other kinds of problems. This is a reference to a withdrawn standard. In this case there’s a newer version, the 2011 version, and it’s warning us ‘gee, maybe the newer version should be cited’. So this is a case where as an editor you might actually want to go back to the working group and make sure that they specifically meant to cite the older version rather than the newer version.

So again, this is a great way that you can work with your working group with these automated tools to make sure that you’ve got the most current version of the citation available.

Another example here is that the reference came back with a different title. The year was missing in the original title, which we preserve in the comment, and the 2009 was added here, so this is a way in which the published document that’s in front of us is being made more accurate before it’s published.

And again a warning on this last one that we saw earlier in-text, that this is a reference to an out-of-date standard.

So this is where adding this kind of automation can really help with the process, to save editorial time and make sure your content’s as accurate as possible.

We do have a feature for going through the document and validating that all of the URLs are pointing to current and valid websites, that you’re not going to get any 404 errors. I’m not going to bother running it on this document because we don’t have any URLs.

The last thing I’m going to do before I create the XML, is a Citation Matching check, where we check all of the internal cross-references. So, for example, if we have Tables 1, 2, 3, and 4, is each table cited at least once and does any citation to a table resolve correctly?

So if we have four tables, but there’s a citation for Table 5, that will give us a warning that there’s a problem that we have a citation for Table 5 but in fact we haven’t found the right matching point for it.

This cross-checks not only figures and tables but also bibliographic references, and sections and equations. And it has found a few problems so we’ll go looping through our comments again here.

And we find a warning: ‘No section matches the in-text citation 5.9. Please supply the missing section or delete the citation.’

So if we go backwards here we can see we’re in Section 7, but in fact Section 5 only had sections up through 5.8.

So we very quickly caught a problem again that, in this case, you would have to go back to the committee and say, “Gee, which section should this be pointing to, or do we need to revise the text?”

And you can see all of the other section citations have been correctly marked up, and this markup will in fact be used when creating the XML.

Let’s see what other warnings we have here. Annex B hasn’t been cited—that may be OK but again you might want to check with the working group. Figure B.1 hasn’t been cited.

By the way, you’ll notice that in CEN’s workflow we have just names to the external figures here, we don’t in fact have the figures in the Word document, because in an XML workflow those figures ultimately have to be separate files so that they can be called in as images when you go to make PDF, when you go to the web, and so on.

But we also do support workflows where the images are embedded in Microsoft Word.

Again we have a warning that Figure D.1 hasn’t been cited, and D.2 hasn’t been cited, and D.3 and D.4. Again, these may be benign warnings, but better to have the warnings and be able to cross-check than to not have these automated warnings at all.

So having done all of the processes on the Advanced Processing menu, we’ve actually now helped the copy editor quite a bit, and at this point the document could be sent out for further copy editing, or at this point we’ve done enough that we can actually make XML.

So in order to make XML we come over to the Export menu and we choose if we’re making XML specific to CEN, in their case because they have some specific metadata requirements we’ve customized for.

And this’ll take just a few moments to convert the Word document over to XML using not just the paragraph styles that we added earlier, but also the character styles that have been added through the automatic processing.

And what’s really cool with all this, is that we haven’t had to go in and turn our copy editors into XML taggers. With the exception of applying paragraph styles, which you may already be doing in either Microsoft Word or InDesign to format your document today, we haven’t done anything more than that but we’ve added a lot of extra granularity.

And we have a message, congratulations, our file is valid according to the Document Type Definition or DTD—that means the document is valid according to the XML rules that you’ve laid out for it.

And what we have here in the XML is, first of all, all of the metadata. So we have the title in multiple languages, you can see that accented letters are represented as numeric Unicode entities. We could also do UTF-8, we can do ISO entities, so we have a lot of flexibility in how we set all of this up.

We have a lot more of that metadata that came, if you remember, from the beginning of this session from the Document Information dialog where we loaded this metadata from the server located in Brussels.

All of this metadata came in through that, including various meta dates that are included in this documentation, the permission statement, the entire title page. This actually was never even visible, but when we did that web services call, this title page information also came in.

And now we finally have information from the Word document itself. We have the foreword which, if I go back to the Word document, you’ll see the foreword here. And where we have the reference to the external standard, we’ve actually marked that up as a standard reference.

That’s really cool because then CEN can take this and make it a hyperlink when creating HTML or any other organization can.

And then we get into the body of the document, and we have sections. And this is where things also start to be really neat, because if you remember in the Word document, we don’t have anything special here in terms of the number 1 in this heading, or the bullets at the beginning of the list.

But yet, in the XML, we’re able to automatically make this a label and separate it from the title, which gives tremendous flexibility when doing formatting for online or for PDF, the fact that these are in separate elements.

We preserve the italic markup from Word. Again with the lists, we’ve automatically separated out the bullets of the label from the rest of the paragraph, and you can see our non-breaking spaces in here.

And then where we have a cross-reference to Annex D,—we’ve marked that up with an internal cross-reference, which means that when making PDF or making HTML, these can all be hyperlinks.

So what that means is now, instead of doing a lot of manual work to get internal cross-references as hyperlinks in your PDF, whether you’re setting up in Word or InDesign, all of this will happen automatically when you use Typefi to make your PDF.

Here’s our normative reference list, we have a special attribute on this, and if you were to look at the ISO Online Browsing Platform we’d see how they take advantage of these attributes.

We have the terms and definitions section marked up in TBX markup which is highly granular, highly structured, so that again you can do all kinds of flexible things in terms of pulling out the definitions, perhaps creating databases of them.

We also will cherry pick a few other things. We have the tables in the document. We preserve the column width information as well as the table width information, which can help with automatic layout.

More importantly, we preserve things such as column spans and row spans, so the entire structure of the table can be faithfully re-rendered online or in PDF, so no manual intervention is necessary.

You’ll also notice this scope attribute sitting in the table. This is for Section 508 accessibility. So by going to XML and using eXtyles to create that XML, you can start making it much easier to meet any accessibility requirements, whether you’re just concerned with, for example, in the United States, Section 508 accessibility requirements, or perhaps the Marrakesh Treaty which does require accessible content in many countries around the world.

So we have tables, we have figures in the document where again we parsed out the label at the beginning of the figure from the rest of the title. We’ve actually kept any author queries such as ‘gee, this figure hasn’t been cited’ as processing instructions. Those could actually be put onto a PDF proof if you wanted to.

And finally we have MathML, where we have converted all of the equation objects into MathML, and that can faithfully be rendered as well.

So we have very rich XML that nobody has to then go and edit by hand. So what that means is you can keep your team working very effectively in Microsoft Word without having much, if any, knowledge of XML.

They can very easily produce this kind of high quality XML, very granular highly-structured XML, according to the NISO STS DTD, and that can then be flowed with Typefi into InDesign to make PDFs automatically, it can be flowed onto a web page, it can be used to make EPUB, and it truly becomes the core of a single-source workflow.

So I hope in these last few minutes, I’ve shown you how easy it can be to take the Word content that comes from your committees or your working groups, and bring it through a process that gets you not only to NISO STS XML, but in addition can actually help your editorial team by making things faster and smoother through the whole process.

And ultimately get you to the point that you can produce wonderful documents in multiple formats, and actually do it faster, more easily, and more accurately, and at lower cost, than you’ve been creating just a PDF.

Thank you for listening, and we hope you’ll join us for the rest of the webinars in this series.

Standardizing Standards 5: Working with Standard Adoptions

Transcript

GABRIEL POWELL: Hello and welcome to “Standardizing the Standards: Working with adoptions.”

My name is Gabriel Powell and I’m the Senior Solutions Consultant for Typefi Systems. I’ve been with the company since 2010, and it’s my privilege today to introduce you to what it looks like to adopt standards.

We also have Bruce with us.

BRUCE ROSENBLUM: Hi Gabriel, I’m Bruce Rosenblum, thank you for asking me join this session. I’m the CEO of Inera Incorporated. I’m also Co-Chair of the NISO STS Working Group.

Inera is located just outside of Boston, and I’ve been with Inera for 20 years, and have been working with standards for a good part of that time.

GABRIEL: In this webinar, we’re going to discuss how national standards bodies can use an XML workflow to simplify the process of adopting and publishing standards that are produced by ISO, and European standards.

That would include the European Committee for Standardization, CEN, as well as the European Committee for Electrotechnical Standardization, also known as CENELEC.

I’m going to begin with an overview of what an adoption is, and then I’ll demonstrate how Typefi and Inera eXtyles are used to facilitate the adoption and publishing process for standards.

So what is an adoption, exactly? Likely, if you’re watching this, you know what an adoption is, but I’ll begin with a brief overview for those who are unfamiliar with the process.

The International Organization for Standardization, known as ISO, develops and publishes international standards. In fact, ISO has already published over 20,000 international standards. These standards are established within a broad range of industries and business sectors.

A standard is developed through a consensus process, and experts from all over the world work together to develop the standards that are required by their sector. These are really subject matter experts.

Once a standard is developed by ISO, an ISO member country can sell and adopt that standard nationally.

In addition, ISO standards are also adopted and sold as European standards. And a European standard is a document that has been ratified by one of the three European standardization organizations—that would be CEN, CENELEC, and ETSI.

Let me give you a brief overview of what an ISO adoption looks like.

Here we’re looking at, on the left side, the cover page of an international standard. This happens to be ISO 20160. And then on the right we have an adoption from Denmark. They adopted that ISO file, and let me take you into the core of this so you can see what that adoption looks like in the final published PDF.

This is the Danish Standards adoption of that ISO document. You can see they put their own cover page on this, along with their own designation, which becomes a DS/ISO standard.

If I move through, they’ll have an inside cover page with their own metadata specific for their needs, and then you’ll see the international standard cover shown on the right, and this is the same cover page as the ISO file itself. In fact, it’s the same copyright from ISO, as well as the same table of contents, and body throughout.

You’ll notice that Denmark places their designation at the top in the running header, so that you can see this is a DS/ISO adoption of this ISO standard. But the rest of this document is the same, from every page all the way to the back. Sometimes some national bodies will actually even append their own back page.

So that’s an idea of what an ISO adoption looks like. And if you were going to adopt a European adoption, it would be very much the same, where here we have the CEN cover page and then the actual adoption.

Let me just open up that document.

So here you can see that the Danish Standards cover is here with the designation DS/EN. And moving through, we have the same title page but this time we have a CEN cover with all of the CEN metadata and information. And then the table of contents, and throughout, we have all the content.

So it’s very similar to an ISO adoption, except for the body is from CEN.

I’d like to introduce you to the various input formats that can be used for creating an adoption.

We have three possible methods. One is to use ISO STS XML, and that has been in use for quite a few years now. And many of the standards, since around 2011, are being produced in this format, ISO STS. And then ISO also has gone through and created a back catalogue of XML files, so that would allow you to publish adopted standards for quite a few years back.

Then we have a new upcoming format that Bruce will introduce you to at the end of this webinar called NISO STS XML.

Then, alternatively, some standards just are not available in an XML format, and that would include some CEN standards, and maybe if you’re adopting an IEC international standard. If there is a back catalogue file that you want to publish and you want to use the PDF source instead of the ISO XML source, that’s also a possibility.

Let’s take a look at the pros and cons of the XML input format vs the PDF source input format.

If you’re using either ISO STS or NISO STS as your input format, the workflow looks as follows. On the left you will see that you have several STS XML files. You will have one or more depending on what you are adopting, and I will show you here in a moment an actual XML package.

But the benefit of using XML as your input is that you can generate multiple output formats. You can generate EPUB, PDF, HTML, DAISY, and more.

If you use PDF source as a format, you get reliability. You accurately represent that adoption or that standard. However, because you’re using a PDF input file, it is not possible to generate any other output format other than PDF, so keep that in mind.

Let me just move over and I’d like to show you what the input packages look like, comparing an XML input package to a PDF body input package.

So, we’ll begin with an ISO adoption. So inside of an ISO adoption package, this is the input package, notice that we have the original ISO XML file, and this in the ISO STS format.

It has a front section with the ISO metadata, as well as the front matter, foreword, and introduction, the body, starting from the scope all the way to the end of the document just before the annex sections if they exist, and then finally the bibliography.

This is all the original ISO file, and then to create the adoption, all we need to do is create an extra XML input file for the national adoption itself.

In this case we only have a few parts. We have the national metadata section, carrying all that metadata for the national components which includes the metadata for the cover page and the title page.

And notice the body section is empty, because it doesn’t actually have anything. The body is going to come from the ISO input file.

So that is a typical package for an ISO adoption.

Interestingly, it’s also possible to publish a multilingual adoption, so let me show you how that looks.

In a multilingual adoption you would have the same files. We have the same ISO input file with no changes, and then in addition to that we have the Danish standard or the national component, and in this case the body is not empty.

In this case the body has the translated text—so that international standard has been translated into the Danish language and it appears within the XML file from that national body, and that would include every section.

So that’s how we would create a multilingual adoption.

And just to show you as well what that would look like, when we publish the multilingual edition we get two options. One, we have a web-optimized view, and we have a print-optimized view.

I’ll start by opening up the web edition. It starts off like any other standard—we have the national body cover page as well as the front matter—and what makes this web-optimized is that there is a language code to the right of every heading in this document.

If I click on that heading, that language code, it actually takes me to the corresponding language, so that’s a really handy way to navigate between the languages in this document, and you’ll see that all the Heading Level 1 and 2s have a language code, so it’s very easy to compare and contrast and move between languages. That makes this web-optimized.

Furthermore, we have a print-optimized version. And for print, you don’t want to have to read one language before you get to the next language, so it’s really much more convenient to view the languages side by side, and that’s exactly what this print version offers.

You’ll see that the English language is on the left, and the Danish in this case is on the right. So it’s a really handy way when viewing this in print to read this document and compare and contrast along the way.

So you’ve seen an introduction to what an XML input package looks like when using ISO STS. Let me show you what an input package looks like when you have a PDF source.

So here is the final PDF output and we’ll take a look at that. I would like you to notice that this PDF, although originates from a PDF source, when you go through Typefi you do not lose the bookmarks. So if bookmarks are in that PDF source file, they’re actually preserved. If the TOC entries are clickable, they remain clickable. So this is a still a web-optimized and highly interactive document, as long as the input PDF file, that source PDF, contains those elements.

So that was the final output; let’s take a look at the input package.

In the input package, you’ll notice that instead of referencing another XML file that would contain the ISO or CEN standard, in this case we have PDF source files, and we have one control file which is what the national body will create.

In this case, Danish Standards has created this. It contains a national metadata section, again used for creating the cover page and their title page.

And then in the body section, instead of actually having XML content to create the body of the document, we have what is called a PDF rendition section, which references the name of the source PDF. And this is referenced in the order that the source PDF file should appear in the output.

It’s really that simple. You just need the control file with a national metadata section and one or more PDF rendition sections, and when you run that through Typefi it will generate the final result, again complete with clickable bookmarks, TOC entries, and hyperlinks.

I’d like to hand it over to Bruce, who will introduce us to how eXtyles is used to facilitate adoptions.

BRUCE: Thank you very much, Gabriel. eXtyles facilitates preparing these adoptions as well. If you’ve already watched the session about getting to XML in this series, then you know a bit about how eXtyles works. And eXtyles can work with adoptions in the same way that you work with preparing a full standard.

What you do, simply, when you’re working with an adoption, is you prepare the front and the back matter of the adoption in Word, and then you convert that to XML. Sometimes that may require having Inera add a few extra paragraph styles to your set in your palette, but otherwise the process works in a similar manner to preparing a full standard.

There are, as Gabriel pointed out, two ways of having the information prepared. The first is to have just your local information in XML, but the standard that you’re adopting in PDF. In this case you would use eXtyles to prepare a Word file with local front matter and your local annexes, and you would use the paragraph styles that have been set up for national standards bodies.

There’s also allowance for various custom metadata elements as necessary, to meet your local requirements for an adoption.

Then you also insert a reference to the PDF file into the Word file, and then you create XML using your standard export processes in eXtyles.

Typefi, as Gabriel showed, can then take that XML and combine it with the ISO PDF, or if you’re a national body adopting a European standard, a CEN PDF, and that all becomes a single PDF in the final result.

You can also do what we call a whole document adoption, where you take the final ISO Word file, you can add your local front matter and annexes to that Word file, and then you can create a single XML file that has your adopted material plus the standard embedded within it, and then Typefi can create a single PDF file from that XML file.

And now I’ll hand it back to Gabriel and he’ll give a demonstration of how all of this works.

GABRIEL: Thanks Bruce. Now I’d like to demonstrate how we can use Typefi to generate an ISO adoption. And this time I’m going to show off an adoption from Sweden, from Swedish Standards.

Here we’re looking at an input package. This is actually just a ZIP package, I’ve opened it up. In this case we have two input XML files. Again, one is the original ISO XML file, which was produced from eXtyles, and then we have the national XML file and it contains the national metadata section used to produce the cover, and then we have another section which is used on the copyright page.

The body is empty because that content comes from ISO. Then we also have all of the graphics, and that would include the math equations and any figures, and those would be in the package as well.

So to run this through Typefi, I would just need to locate a workflow in the Typefi server, and here you can see a workflow is indicated with this space rocket icon. We’ll produce a web PDF.

This is the actual workflow. I’ll give you a very brief introduction to the components. You have seen this in a previous webinar in much more detail.

It begins by ingesting that input file, so in this particular case there are two parts. One, this component, the SS multi component, will actually unpack the ZIP package and copy all the resources, the images and the XML files, and it will merge those two XML files into one, and then we actually convert those to another form of XML called Content XML using this SS component.

In the end, that input file is passed through a series of actions to create an Adobe InDesign document, and then finally export it to PDF, and finally to update the metadata so that all the metadata is added to the PDF and some other settings are applied to it to make it accessible.

I’ll go ahead and run that workflow. And here I’m just going to choose an input file. And I’ll go ahead and pick up this package, and go ahead and run it.

Now you’ve just watched me manually run a job. It is possible to connect another system on the front end, such as a MarkLogic system, which can actually send the input file via an API connection to Typefi so that you don’t manually run jobs. You can automate the running of the jobs as well.

In this case the InDesign template opens up and you can see all the metadata from that national metadata section showing up on the page to create the cover. And then some additional metadata. Now we’re building the table of contents, the front matter, and now we’re working into the body of the document.

Keep in mind that all the content we see being placed on the page at this moment is coming from the ISO XML input file.

And here you can see the Typefi engine working to apply formatting to all of this XML content, and it’s working out the size of the table, and if tables continue across to another page, even the continuation notice appears automatically.

And at this moment cross-references throughout the documents are being resolved. So wherever you see internal references to tables or figures, those are cross-references, and those are being resolved at the moment. And once they’re resolved, the rest of this document will be very quickly paginated.

Here you can see the rest of the document being laid out. There are various tables and graphics being placed. There are a lot of rules going on here, in fact, there are several keep options that keep figures together so that they don’t straddle a page.

And finally the bibliography and a couple of notes pages are added, and then followed by some static back matter and the back page itself.

So that’s what it looks like to use Typefi to work with an input package, run it through Adobe InDesign, and generate that final PDF which is being created as we speak.

When the job is complete, and you see the green check mark, you can just click on that job and collect all the output. And here you see is the final web PDF that was produced from this workflow.

So now I’d like to hand it over to Bruce, who’s going to introduce you to the new upcoming NISO STS model for adoptions.

BRUCE: Thank you very much, Gabriel. As you mentioned, there is a new model for adoptions in the new NISO STS standard that just came out in October of 2017.

In this model we can have two different top level elements. Previously in ISO STS, we could only have standard as a top level element, and now we can have either standard or adoption as a top level element.

Of course, the ISO STS model is fully backwards compatible with ISO STS, but the new model gives you more flexibility.

Before we look at the new model though, let’s look at the existing ISO STS model. It’s a relatively flat model. You can have a front matter section with one or more metadata blocks and special front matter sections, you can have one body section, and then you can have multiple back matter sections; for example, ISO annexes followed by your local adopted annexes.

But as a flat model it’s limited in terms of flexibility.

With the new NISO STS adoption model, it’s a hierarchical model. So you can start with an adoption at the top level, you can nest adoptions within adoptions, and then you can have a standard inside of that.

At the very inside portion of this, you can see we have a standard element and that could be an ISO standard. The inner adoption element would be a CEN adoption that has standard document metadata for that standard as well as the CEN annexes just after the standard element.

And then at the outermost level, you could have the national adoption; for example, a Danish or Swedish adoption. And that adoption would have its own standard doc meta element, and its own back matter as well.

Now one of the interesting things about this model is that the back matter for the national adoption could appear just after the standard doc meta rather than after the adopted information.

This gives you tremendous flexibility in terms of representing, in your XML, the reading order, because some national bodies put all of their adopted material up front, and some national bodies have only their metadata up front and their annexes at the back after the adopted material.

Take another look at how this works. This is actually straight from the NISO STS documentation, where you have an adoption with adoption front matter.

And then, in this case, rather than incorporating all of the XML in, you can have a standard xref element that says this is an adoption, that now pulls in by reference an ISO standard.

This is really really cool, and leads to part of the flexibility that we have with this new model for adoptions.

Not only can we include, as shown in the third bullet point, by standard xref, but we can also include standards with XInclude, for those of you who like using that XML model, or you can have the entire standard or, of course, as Gabriel showed before, you can just incorporate a PDF and you could do that using the standard xref model.

So this model that allows multiple inclusion formats is incredibly flexible, because it allows you to have what the working group calls “reading order” XML; in other words, the order in which you prepare your XML file reflects the order in which the content will be rendered into PDF or HTML or whatever reading format you’re going to render it to.

It’s a recursive model, and it allows multiple level adoptions, much much more flexibly than the ISO STS model. And this means that you can have three or even, if necessary, four levels of an adoption as you go through the adoption process.

There’s lots more information about this model. We’ve included two URLs here if you want to learn more. The first one points to the adoption documentation at the niso-sts.org website, and there’s full documentation including some limited examples of how to do an adoption.

The other is STS4i, which is a group that’s promoting best practices for use of both ISO and NISO STS, has a repository on GitHub, and they actually have a sample of a DIN/EN/ISO adoption that shows all of the layering and shows exactly how you can take advantage of this tagging when you’re doing an entire standard as an adoption.

We hope you’ve enjoyed learning about all of this, and I’m going to hand it back to Gabriel now.

GABRIEL: All right, thanks everybody for watching. If you’d like to watch other webinars in this same series, take a look at the URL below, typefi.com/standardizing-standards, and you’ll see a full listing of previous webinars that you might’ve already missed, and upcoming webinars that you might be interested in.

Standardizing Standards 7: Multilingual Standards Publishing with XML

Transcript

ANTTI SAARI: Hello, my name’s Antti Saari, I’m from the Finnish Standards Association SFS, here to tell you about the way we do multilingual standards publishing with STS XML.

The Finnish Standards Association is a national standards body in Finland, one of three. We do most of our standardization work in ISO and CEN, and work with the other national standards bodies in Finland to also publish and sell national adoptions and translations from CENELEC and IEC.

We also do some Finnish national standards—those are not a big priority for us, but we do publish a few and they are included in the numbers that I’ll show you in our later slides.

Since the topic of this presentation is multilingual standards, I think that we should first define what we mean by a multilingual standard.

In our context, most of what we publish is adoptions of CEN and ISO standards. We publish those in English, the original English text of the standard. We are bound by CEN rules to publish everything or at least adopt everything that they publish, so that accounts for something around a thousand individual standards per year.

Now, we look through those standards and try to find the ones that are particularly interesting to Finnish industry, Finnish stakeholders, and provide a Finnish translation of those CEN and ISO standards.

The Finnish translation that we do does not have the same status as the original text of the standard. We have this disclaimer on the cover page of every translation that we publish, saying that in case there’s anything different about our translation, or if the translation doesn’t seem to match with the original, the original text is the one that applies—follow the original.

So, the customers who buy the translation, we have to provide them with the original text as well. What we call a multilingual standard consists of the Finnish translation and the English original standard in one product, or one PDF right now.

And it has to be made in a way that makes it easy for the user to read through the text in one language and then cross-check with the original text, and then get back to the translation and continue reading.

In terms of numbers, these are from last year, we published around 250 of this kind of multilingual standard. The top row says 268, but like I mentioned before, that includes our national standards as well, so that’s a handful, a dozen, maybe a bit more. There are about 250 translations for multilingual publications.

Of those, we did a bit over 200 in STS XML using a workflow including eXtyles and Typefi, and the rest were done in our old workflow that I’ll cover in the next slide.

The reason we’re not doing everything with STS XML is because sometimes the original standard, the English original coming from ISO, CEN, CENELEC, whoever, is not made in STS XML. And if it’s not made in STS XML then well, we’re not going to do it either.

Our idea is to, when we’re making these multilingual standards, is to use the English XML we get from the international organization as is, and then just add our translation to it. So if we don’t get the English XML, then we just don’t produce an XML publication from it.

The percentage of XML to non-XML is roughly similar to what CEN itself is doing. CEN manages to publish XML with over 80 percent of their publications and we’re in the same ball park.

Now, we’ve been doing this kind of multilingual standard since way before STS XML was a thing. I’m not sure about the exact year we started, but way before my time.

The way we used to do those, and the way we still do anything that we can’t get in XML, is with Adobe FrameMaker and a custom plug-in that we have for that.

I think the main reason this is interesting is that the workflow we had for FrameMaker was, and is, very similar to what we are doing now with eXtyles and Typefi.

So we had a Word file from CEN and ISO. Since we are a member we get all of their output—we get their PDF files, their Word files, and their XML files if they produce them.

We take the Word file, and have it translated so we get another Word file. Someone would go through those Word files and style everything according to our specification, using just Word’s built-in tools.

Then we’d have a plug-in that would read through the Word file, convert it to XML, apply structure, and our editors could work through it in FrameMaker.

The reason we were using FrameMaker is because it allows you to have multiple text flows, among other things. When we started doing standards like this, we were mostly thinking about people reading standards as a physical book where you have actual binding and you have to turn a page, and stuff like that.

So, the idea was, in that book we’d have always the left hand side page in Finnish, and the right hand side page would be in English. FrameMaker lets you do that pretty easily, and our plug-in made it easier still.

The only thing our editors really had to do was to make sure that the standard would proceed in both languages at the same rate. So normally Finnish takes a bit more space than the English does, and they would have to make the Finnish take up less space by using layout tricks like reducing the spacing between paragraphs or between words, or even between letters.

Now, when we moved to our current publishing process with STS XML using eXtyles and Typefi, we also wanted to rethink the end product we have since years have passed and those book standards are not so important anymore.

More people are reading standards on computer screens or even tablets, and if you’re reading a standard on an iPad you can’t really fit more than one page on the screen at a time.

So if you had that kind of book layout we had before, that would mean that every other page is in Finnish and every other page is in English, and that would be really annoying to read if you could only see one page at a time and you were trying to read through it in one language.

So, when we moved to eXtyles and Typefi we just went to rethink that.

Also, there’s the thing that making that kind of change that our editors used to make to compress the space Finnish language takes, is kind of hard to automate. At least, that’s how we felt back in 2014.

I’ve heard now that some of Typefi’s customers are doing the same kind of thing, using Typefi automation to basically make that kind of side by side layout automatically, but in 2014 it seemed difficult for us.

So, the way we’re publishing standards now with eXtyles and Typefi, we have one process that we use for everything that we publish, including our national stuff, and standards from CEN and ISO.

The way the process works—well first of all someone has to decide that ok, we want to translate the standard. So, we send the translator a Word file. We’re still dealing with Word files for the translation part.

And they just type their translation on top of the Word file, or if they have access to special software like Trados, they might import the Word file into Trados and re-export it back into the same structure.

As it happens, the translated Word file we receive will be already styled in the exact same styles that we need for eXtyles to be able to export XML from it. That is because the Word file we send to the translator has already been treated by CEN or ISO, and their editors.

And while it’s possible that the translator might make a bit of a mess with some of Word’s built-in styles—do something unexpected—I’d say 90 percent of the styling work that the eXtyles is used for in this process has already been done in the translation. We really only have to do some minor cleanup at this point.

The reason we are using Word files for translation, even though XML is available, is that the dedicated software that you’d need to do XML translations is kind of expensive. Not all of our translators have access to that software, so that’s an issue.

Also, if you know there’s a mistake in the translation, and the translation only exists in XML, then the only person who can fix it is the guy who has access to the translation software, and so they can re-export the XML.

The only alternative is really to manually fix the XML file and we are trying to avoid that—that’s not something our editors are generally comfortable doing.

So, the part where Typefi comes into this process is where we already have two XML files. The first one is the one we’ve produced in-house—it has all of the translated content of the standard in Finnish, and all of our metadata is in there.

And then there’s the second file. It’s the same XML file as ISO or CEN created and let their members download. It’s the same file, we do not add anything to that file.

We feed those two files to Typefi, and it merges the contents in the order that we want them to be.

So there’s our cover page, then it gets the cover page from CEN coming from the CEN XML file, then comes all the Finnish contents from our XML file, followed by the English contents from the CEN XML file.

Something like that. There are some variations to this, but that’s the general idea.

While Typefi is doing this, every time it sees a section heading it says ok, this section heading came from the Finnish XML file. So Typefi will create a cross-reference to the section heading with the exact same ID attribute value that comes from the English XML file.

Typefi doesn’t check whether that kind of section really exists, it’s just assumed that there will be a corresponding section with this exact same ID attribute. The link is created, and we ensure that there will be a target for that link.

At this point I’ll just quickly show what a PDF file like this looks like.

You’re looking at an SFS cover page of an ISO standard that has been adopted by CEN and then again adopted and translated by us.

So really, this actually has contents from three XML files, one from us, one from CEN, and one from ISO. The general idea is the same.

Now, the first actual section in the standard is the foreword coming from CEN. And right next to the section heading you see a hyperlink. When I click the hyperlink it takes me to the same section in English.

I can scroll through the standard in English, I get the terms and definitions, and there’s a cross-reference to the terms and definitions section in Finnish—so I could do it like this, and now I’m at terms and definitions in Finnish.

That’s basically all there is to it. It’s stupidly simple, even. But it’s kind of convenient I think, it’s an easy way to cross-reference between languages, and you could apply the same idea to online platforms as well.

We’re doing it with PDF files for now, but it’s the same kind of idea behind how you create links and allow the customer to read through the standard in different languages and check the other language.

If that’s the kind of thing you want to do, this is a surprisingly easy way to do it.

Now, being able to do it like this is not a given, I have to stress that. It’s easy for us because when we started our project with eXtyles and Typefi, we copied everything that the ISO had done.

ISO had already started a project, they were publishing everything in XML by that time.

CEN had already started as well, they weren’t quite finished in the sense that they were still developing parts of their project, but they had all the eXtyles templates and customizations were already in place. So we could just march in and get all their stuff.

We wanted our stuff to be as similar as possible to what they were doing, so we just told eXtyles and Typefi, don’t make any customizations, just give us what they’re doing and we’ll work with that.

What that leads to is that when we have sections, all sections do have an ID attribute. That’s something that the ISO and CEN have decided, and that’s something that we’ve decided to follow them on, so it’s easy for us to always assume that ok, we have a section heading, we can create this kind of hyperlink, because the ID attribute will be there.

Similarly, the ID attribute values need to match because, like I said, we are not actually trying to look for a matching section in the other language, we’re just assuming that a section with the exact same ID will be there. So that means that the section ID schemes must be the same in the translation and in the original text.

I’m bringing this up because in the NISO STS, the official documentation for ID attribute—I have to speak here from the documentation—and it shows an ID attribute with the value s6.7.1.5.

I suppose that’s a good way to identify your section 6.7.1.5 but that is different from what ISO is actually doing, and what CEN is doing, and what we’re doing.

So, if someone were to look at the NISO STS documentation and decide that ok, this is how the section IDs work in the examples, we’re going to do exactly that, it would make sense for them.

But if we wanted to produce a translation and a bilingual standard using that XML from that organization, we would be in trouble, because our ID attribute schemes do not match. Well, it wouldn’t be hard, but we would have to create some kind of mapping to be able to match them.

All in all, these are not huge issues, we have some custom sections there to handle national content and we’ve created workarounds for them, but all in all this is a pretty easy thing to do.

Now, how has this all worked out for us? This shows how many pages per year we’re publishing. Our production of STS XML started in full in the middle of 2015, and in 2016 we were using STS XML / eXtyles / Typefi as our main publishing process.

The page count in those two years was pretty ok, normal. The amount of pages isn’t really limited by what we can publish, it’s more limited by what our translators are able to produce, so if they produce 17,000 pages of translations then that’s what we publish. No more, and no less.

The thing to take away from this is that the page count is normal, it’s the same as it was before.

Which takes me to the next slide. On top, the line shows how many days it took from when a draft translation was first submitted to our publishing department, to when there was a ready translation, ready to be sold to our customers.

You can see a fairly dramatic drop in there, almost a month compared to 2015. But in 2015 we had a lot of issues because, you know, we were starting this whole new publication process that took a lot of resources.

But even compared to the previous years when we were still completely using the old system, we’ve managed to decrease the amount of time it takes to create a publication by quite a lot.

And, furthermore, we’re doing it with a lot less effort required. The bars or columns on the bottom show how many person-years we’ve worked in our publishing department per year. So it’s not just creating those translations, it’s everything that our publishing department does, including creating advertisement materials and publishing the thousand adoptions that we do, all that stuff.

The amount of work, you can see, has gone down a lot, by what, one and a half person-years compared to when we were only using the XML method.

Compare it to 2014 when we produced a very comparable amount of pages, also 17,000, but we had over eight people working to create those pages.

So we’re doing a lot of pages, we’re doing it faster than before, and we’re doing it with less work required than before.

That’s all from me, thank you for listening.