Introduction

XML schemas are often “enabling, not prescriptive” – they allow the same content to be marked up in multiple ways. However, processing tools such as HTML renderers tend to be inflexible with respect to handling these variations in input markup. This creates challenges when receiving documents from other parties even if they purportedly use the same vocabulary or the same schema version.

In addition to differing markup conventions, naming conventions, folder locations or file formats for graphic files may differ from the conventions that the receiving part established. This means that either the receiving party’s tools need to become more flexible, or the input needs to be normalized according to the receiving party’s conventions.

The well-established Schematron Quick Fix approach can help with normalization, but it is intended for interactive use. For example, DIN needed to normalize more than 80,000 ISO standards so that they fit into DIN’s semantic extraction or HTML rendering pipelines. This called for a batch processing approach.

ISO itself reportedly has a monolithic XSLT that transforms their legacy content to the latest NISO STS content. Schematron Batch fixes, in contrast, are non-monolithic by design. Only when a construct in the input is found, by Schematron, not to comply with the markup expectations, SBF will apply a small XSLT stylesheet whose purpose is to fix only this thing. This permits processing arbitrary input: Legacy STS input doesn’t use the adoption model. If a standard top-level element is detected and if it contains multiple sets of metadata, an XSLT fix will try to identify the core standard and wrap it in adoption elements that correspond to the additional metadata blocks. There is an SDO who uses JATS in order to mark up their standards. When JATS is detected, a dedicated transformation to NISO STS is be applied. Putting all these potential fixes into a monolithic XSLT will create priority conflicts and maintenance nightmares.

Different receiving parties employ different conventions on how to mark up their standards: One party wants to mark simple inline formulas using JATS-/STS-native vocabulary, others want to have them encoded as MathML. One party wants to have lists embedded in paragraphs, others want to have lists separated from introductory paragraphs (HTML-like block-level elements). One party wants to have footnotes grouped at the end of section, other parties wants them inline or in the backmatter. One party has strict rules on how XML IDs are formed, and their rendering tool use these IDs to detect whether it’s a regular or a so-called national footnote that is rendered differently; another party uses UUIDs or other generated IDs. Even within the same organization, there are different output expectations: DIN’s STS-processing tools (HTML renderer, ReqIF converter) require STS that the newly introduced online editor chokes on. So they need a different SBF correction & checking profile that prepares their STS content for the online editor.

However, there are common rules for sanitizing arbitrary input, such as applying the nested adoption model to adopted standards. Not only do these modularity requirements rule out monolithic XSLT transformations, but also Schematron’s built-in parametrization capabilities, such as abstract rules and patterns, phases, and extensions fall short. Even if two parties mark the same thing as undesired, for example, inline footnotes, the selected fix might be different for each party: One party wants fn-group elements at the end of sections and inline xref elements with repeated footnote labels, the other party might prefer fn-group elements in the backmatter and empty xref elements so that the HTML renderer can insert the footnote label in the output.

This is why the Schematron Batch Fix methodology comes with its own Schematron assembly mechanism: A specialized schema can build on more general schemas. In doing so, it can disable, replace or extend the fixes that are contained in the base schemas. The Schematron Batch Fix vocabulary also allows declaring dependencies between fixes, so that a subsequent fix can rely on a certain normalization to have already taken place before it runs.

While the previous examples are all taken from NISO STS, the concept can obviously be applied to arbitrary XML vocabularies. The current pipeline allows output only to be NISO STS, the only option is whether to produce a DOCTYPE declaration for version 1.0 or 1.2. The current re-implementation will make this more flexible.

But the main new feature that the re-implementation will provide is this: Apart from XML files proper, anything else can be validated – and fixed – for which an XML representation can be obtained, such as directory listings, Zip archive contents or image resolutions, colorspaces, file formats, etc.

This creates at least two challenges:

  1. A Schematron schema is intended to be applied to a single document. Checking both a directory listing XML representation for correct paths/filenames and the XML files in that directory can only be done by a single Schematron schema if the XML files’ content are expanded in-place at the locations where they are referenced in the directory listing. But this will disable Schematron checks that, for example, apply to a context /standard because standard is no longer a top-level element.

  2. Renaming files or moving them to a different subdirectory can only be done in XSLT with extension functions that require commercial XSLT processor versions. Apart from specialized applications, the basic SBF tool should run on open-source software such as Saxon HE and XML Calabash. An XProc processor makes it easier to integrate external tools such as image converters.

The latter requirement leads to extending SBF so that in addition to XSLT fixes, also XProc fixes can run on the checked data. For example, when a Schematron check of the Zip archive manifest XML determines that images need to be moved to another folder, the XProc fix can also process the XML files in the Zip archive and adjust the graphic location URIs accordingly.

In order to address the first requirement, an SBF correction and checking profile no longer needs to be a single Schematron file. It can be a collection of Schematron files, with an NVDL (Namespace-based Validation Dispatching Language) bracket around them: If the XML data at hand is an Zip archive manifest (c:archive) or a directory listing (c:directory) in the namespace xmlns:c="http://www.w3.org/ns/xproc-step", other checks and fixes are applied than if the input is in no namespace, as is the case for NISO STS. For NISO STS, one of the currently defined Schematron schemas may be used unaltered. (Please note that in a Zip archive with NISO STS XML and images, it is unlikely that there are other XML files in no namespace present. A SBF correction & checking profile is always targeted at specific XML vocabularies, it does not need to be prepared to fix any non-namespace XML. In the case of the SDO that encodes their standards as JATS there is already a fix in place that transforms a JATS article into a NISO STS standard, so this choice of NVDL seems vindicated.)

References

[STS4i 2018] Imsieke, Gerrit. STS4i. Standards Tag Suite XML for Interoperability. Presented at JATS-Con 2018. https://subversion.le-tex.de/common/presentations/2018-04-17_JATS-Con_STS4i/slides/index.html [accessed 2026-06-26].

[SBF 2024] Imsieke, Gerrit, Scholle, Paul. sbf.rng commit history. https://github.com/sts4i/sts4i-tools/commits/master/schema/sbf/sbf.rng [accessed 2026-06-26].

Gerrit Imsieke

Gerrit is managing director at le-tex publishing services, a mid-size preprint services, data conversion, and content management software company in Leipzig, Germany. A physicist by training, he entered the field of scientific publishing during his graduate studies. He is responsible for XML technologies at le-tex. He is a member of the NISO STS Standing Committee and of the XProc community group.