Balisage Paper: Schematron Batch Fixes
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).
Abstract
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.
Table of Contents
- Introduction
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:
-
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.)