Balisage: The Markup Conference 2026 August 3-7, 2026 This paper examines how the roles of XML schemas—sanity checking and documentation—differ depending on their ecosystems, by comparing EPUB and Office Open XML (OOXML). In the EPUB ecosystem, schemas primarily serve as validation artifacts to ensure content quality throughout the distribution pipeline. In contrast, the OOXML ecosystem lacks mandatory validation during distribution. However, a validation experiment suggests that third-party office suites produce nearly valid XML once Markup Compatibility Elements (MCE) are preprocessed. This demonstrates that OOXML schemas function successfully as documentation artifacts, guiding developers in software quality assurance to achieve interoperability. Makoto MURATA Then-member of the W3C XML WG Visiting professor Higashi Nippon International University Founder Information Accessibility Institute, LLC eb2mmrt@gmail.com Copyright © 2026 by the author. Used with permission.

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.

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: Authoring: Content creators validate EPUB files before submission. Content aggregation: Distributors re-validate files to ensure consistency. Ebook stores: Final validation is performed before distribution to end users. 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.

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.

The comparison between EPUB and OOXML reveals that the key difference is not simply the strictness of validation, but where validation takes place. In general, validation can occur in at least two distinct contexts. One is validation performed within an ecosystem as part of a distribution pipeline. The other is validation performed during software development to ensure that implementations correctly follow a specification. These two forms of validation lead to fundamentally different roles for schemas.

In the EPUB ecosystem, validation is performed at multiple stages before content is consumed. Authors validate their publications, content aggregators re-validate them, and ebook stores perform additional validation before distribution. This process is typically repeated many times for a single publication. Because EPUB publications must function across a wide range of reading systems, strict validation is essential. The de facto authority is epubcheck, which integrates RELAX NG, Schematron, and additional checks. Validation results directly affect whether a publication is accepted or rejected in the distribution pipeline. In this environment, schemas primarily serve as components of a validation framework. They contribute to the enforcement of constraints across the ecosystem, ensuring interoperability among heterogeneous implementations. Although schemas formally describe the structure of EPUB documents, they are not the primary source of documentation; this role is fulfilled by the specification text. Thus, in EPUB, schemas function mainly as validation artifacts, supporting ecosystem-level enforcement of correctness.

In contrast, validation in the OOXML ecosystem is not performed as part of a distribution pipeline. End users and document producers do not typically validate documents. Instead, correctness is determined by whether Microsoft Office can successfully open and process a file, often repairing errors automatically. Despite the absence of ecosystem-level validation, independently developed office suites generate XML that is remarkably close to the schemas. This suggests that validation is actively used during software development rather than during document distribution. Developers of office applications appear to rely on schema validation to verify their implementations and to ensure interoperability with Microsoft Office as well as other office applications. In this context, schemas provide a precise and machine-readable description of the document structure, enabling developers to understand and reproduce complex behaviors. Thus, in OOXML, schemas function primarily as documentation artifacts consumed during development, rather than as enforcement mechanisms applied during distribution.

These observations highlight a dual nature of schemas. Schema technologies can support fundamentally different workflows depending on where validation is located. In EPUB, validation is performed by the ecosystem before content is consumed. Schemas are integrated into a validation framework and are used to enforce correctness across multiple actors. In OOXML, validation is performed by developers during implementation. Schemas are used as a reliable and precise form of documentation, guiding the development of interoperable software. This distinction suggests that the role of schemas is not determined solely by their formal expressive power, but by the structure of the surrounding ecosystem. When validation is externalized and repeated across a distribution pipeline, schemas become enforcement tools. When validation is internalized within development processes, schemas become a form of executable documentation.

This paper has compared EPUB and OOXML from the perspective of how schemas are used in practice. The comparison shows that the role of schemas depends strongly on where validation takes place. In EPUB, validation is carried out throughout the distribution pipeline by multiple actors, and schemas are used as part of a framework that enforces correctness before content is consumed. In OOXML, validation is not part of the distribution process but is instead used by developers during implementation. As a result, schemas are primarily used to understand and reproduce the document structure. These two cases illustrate that schemas can play different roles. They can serve as validation artifacts in a distributed ecosystem, or as a form of precise documentation in a development context. This observation suggests that discussions about schemas should not focus only on their expressive power or formal properties. It is equally important to consider the ecosystem in which they are used, including how documents are created, distributed, and implemented. Rather than converging to a single ideal model, schemas appear to adapt to their environments. EPUB and OOXML demonstrate two stable and successful patterns, each reflecting different assumptions about interoperability and system design.

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.

EPUB 3.3. W3C Recommendation. 2023. Available at: https://www.w3.org/TR/epub-33/ EPUB 3 Overview. IDPF Recommended Specification. 11 October 2011. https://idpf.org/epub/30/spec/epub30-overview.html ISO/IEC 29500-1:2016. Information technology — Document description and processing languages — Office Open XML File Formats — Part 1: Fundamentals and Markup Language Reference. ISO/IEC 29500-3:2015. Information technology — Document description and processing languages — Office Open XML File Formats — Part 3: Markup Compatibility and Extensibility. EPUBCheck: The official conformance checker for EPUB publications. Available at: https://github.com/w3c/epubcheck ISO/IEC 19757-2:2008. Information technology — Document Schema Definition Languages (DSDL) — Part 2: Regular-grammar-based validation — RELAX NG. ISO/IEC 19757-3:2025. Information technology — Document Schema Definition Languages (DSDL) — Part 3: Rule-based validation — Schematron. ISO/IEC 19757-4:2006. Information technology — Document Schema Definition Languages (DSDL) — Part 4: Namespace-based Validation Dispatching Language (NVDL). W3C XML Schema Part 1: Structures Second Edition. W3C Recommendation. 2012. Available at: https://www.w3.org/TR/xmlschema-1/ The Nu Html Checker. Available at: https://validator.w3.org/nu/