Sustainability of Digital Formats: Planning for Library of Congress Collections |
|
![]() |
|
Introduction | Sustainability Factors | Content Categories | Format Descriptions | Contact |
Full name | ODF 1.1 Package. OASIS name: Open Document Format for Office Applications (OpenDocument) v1.1. ISO name: ISO/IEC 26300:2006, Information technology -- Open Document Format for Office Applications (OpenDocument) v1.0 |
---|---|
Description |
An ODF package is a container that holds a collection of parts, aggregating components of a document (or other type of content) into a single object. The packaged document may be a word-processing document, a spreadsheet, a presentation, a chart, a drawing, etc. The ODF package is based on the ZIP File Format [ZIP_PK]. This description for ODF_package_1_1 covers versions 1.0 and 1.1 of ODF as published by OASIS. It also covers ISO/IEC 26300:2006, which aligns with version 1.1 as published by OASIS when supplemented by Amd 1:2012. The ODF package is specified in clause 17 of the OASIS ODF 1.1 specification, which is essentially identical to the same clause in the OASIS ODF 1.0 specification. Versions 1.0 from ISO/IEC and 1.1 from OASIS referred to an unofficial variant of PKWARE's appnote.txt from Info-ZIP. This adaptation of PKWARE's specification explicitly removed some capabilities for encryption and other services patented by PKWARE. The Info-ZIP software was used widely as a library for working with an interoperable open subset of the ZIP format. The open source Info-ZIP project has not seen much action since early 2009, although betas have been released since then. In ODF_package_1_1, compression is restricted to the "deflate" algorithm. A single encryption mechanism is specified for ODF_package_1_1. Encryption mechanisms as defined in APPNOTE.TXT for ZIP_PK are not permitted. Digital signatures are not supported in ODF_package_1_1. Note that ODF 1.2 uses PKWARE's version 6.2.0 of APPNOTE.TXT [see ZIP_6_2_0]. The compilers of this resource are not aware of substantive differences in the intent of the ZIP specifications in ODF 1.0-1.2 or among software implementations creating ODF files. Comments welcome. A manifest file is mandatory in all ODF document packages. It must be named META-INF/manifest.xml. It contains a list of files in the package, their media types (MIME types), and information required for decrypting each file as relevant. Also mandatory in this ZIP-based package is a "stream" that provides a magic number for identifying a file as an ODF document of a particular category. From section 17.4 of the ODF 1.1 specification: 'the package should contain a stream called "mimetype". This stream should be first stream of the package's zip file, it shall not be compressed, and it shall not use an "extra field" in its header ... The purpose is to allow packaged files to be identified through "magic number" mechanisms, such as Unix's file/magic utility. If a ZIP file contains a stream at the beginning of the file that is uncompressed, and has no extra data in the header, then the stream name and the stream content can be found at fixed positions. More specifically, one will find:
Although the ODF 1.1 specification uses the term "stream," the magic number requirement is equivalent to including a text file with the specified character string as the first file in the ZIP archive. |
Production phase | An ODF package can be used in any production phase. |
Relationship to other formats | |
Subtype of | ODF_family, OpenDocument Format (ODF) Family, OASIS and ISO/IEC 26300 |
Has subtype | ODF_text_1_1, OpenDocument Text Document Format (ODT), Version 1.1, ISO/IEC 26300:2006 |
Has subtype | ODF_spreadsheet_1_1, OpenDocument Spreadsheet Format (ODS), Version 1.1, ISO 26300:2006 |
Has subtype | Formats for various other content categories, including for presentation files, not described separately on this website. |
Subtype of | ZIP_PK, ZIP File Format (PKWARE). Various features of the ZIP File Format are not permitted in ODF. |
Contains | META-INF/manifest.xml file. This manifest file is mandatory in all ODF packages. |
Has earlier version | ODF 1.0, not described separately at this site. Section 17 of the specifications for ODF 1.0 and ODF 1.1, where the package format is specified, are essentially identical. |
Has later version | ODF_package_1_2, OpenDocument Package Format, ODF 1.2 |
Defined via | XML_1_0, XML (Extensible Markup Language) 1.0. A normative RELAX NG schema for manifest.xml is part of the specification for ODF_package_1_1. |
LC experience or existing holdings | See ODF_family. |
---|---|
LC preference | See ODF_family. |
Disclosure | International open standard. Developed and maintained by OASIS Open Document Format for Office Applications (OpenDocument) TC. |
---|---|
Documentation |
Specifications from OASIS: Open Document Format for Office Applications (OpenDocument) Specification v1.1; Normative RNG schema for mandatory.manifest file. Specification for ODF 1.0 published as ISO/IEC 26300: ISO/IEC 26300:2006, Information technology -- Open Document Format for Office Applications (OpenDocument) v1.0 and Amd 1:2012, to align with OASIS version 1.1. |
Adoption |
The major applications supporting ODF can read and write files in ODF 1.1. Lists of approved formats may or may not be specific about the ODF versions recommended; however, as of early 2015, ISO/IEC 26300:2006, Information technology -- Open Document Format for Office Applications (OpenDocument) v1.0, which is equivalent to ODF 1.1 from OASIS and thus to ODF_package_1_1, is frequently the version cited. This is probably because ODF_package_1_2 was not published until June 2015 as an ISO/IEC standard. Such citations should not be interpreted as preferences for the earlier version. See ODF_family for more detail. |
Licensing and patents | No concerns. See ODF_family. |
Transparency |
As a container, transparency corresponds to that of ZIP_PK. It depends upon algorithms and tools to interpret and extract contents. It would require sophistication to build tools from scratch, but many tools exist. The files that represent the structure of the ODF package are all in XML and thus both human readable and easily machine processable. Transparency ultimately depends on the files contained in the package. Files may be encrypted. |
Self-documentation |
The built-in support for metadata in the package specification per se is limited to structural metadata to support extraction of component files. ODF 1.1 support for metadata is through three mechanisms defined in clauses 2.2 (Document Metadata) and clause 3 (Metadata Elements) of the OASIS ODF 1.1 specification: predefined elements explicitly listed in the specification; user-defined metadata, using a specified XML structure for a triplet of name, data type, and value; and custom metadata, held in arbitrary elements within the <office:meta> element. The ODF 1.1 specification requires implementers to preserve custom metadata. Note that the use of arbitrary custom metadata was deprecated in ODF 1.2 and replaced by support for RDF-based metadata. Pre-defined metadata elements for the document as a whole include:
The pre-defined elements are all optional and repeatable. However, applications are not required to update multiple occurrences in a specific way to reflect modifications to a document. |
External dependencies | Depends on files contained in the package. |
Technical protection considerations | Encryption is supported for files within an ODF package. In addition, an ODF package file may be encrypted during interchange or as part of DRM controlling distribution. |
Other | |
---|---|
Bundling/compression | Separate functionality factors for comparing formats that are used to bundle and or compress files have not been developed. From the perspective of digital preservation, consideration of the sustainability factors above is more important than the degree of compression. |
Tag | Value | Note |
---|---|---|
Filename extension | See note. | ODF package files use extensions appropriate to the type of document packaged. Hence, .odt, .odp, .ods, are all extensions used for ODF packages. |
Internet Media Type | See note. | ODF package files use MIME types appropriate to the type of document packaged. The appropriate MIME types are listed in Appendix C of the OASIS specification for ODF 1.1. They use the pattern application/vnd.oasis.opendocument.xxx. See for example, registration for ODF spreadsheet category at IANA. |
Magic numbers | See note. | Magic numbers that apply to document category subtypes, incorporate the magic number for ZIP_PK, the string mimetype at position 30, and the MIME subtype string value at position 38. See, for example, registration for ODF spreadsheet category at IANA. |
Indicator for profile, level, version, etc. | ASCII: office:version="1.0" ASCII: office:version="1.1" |
The four root elements used in the primary files in an ODF package all permit an attribute that records the ODF version. |
Pronom PUID | See note. |
PRONOM has no PUID specifically for the ODF 1.1 container format. See https://www.nationalarchives.gov.uk/PRONOM/fmt/135 (PUID: fmt/135) for ODF 1.0. |
Wikidata Title ID | See note |
Wikidata has no Title ID specifically for the ODF 1.1 container format. Title IDs are assigned to many subtypes in the ODF_family of document formats. |
General | |
---|---|
History |
See ODF_family for the early history of ODF. Section 17, the package specification for ODF, is essentially identical in version 1.0 and 1.1 of the ODF specification from OASIS. There were no significant changes to section 17 in Errata 01 to ODF 1.1, approved by OASIS in 2013. ODF 1.2, including the package specification in Part 3, was approved as a three-part OASIS standard in September 2011. ODF 1.2 was approved by ISO/IEC JTC1/SC34/WG6 in September 2014 and published as an ISO/IEC standard in June 2015. See ODF_package_1_2. |
|