Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 26300-1:2015 Open Document Format v1.2 — OpenDocument Schema
The XML schema and semantics for open, vendor-neutral office documents including text, spreadsheets, presentations, and drawings
1. Overview of the OpenDocument Format
ISO/IEC 26300-1:2015 defines the Open Document Format for Office Applications (OpenDocument) v1.2, Part 1: OpenDocument Schema. This standard specifies an XML schema for office documents and its semantics, suitable for text documents, spreadsheets, charts, drawings, presentations, and other document types. It was originally developed by OASIS and adopted by ISO/IEC JTC 1 under the Publicly Available Specification (PAS) procedure.
The OpenDocument format is designed to provide an open, XML-based file format that can be implemented by any office application vendor, ensuring long-term access to data without dependence on any specific product or vendor. It is the standard file format for LibreOffice, Apache OpenOffice, and many other office suites.
ODF’s vendor-neutral design makes it the preferred format for government archives and long-term document preservation. Unlike proprietary formats, ODF guarantees that documents remain accessible even decades later, regardless of which software vendor is dominant.
2. Document Structure and Types
The standard defines a comprehensive document model with multiple document types and a modular structure:
| Document Type | XML Root Element | Primary Use |
|---|---|---|
| Text Document | |
Reports, letters, books, articles |
| Spreadsheet Document | |
Data tables, calculations, charts |
| Drawing Document | |
Vector graphics, diagrams, flowcharts |
| Presentation Document | |
Slide shows, presentations |
| Chart Document | |
Standalone charts and graphs |
| Image Document | |
Raster or vector images with metadata |
| Formula Document | |
Mathematical formulas |
| Database Front End Document | |
Database forms, reports, queries |
A single OpenDocument file can be represented in two ways:
- Single XML file: All content, styles, and metadata in one XML document using the
- Package (ZIP): A ZIP package containing separate XML files for content, styles, metadata, and settings. This is the more common approach and uses file extensions like
.odt,.ods,.odp, etc.
When implementing ODF support, the package approach offers significant advantages: styles and metadata can be cached separately from content, incremental saves update only changed components, and the manifest provides a clear inventory of all document resources.
3. Core Schema Components
The OpenDocument schema is organized into several major component areas:
Metadata Framework: ODF v1.2 introduces a sophisticated metadata framework with three complementary approaches — RDF metadata embedded using RDFa within content, a separate manifest.rdf file within the package, and traditional pre-defined metadata elements (title, creator, date, etc.) in the
Content Model: The content model covers text structures (headings, paragraphs, lists, sections), tables with spreadsheet capabilities, change tracking, field elements, text annotations (ruby, notes), and various content types including drawings, charts, and media objects.
| Schema Area | Key Elements | Purpose |
|---|---|---|
| Text Content | |
Document body text structure |
| Tables | |
Tabular data and spreadsheets |
| Styles | |
Formatting and layout definitions |
| Drawing | |
Vector graphics and shapes |
| Presentation | |
Slideshow configuration |
4. Engineering Insights for ODF Implementation
Key technical considerations for developers implementing ODF support:
- Namespace management: The ODF schema uses a rich set of XML namespaces. Correct namespace handling is essential for valid documents. Developers must properly declare and use namespaces like
urn:oasis:names:tc:opendocument:xmlns:text:1.0,...:table:1.0,...:style:1.0, and many others. - Style inheritance: ODF styles follow a hierarchical inheritance model. Automatic styles override common styles, and inline styles override automatic styles. Understanding this hierarchy is critical for correct rendering.
- Change tracking: ODF v1.2 includes sophisticated change tracking with insertion, deletion, and format-change elements. This enables multi-user collaborative editing workflows.
- Package handling: The ODF package is a standard ZIP archive with specific conventions. The
mimetypefile must be the first entry (stored, not compressed), and theMETA-INF/manifest.xmlfile describes the package contents.
One common pitfall in ODF implementation is incorrect handling of the
mimetype file in the ZIP package. It MUST be stored without compression as the first entry in the archive. Many ZIP libraries compress entries by default, which can produce invalid ODF packages that some applications will reject.Frequently Asked Questions
Q: What is the relationship between ODF v1.2 and ISO/IEC 26300-1:2015?
A: ISO/IEC 26300-1:2015 is the ISO/IEC adoption of the OASIS Open Document Format v1.2 specification Part 1 (OpenDocument Schema). The content is identical — the ISO/IEC standard adopts the OASIS standard under the PAS procedure.
Q: Can ODF files be converted to and from other formats like DOCX or PDF?
A: Yes. Most major office suites (LibreOffice, Apache OpenOffice, Microsoft Office, Google Docs) support ODF import and export. Conversion quality varies depending on the complexity of formatting and features used. For best fidelity, staying within the ODF-native workflow using LibreOffice or Apache OpenOffice is recommended.
Q: How does ODF handle embedded media and fonts?
A: ODF packages can embed media files (images, audio, video) directly using standard ZIP compression. Font embedding is supported through the
Q: Is ODF suitable for real-time collaborative editing?
A: ODF v1.2 itself is a file format standard, not a real-time protocol. However, its change tracking features and XML-based structure make it suitable as a foundation for collaborative editing systems. Implementations can leverage the tracked changes and document comparison features to merge concurrent edits.
