Balisage Paper: Schemas in EPUB and OOXML: Sanity Checking versus Documentation

Introduction

Schemas play an essential role in XML technologies. A schema defines constraints on the structure and values of documents in a specific XML-based language.

Schemas are generally understood to serve two primary purposes: sanity checking and documentation. For sanity checking, they enforce structural constraints and detect invalid documents. As documentation, they provide a formal description of these constraints, enabling developers to understand and implement the language.

However, the relative importance of these two roles varies significantly depending on the ecosystem in which an XML-based language operates. This paper examines how these roles differ by comparing two major document formats: EPUB and Office Open XML (OOXML). The observations in this paper are informed in part by the author’s experience as the then-leader of the EPUB 3 Internationalization sub-group and as convenor of ISO/IEC JTC 1/SC 34/WG 4 for OOXML.

Schemas and Validation in EPUB

EPUB is a widely used standard for digital publications, originally defined by the IDPF and now maintained by the W3C. An EPUB publication consists of XHTML and SVG content, CSS stylesheets, and other XML resources such as packaging and navigation documents.

While EPUB includes schema definitions in RELAX NG, validation in practice is carried out using epubcheck, a comprehensive validator that combines schema-based validation with additional checks beyond what schemas alone can express. As a result, epubcheck serves as the de facto validation mechanism in the EPUB ecosystem.

The EPUB validation framework is not based on a single schema language. While most structural constraints are expressed using RELAX NG, additional rules are specified using Schematron. Furthermore, NVDL is used to combine RELAX NG validation and Schematron validation. This multi-layered approach reflects the need to express constraints that cannot be captured by a single schema language alone and results in a framework in which a wide range of constraints are systematically checked by epubcheck.

Although such schema definitions exist, they are not commonly used as a primary source of documentation. Instead, structural details—such as element ordering and constraints on attribute values—are described in the specification text. Schemas therefore appear to be used mainly for validation rather than for understanding the document structure. Moreover, parts of the schemas have been adapted over time in response to validation requirements. For example, XHTML-related validation has come to rely on mechanisms aligned with those used in validator.nu, while SVG-related constraints have been relaxed to avoid overly strict validation. Similarly, schemas related to digital signatures and encryption have undergone slight adjustments at the root level. These observations indicate that the schemas have evolved not only as part of the specification, but also in response to practical validation needs. Schemas are now maintained as part of epubcheck and are referenced from the EPUB 3 specification.

A key characteristic of the EPUB ecosystem is that validation is performed at multiple stages:

Not only errors but also warnings reported by epubcheck may lead to rejection. This reflects the strict requirements of a distributed ecosystem, where EPUB files must function correctly across a wide variety of reading systems, such as Apple Books and Thorium Reader.

Because validation is performed by multiple actors and across multiple distribution channels, it is typically repeated many times for a single publication. During the authoring process, validation may be performed iteratively until no errors—and often no warnings—are reported. Moreover, validation is not static: new versions of epubcheck may introduce updated rules, prompting the re-validation of existing publications.

Given the large number of commercially distributed EPUB publications—on the order of hundreds of thousands or more—the cumulative number of validation operations is substantial.

Thus, in the EPUB ecosystem, schemas primarily support sanity checking, and validation is an essential part of the distribution pipeline. In practice, schemas serve mainly as validation artifacts, while the specification text functions as the primary source of documentation. Conformance is effectively determined by epubcheck rather than by any specific EPUB reading system.

Schemas and Validation in OOXML

OOXML was standardized to provide XML vocabularies for word-processing documents, spreadsheets, and presentations, replacing the proprietary binary formats previously used by Microsoft Office while faithfully representing the existing corpus of Office documents.

Unlike the EPUB ecosystem, the OOXML world is characterized by the overwhelming dominance of a single major implementation: Microsoft Office. In this ecosystem, the de facto standard is the behavior of Office itself; whether a document can be opened by Office is the ultimate measure of correctness. Office does not perform schema-based validation when opening files; instead, it attempts to repair incorrect OOXML documents (including those having validation errors). This tolerance is not a new feature introduced with OOXML, but rather a continuation of behavior established in legacy binary formats, where documents were often partially corrupted or produced by heterogeneous tools. Consequently, the concept of validation as a mandatory checkpoint in the distribution pipeline does not exist in the OOXML ecosystem .

However, this does not mean that the OOXML schemas (XSD) are useless. On the contrary, they are highly successful as a foundation for developers. To investigate this, the author validated document.xml files generated by four major office suites: LibreOffice, WPS Office, Google Docs, and Microsoft Word. The source document was a draft JIS specification for LCP (Licensed Content Protection), a substantial real-world document containing a variety of structures commonly found in standards documents, including headings, lists, tables, cross-references, hyperlinks, images, and extensive styling information.

Before validation, a necessary preprocessing step was performed to handle Markup Compatibility and Extensibility (MCE). MCE is a mechanism in OOXML designed to support forward compatibility and application-specific extensions, often utilizing elements such as mc:Ignorable to allow foreign elements and attributes, and mc:AlternateContent to provide fallback structures for unknown elements. Because these extension elements and attributes are not defined in the OOXML schemas, passing raw document.xml files directly to an XSD validator would inherently result in errors. After MCE preprocessing, the validation results showed little difference among the four products.

Surprisingly, all four tools produced almost entirely valid XML. Microsoft Word produced no validation errors, while the other office suites produced only a very small number of errors. The observed errors were minor schema-conformance issues, such as missing elements or attribute values that did not exactly match schema constraints. Although the exact errors differed among products, none represented a substantial deviation from the OOXML schemas.

While schema validation is not used within the OOXML distribution ecosystem, this remarkable level of validity strongly suggests that developers of office suites actively use schema validation during software development and testing. Without such validation, it would be difficult to explain why independently developed office suites generate XML that is so closely aligned with the schemas. Thus, developers appear to rely heavily on OOXML schemas as a precise documentation tool for understanding the specification and achieving interoperability.

Discussion: Comparing EPUB and OOXML

Acknowledgments / Dedication

I would like to express my deep gratitude to my colleagues in ISO/IEC JTC 1/SC 34/WG 4, with whom I worked closely on the standardization of OOXML, as well as my colleagues at W3C and the former IDPF, who collaborated with me on EPUB. The practical observations presented in this paper were heavily informed by the invaluable discussions and shared experiences within these standardization communities. I am also grateful to my colleagues from the XML Working Group and the schema language community, with whom I shared many years of discussion on markup and validation technologies. The practical observations presented in this paper were heavily informed by the invaluable discussions and shared experiences within these standardization communities.

Finally, I would like to dedicate this paper to the memory of Michael Sperberg-McQueen. Even before XML started, at an SGML conference, he generously praised a paper I presented. His warm encouragement and profound understanding of markup theory left a lasting impression on me. That early encounter guided me throughout my decades of work in the markup community—from the days of the XML specification and the development of schema languages, all the way to the standardization of both EPUB and OOXML. I can think of no better way to close this paper than by offering this practical observation on schemas and ecosystems to him—a true giant of our community who always believed that there is nothing so practical as a good theory.