Balisage: The Markup Conference 2026 August 3-7, 2026 This truly late-breaking (because unfinished) paper describes a non-interactive input normalization process that was introduced at DIN, the German standardization body, for (N)ISO STS XML in 2017. In 2024, it was named “Schematron Batch Fix” (SBF) and successfully applied to heterogeneous input from 10 different standards development organizations (SDO) so that the files could be processed with DIN’s tools that rely on specific markup conventions. At the same time, a schema for the SBF extension vocabulary was introduced. If a Schematron check detects an error, an XSLT fix (a transformation with a specific stylesheet in a specific mode) is applied. This paper will document the layered Schematron schema extension mechanism that the SBF schema permits: An extending Schematron schema may build on a base schema but add, replace or remove fixes. It can also specify dependencies among fixes (fix B needs to run after fix A because it needs input that has already been normalized by fix A). The process is orchestrated by an XProc pipeline that will re-run all the checks after all fixes have been applied. It will report which of the fixes have been successful at which input locations. In addition to documenting the existing Schematron extension and assembly mechanism, this paper, once finished, will cover new developments that are currently under way: Migration from XProc 1 to XProc 3 and, more importantly, the addition of a new class of fix in addition to the current XSLT fix: XProc fixes. While XSLT fixes are limited to fixing XML input, XProc fixes will be able, for example, to rename or convert image files in an input package. And while the current implementation is narrowly focused on producing NISO STS output, the migrated pipeline will be vocabulary-agnostic. This paper will argue that fine-grained fixes are more maintainable and composable than monolithic conversion pipelines, and that they are applicable to a wide range of input formats. 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. Copyright (c) 2026 by the author. Licensed under Creative Commons Attribution 4.0 International License (CC BY 4.0).

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: 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. 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.)

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]. Imsieke, Gerrit, Scholle, Paul. sbf.rng commit history. https://github.com/sts4i/sts4i-tools/commits/master/schema/sbf/sbf.rng [accessed 2026-06-26].