Open Document Format for Office Applications (OpenDocument) Version 1.2

Part 3: Packages

Committee Draft 01

19 October 2009

Specification URIs:

This Version:

http://docs.oasis-open.org/office/v1.2/part3/cd01/OpenDocument-v1.2-part3-cd01.odt (Authoritative)
http://docs.oasis-open.org/office/v1.2/part3/cd01/OpenDocument-v1.2-part3-cd01.pdf
http://docs.oasis-open.org/office/v1.2/part3/cd01/OpenDocument-v1.2-part3-cd01.html

Previous Version:

http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1.odt
docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1.pdf
http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1-html/OpenDocument-v1.1.html

Latest Version:

http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2-part3.odt
http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2-part3.pdf
http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2-part3.html

Technical Committee:

OASIS Open Document Format for Office Applications (OpenDocument) TC

Chair:

Rob Weir, IBM
Michael Brauer, Sun Microsystems, Inc.

Editors:

Patrick Durusau <patrick@durusau.net>

Dennis Hamilton <dennis.hamilton@acm.org>

Michael Brauer, Sun Microsystems, Inc. <michael.brauer@sun.com>

Related Work:

This specification supersedes OASIS OpenDocument v1.1.

Declared XML Namespaces:

urn:oasis:names:tc:opendocument:xmlns:manifest:1.0
urn:oasis:names:tc:opendocument:xmlns:digitalsignature:1.0
http://docs.oasis-open.org/ns/office/1.2/meta/pkg#

Abstract:

This is the specification of the Open Document Format for Office Applications (OpenDocument) format, an open, XML-based file format for office applications.

This specification has three parts.

Part 1 defines an XML schema and its semantics for office applications. The format is suitable for office documents, including text documents, spreadsheets, charts and graphical documents like drawings or presentations, but is not restricted to these kinds of documents.

Part 2 defines a formula language recommended for use in OpenDocument documents.

Part 3 (this document) defines a package format  for OpenDocument documents.

Status:

This document was last revised or approved by the OASIS Open Document Format for Office Applications (OpenDocument) Technical Committee on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document. This document is updated periodically on no particular schedule.

Technical Committee members should send comments on this specification to the Technical Committee's email list. Others should send comments to the Technical Committee by using the "Send A Comment" button on the Technical Committee's web page at www.oasis-open.org/committees/office.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (www.oasis-open.org/committees/office/ipr.php).

The non-normative errata page for this specification is located at www.oasis-open.org/committees/office.

Notices

Copyright © OASIS® 2002–2009. All Rights Reserved. OASIS trademark, IPR and other policies apply.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The names "OASIS", “OpenDocument”, “Open Document Format” and “ODF” are trademarks of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

Table of Contents

1Introduction

1.1Introduction

The Open Document Format for Office Applications (OpenDocument) format is an XML-based file format for office applications.

This Specification has three parts.

Part 1 defines an XML schema and its semantics for office applications. The format is suitable for office documents, including text documents, spreadsheets, charts and graphical documents like drawings or presentations, but is not restricted to these kinds of documents.

Part 2 defines a formula language recommended for use in OpenDocument documents.

Part 3 (this document) defines a package format for OpenDocument documents.

1.2Terminology

All text is normative unless otherwise labeled.

Text with a gray background color which is contained in boxes is informative. It lists the XML element-element and element-attribute relations for cross reference purposes.

Within the normative text of this specification, the terms “shall”, “shall not”, “should”, “should not”, “may” and “need not” are to be interpreted as described in Annex H of [ISO/IEC Directives].

XML Element, attribute names, attribute value types, and attribute values appear in  monospace font.

1.3Normative References

1.4Non Normative References

1.5Namespaces

The namespaces used or defined by OpenDocument part 3 are listed in tables 1 and 2.

The prefix column in tables 1 and 2 lists the namespace prefixes this specification uses when referring to elements and attributes in different namespaces. Conforming OpenDocument documents may substitute other namespace prefixes, bound to the listed namespace URI's, in accordance with the Namespaces in XML specification [xml-names].

Note: XML namespaces are employed in accordance with the  the Namespaces in XML W3C Recommendation  [xml-names].

Table 1 - XML Namespaces defined by the OpenDocument specification part 3

Table 2 - XML Namespaces used by the OpenDocument digital signature schema

2Packages

2.1General

As XML has no native support for binary objects such as images and other media types, and because uncompressed XML files can become very large, OpenDocument uses a package file to store the XML content of a document as separate parts together with  associated binary data as file entries in a single package file. These file entries may be compressed to further reduce the storage taken by the package This package is a Zip file [ZIP], whose structure is described in Appendix B. ODF Packages impose additional structure on the Zip file to accomplish the representation of OpenDocument Format documents.

A document within a package may consist of a set of files creating a unit, for instance the set of files specified by OpenDocument part 1. These files may be located in the root of the package, or within a directory. If they are contained in the root of the package, they are called document. If they are located within a directory, the document they constitute is called a sub document. A package may contain multiple sub documents, but only a single document may be contained in the root of the package. Unless otherwise stated, the term document refers to the document contained in the root of the package. This may include sub documents.

2.2Manifest

All OpenDocument package documents shall contain a file named “META-INF/manifest.xml”. This file is the OpenDocument package manifest.  The manifest provides :

• •A list of all of the files in the package (except those specifically excluded from the manifest). 

• •The MIME media type of each file in the package. 

• •If a file is stored in the file data in encrypted form, the manifest provides information required to decrypt the file correctly when the encryption key is also supplied. 

The format of the manifest file is specified in chapter 3.

2.3MIME Media Type

If a MIME media type for a document exists, then an OpenDocument package should contain a file with name “mimetype”. The content of this file shall be the MIME media type associated with the document.

Note: The purpose is to allow the type of document represented by the package to be discovered through 'magic number' mechanisms, such as Unix's file/magic utility. If a ZIP file contains a file at the beginning of the file that is uncompressed, and has no extra data in the header, then its file name and data can be found at fixed positions from the beginning of the package. More specifically, one will find:

• •the string 'PK' at position 0 of all zip files 

• •the string 'mimetype' beginning at position 30 

• •the media type itself beginning at position 38. 

2.4Encryption

2.4.1General

OpenDocument packages may be encrypted by encrypting the files within the package. The encryption process takes place in the following stages:

• •The start key is generated. 

• •The derived key is generated based on the start key. 

• •The files are encrypted based on the derived key and the encryption algorithm. 

Package consumers and producers that support encryption shall support the digest and encryption algorithms defined in 2.4.2. They may support additional algorithms. The information regarding the algorithms that were used to encrypt a file and required parameters are contained in the manifest.

Each file entry that is encrypted shall be compressed before being encrypted. Encrypted file entries shall be flagged as 'STORED' rather than 'DEFLATED' in the Zip file's central directory. The file entry's central directory records and its local file header both shall contain the compressed size of the file entry. The uncompressed size shall be contained in the manifest:size 3.8.13 attribute of the <manifest:file-entry> 3.3 element for the file entry.

2.4.2Default Encryption Algorithm

The encryption process for file entries using the default digest and encryption algorithms has three steps:

1. 1.The start key is generated: The byte sequence representing the password in UTF-8 is used to generate a 20-byte SHA1 digest (see [RFC3174]). 

2. 2.The derived key is generated from the start key: The PBKDF2 algorithm based on the HMAC-SHA-1 function (see [RFC2898]) is used for the key derivation. A random number generator initialized with the current time is used to generate a 16-byte salt for each file. The salt is used together with the start key to derive a unique 128-bit key for each file. The default iteration count for the algorithm is 1024. 

3. 3.The files are encrypted: The random number generator is used to generate the 8-byte initialization vector for the algorithm. The derived key is used together with the initialization vector to encrypt the file using the Blowfish algorithm in cipher feedback (CFB) mode (see [Blowfish]). 

2.5Digital Signatures

Files within a package may have a digital signature applied. Digital signatures are stored in one or more files whose relative paths begin with “META-INF/”. The names of these files shall contain the term “signatures”.

The format of digital signature files is specified in chapter 4.

2.6Metadata

Metadata for documents contained in an OpenDocument package may be expressed using the model of the W3C Resource Description Framework [RDF-CONCEPTS].

A document or sub document that is stored in a package may contain an arbitrary number of metadata files. The content of a metadata files shall conform to the [RDF-XML] specification. Editing applications that read and write documents should preserve all metadata files.

All metadata files of a document or sub document shall be listed in a separate metadata manifest file, which has the file name “manifest.rdf”. This file enumerates metadata files and their relationships to other files in an OpenDocument package. See chapter 5.

All references to a resource within the same package that occur within metadata file shall be represented by relative IRIs to the resource. This includes values of rdf:about attributes occurring within metadata files or metadata manifest files.

2.7Usage of IRIs Within Packages

Within the files contained in a package, relative IRIs may be used to reference other files within the same package.

OpenDocument Package Consumers shall resolve relative IRIs that occur within a file of a package as follows:

• •The file entry path is the file name  of the file within the Zip file which contains the relative IRI, including its relative path. 

• •The package base IRI is the base IRI which would be established for the package itself as defined in §5.1 of [RFC3986]. 

• •A file entry base IRI is constructed by interpreting the file entry path as a relative IRI, and by resolving this relative IRI to an absolute one as defined in §5.2 of [RFC3986] using the package base IRI as base URI. 

• •Relative IRI references shall be resolved as defined in §5.2 of [RFC3986] using the file entry base IRI as base URI. 

• •If a relative IRI 

  • –matches the rule for “relative-ref” defined in §4.2 of [RFC3986], and 

  • –matches the constrains for “relative-path” references defined in §4.2 of [RFC3986], and 

  • –if no path segments that are removed from the output buffer during the execution of the “Remove Dot Segments” step (§5.2.5 of [RFC3986]) have its origin in the package base IRI, 

   then the relative IRI shall interpreted as a package file entry reference. A package file entry reference is a reference to a file within the same package as the file containing the relative reference. The relative path of this file within the ZIP file is determined by the following procedure: 

  • –The package base IRI is removed from the absolute IRI to which the relative IRI has been resolved. 

  • –If the resulting relative IRI starts with a “/” character (U+002F SOLIDUS), then the “/” character is removed. 

  • –A fragment identifier, if it does exist, is removed. 

  • –The resulting relative IRI is interpreted as a file name within  the package, that is, as the name of a file including its relative path within the Zip file. 

  • –If a fragment identifier has been removed in a previous step, it may be resolved as defined for the media type of the referenced file. 

Note: File whose relative path starts with “META-INF/” are considered to be part of the OpenDocument package rather than of the content stored within the package. Therefore, different rules regarding the resolution of relative IRIs may apply. In particular the base URI for the resolution of relative IRIs may be the package base IRI rather than the file entry base IRI.

2.8Preview Image

Package producers should generate a preview image of the document that is contained in the package. It should be a representation of the first page, first sheet, etc. of the document. For maximum re-usability of the preview images they shall be generated without any effects, surrounding frames, or borders.

Note: Such effects might interfere with effects added to the preview images by the different file system explorers or may not be desired at all for certain use cases.

The preview image shall be contained in a file named “Thumbnails/thumbnail.png”.

Preview images shall be saved in PNG format.

Note: Current desktops display preview images within squares of up to 256 pixel width and height, and 24 bit per pixel. While this specification does not define upper or lower limits for preview image sizes, implementations should only use image sizes that are displayed with a reasonable quality if scaled to fit into 256x256 pixel square.

Encrypted files are intended to be unreadable for unauthorized users and package producers shall not generate preview images for such files. The may include a preview image that is  independent of the contents of the document..

3Manifest File

3.1Introduction

The format of the manifest file is defined by the OpenDocument manifest Relax-NG [RNG] schema. See appendix A. This chapter describes the semantics of the elements and attributes defined by this schema.

3.2<manifest:manifest>

The <manifest:manifest> element is the root element of the manifest file. It contains <manifest:file-entry> child elements 3.3, each of which describes a file or directory in the package.

The <manifest:manifest> element is a root element.

The <manifest:manifest> element has no attributes.

The <manifest:manifest> element has the following child element: <manifest:file-entry> 3.3.

3.3<manifest:file-entry>

The <manifest:file-entry> element defines a single file or directory within the package. It specifies the file's or directory's location in the package and its media type. It may also specify the data required to decrypt a file.

For directories, the manifest file should contain a <manifest:file-entry> element only if a directory contains a document or a sub document. See 2.1. A directory for administrative or convenience purposes, such as a directory that contains various unrelated image files, should not have an entry in the manifest file.

Directories have no corresponding file entries within the Zip file.

The <manifest:file-entry> element is usable with the following element: <manifest:manifest> 3.2.

The <manifest:file-entry> element has the following attributes: manifest:full-path 3.8.4, manifest:media-type 3.8.10, manifest:preferred-view-mode 3.8.11, manifest:size 3.8.13 and manifest:version 3.8.14.

The <manifest:file-entry> element has the following child element: <manifest:encryption-data> 3.4.

3.4<manifest:encryption-data>

The <manifest:encryption-data> element contains all of the information required to decrypt a file entry.

The <manifest:encryption-data> element is usable with the following element: <manifest:file-entry> 3.3.

The <manifest:encryption-data> element has the following attributes: manifest:checksum 3.8.2 and manifest:checksum-type 3.8.3.

The <manifest:encryption-data> element has the following child elements: <manifest:algorithm> 3.5, <manifest:key-derivation> 3.7 and <manifest:start-key-generation> 3.6.

3.5<manifest:algorithm>

The <manifest:algorithm> element specifies the algorithm used to encrypt data.

Depending on the algorithm specified by the manifest:algorithm-name attribute  3.8.1 , the <manifest:algorithm> element may have further child elements.

If the value of the manifest:algorithm-name attribute is Blowfish CFB the <manifest:algorithm> element shall not have child elements.

If the manifest:algorithm-name attribute has any value other than Blowfish CFB, the <manifest:algorithm> element should contain only child elements that are permitted child elements of an <EncryptionMethod> element, as defined in §3.2 of [xmlenc-core], whose Algorithm attribute has the value of the manifest:algorithm-name attribute.

The <manifest:algorithm> element is usable with the following element: <manifest:encryption-data> 3.4.

The <manifest:algorithm> element has the following attributes: manifest:algorithm-name 3.8.1 and manifest:initialisation-vector 3.8.5.

The <manifest:algorithm> element has no child elements.

3.6<manifest:start-key-generation>

The <manifest:start-key-generation> element specifies how the encryption start key was calculated from the user specified password. The password shall be provided as a sequence of bytes in UTF-8 encoding to the start key generation algorithm.

The <manifest:start-key-generation> element is usable with the following element: <manifest:encryption-data> 3.4.

The <manifest:start-key-generation> element has the following attributes: manifest:key-size 3.8.7 and manifest:start-key-generation-name 3.8.6.

The <manifest:start-key-generation> element has no child elements.

3.7<manifest:key-derivation>

The <manifest:key-derivation> element specifies how the encryption key was calculated from the encryption start key.

The <manifest:key-derivation> element is usable with the following element: <manifest:encryption-data> 3.4.

The <manifest:key-derivation> element has the following attributes: manifest:iteration-count 3.8.8, manifest:key-derivation-name 3.8.9, manifest:key-size 3.8.7 and manifest:salt 3.8.12.

The <manifest:key-derivation> element has no child elements.

3.8Manifest Attributes

3.8.1manifest:algorithm-name

The manifest:algorithm-name attribute specifies the name of the algorithm used to encrypt a file entry, and also specifies in which mode this algorithm was used.

The defined values for the manifest:algorithm-name attribute are:

• •Blowfish CFB: The Blowfish algorithm in CFB mode. See [Blowfish]. 

• •urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#blowfish: The same algorithm as identified by Blowfish CFB. 

• •An IRI listed in §5.2 or §5.3 of [xmlenc-core]: The algorithm specified in §5.2 or §5.3 of [xmlenc-core] for this IRI, or 

• •The IRI of an alternative algorithm as specified in §5.1 of [xmlenc-core]. Alternative algorithms may be specified by extended conforming documents only. They shall not be specified by conforming documents. 

• •Package producers that support encryption shall support the value Blowfish CFB. Package consumers that support encryption shall support the values Blowfish CFB and urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#blowfish. 

The manifest:algorithm-name attribute is usable with the following element: <manifest:algorithm> 3.5.

The values of the manifest:algorithm-name attribute are Blowfish CFB or a value of type anyURI 6.2.

3.8.2manifest:checksum

The manifest:checksum attribute specifies a digest in BASE64 encoding that can be used to detect password correctness as specified by a manifest:checksum-type attribute 3.8.3 .

The manifest:checksum attribute is usable with the following element: <manifest:encryption-data> 3.4.

The manifest:checksum attribute has the data type base64Binary 6.2.

3.8.3manifest:checksum-type

The manifest:checksum-type attribute specifies the name of a digest algorithm that can be used to check password correctness. The digest is build from the compressed unencrypted file.

The defined values for the manifest:checksum-type attribute are:

• •SHA1/1K: SHA1 algorithm (see [RFC3174]) applied to first 1024 bytes of the compressed unencrypted file. 

• •urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#sha1: The same algorithms as identified by SHA1/1K. 

• •An IRI listed in §5.7 of [xmlenc-core]: The algorithm specified in §5.7 of [xmlenc-core] for this IRI. 

• •The IRI of an alternative algorithm as specified in §5.1 of [xmlenc-core]. Alternative algorithms may be specified by extended conforming documents only. They shall not be specified by conforming documents. 

Package producers that support encryption shall support the value SHA1/1K. Package consumers that support encryption shall support the values SHA1/1K and urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#sha1.

The manifest:checksum-type attribute is usable with the following element: <manifest:encryption-data> 3.4.

The values of the manifest:checksum-type attribute are SHA1/1K or a value of type anyURI 6.2.

3.8.4manifest:full-path

The manifest:full-path attribute describes the location of a file or directory within the package. It's value is the name of a file or folder within the Zip file for which the manifest entry defines additional information, including its relative path in the package. The notation is the same as for the “filename” fields of the Zip file's central directory.

The attribute value "/" denotes a manifest entry for the package itself.

Note: The Zip file's central directory and the manifest file may have different text encodings.

The manifest:full-path attribute is usable with the following element: <manifest:file-entry> 3.3.

The manifest:full-path attribute has the data type string 6.2.

3.8.5manifest:initialisation-vector

The manifest:initialisation-vector attribute specifies the byte-sequence used as an initialization vector to a encryption algorithm. The initialization vector is a BASE64 encoded binary sequence.

The manifest:initialisation-vector attribute is usable with the following element: <manifest:algorithm> 3.5.

The manifest:initialisation-vector attribute has the data type base64Binary 6.2.

3.8.6manifest:start-key-generation-name

The manifest:start-key-generation-name attribute specifies the algorithm used to generate a start key from the user password.

The defined values for the manifest:start-key-generation-name attribute are:

• •SHA1: The SHA1 algorithm (see [RFC3174]). 

• •An IRI listed in §5.7 of [xmlenc-core]: The algorithm specified in §5.7 of [xmlenc-core] for this IRI. 

• •The IRI of an alternative algorithm as specified in §5.1 of [xmlenc-core] Alternative algorithms may be specified by extended conforming documents only. They shall not be specified by conforming documents. 

Package producers that support encryption shall support the value SHA1. Package consumers that support encryption shall support the values SHA1 and http://www.w3.org/2000/09/xmldsig#sha1.

The manifest:start-key-generation-name attribute is usable with the following element: <manifest:start-key-generation> 3.6.

The values of the manifest:start-key-generation-name attribute are SHA1 or a value of type anyURI 6.2.

The manifest:start-key-generation-name attribute has the value SHA1 or a value of data type anyURI.

3.8.7manifest:key-size

The manifest:key-size attribute specifies the length of a key.

The manifest:key-size attribute is usable with the following elements: <manifest:key-derivation> 3.7 and <manifest:start-key-generation> 3.6.

The manifest:key-size attribute has the data type nonNegativeInteger 6.2.

3.8.8manifest:iteration-count

The manifest:iteration-count attribute specifies the number of iterations used by the key derivation algorithm to derive a key.

The manifest:iteration-count attribute is usable with the following element: <manifest:key-derivation> 3.7.

The manifest:iteration-count attribute has the data type nonNegativeInteger 6.2.

3.8.9manifest:key-derivation-name

The manifest:key-derivation-name attribute specifies the name of the algorithm used to derive a name.

The defined values for the manifest:key-derivation-name attribute are:

• •PBKDF2: The PBKDF2 key derivation method. See [RFC2898]. 

• •urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#pbkdf2: The same algorithms as identified by PBKDF2. 

• •An IRI listed in §5.7 of [xmlenc-core]: The algorithm specified in §5.7 of [xmlenc-core] for this IRI. 

• •The IRI of an alternative algorithm as specified in §5.1 of [xmlenc-core]. Alternative algorithms may be specified by extended conforming documents only. They shall not be specified by conforming documents. 

Package producers that support encryption shall support the value PBKDF2. Package consumers that support encryption shall support the values PBKDF2 and urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#pbkdf2.

If the value of this attribute is PBKDF2 or urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#pbkdf2 the <manifest:encryption-data> 3.4 should contain a <manifest:start-key-generation> 3.6 child element that specifies the start key for the PBKDF2 algorithm.

The manifest:key-derivation-name attribute is usable with the following element: <manifest:key-derivation> 3.7.

The values of the manifest:key-derivation-name attribute are PBKDF2 or a value of type anyURI 6.2.

3.8.10manifest:media-type

The manifest:media-type attribute specifies the MIME media type of a file or directory. See [RFC4288]. All files that have XML content should have the media type “text/xml”.

A manifest:media-type attribute should be present for all files and folders where a MIME media type exists for the content of the file or folder.

The manifest:media-type attribute is usable with the following element: <manifest:file-entry> 3.3.

The manifest:media-type attribute has the data type string 6.2.

3.8.11manifest:preferred-view-mode

The manifest:preferred-view-mode attribute specifies a preference on how the author of the document would like the document to be presented upon the document being opened. This attribute is only applicable to the root file entry with the manifest:full-path 3.8.4 attribute value of "/".

The defined values for the manifest:preferred-view-mode attribute are:

• •edit: The author's preference is to open the document as an editable document. 

• •presentation-slide-show: The author's preference is to open the document as presentation slide show. 

• •read-only: The author's preference is to open the document as a read-only document. 

• •A namespaced token value: Specifies an implementation defined view. 

Preferred view modes are not necessarily generally applicable to all media types. The default preferred view mode is implementation defined. The behavior for cases where the manifest:preferred-view-mode attribute is absent is implementation defined.

The manifest:preferred-view-mode attribute is usable with the following element: <manifest:file-entry> 3.3.

The values of the manifest:preferred-view-mode attribute are edit, presentation-slide-show, read-only or a value of type namespacedToken 6.3.1.

3.8.12manifest:salt

The manifest:salt attribute specifies the  sequence used as the 'salt' by a key derivation algorithm. The salt is a BASE64 encoded binary sequence.

The manifest:salt attribute is usable with the following element: <manifest:key-derivation> 3.7.

The manifest:salt attribute has the data type base64Binary 6.2.

3.8.13manifest:size

The manifest:size attribute shall be present for encrypted files. See 2.4. Its value shall be size of the uncompressed, unencrypted file in bytes.

The manifest:size attribute is usable with the following element: <manifest:file-entry> 3.3.

The manifest:size attribute has the data type nonNegativeInteger 6.2.

3.8.14manifest:version

The manifest:version attribute specifies the format version of a file entry. For documents that are composed from multiple files, this attribute is specified at the manifest entry that references the folder that contains these files.

The specified version refers to the format specified in the media-type attribute of the manifest entry at which it occurs.

The manifest:version attribute is usable with the following element: <manifest:file-entry> 3.3.

The manifest:version attribute has the data type string 6.2.

4Digital Signatures File

4.1Introduction

The format of the digital signature files is defined by the OpenDocument digital signature schema Relax-NG [RNG] schema. See appendix A. This chapter describes the semantics of the elements and attributes defined by this schema.

4.2<dsig:document-signatures>

The <dsig:document-signatures> root element serves as a container for an arbitrary number of <xmldsig:Signature> 4.3 elements. If the <dsig:document-signatures> element contains multiple <xmldsig:Signature> elements, then there should be a relation between the digital signatures they define, for instance, they may all apply to the same set of files.

Implementations may require that a digital signature includes a certain set of files. That is, they may consider a digital signature to be valid if, and only if,

• •the digital signature itself is valid, and 

• •if the <Reference> child elements of the <Signature> element reference a certain set of files. 

In particular, implementations may require that a digital signature references all files contained in a package.

The <dsig:document-signatures> element is a root element.

The <dsig:document-signatures> element has no attributes.

The <dsig:document-signatures> element has the following child element: <xmldsig:Signature> 4.3.

4.3<xmldsig:Signature>

The <xmldsig:Signature> element is defined by the [xmldsig-core] specification.

Relative IRI references contained within the element or any of its descendant elements shall be resolved as defined in section 2.7, except that the base URI for resolving relative IRIs shall be the package base IRI.

Note: Applications may use extensions to the [xmldsig-core] specification, such as those required for implementation of XAdES signatures specified in ETSI TS 101 903 v1.3.2 [XAdES].

The <xmldsig:Signature> element is usable with the following element: <dsig:document-signatures> 4.2.

5Metadata Manifest Files

Metadata manifest files (see 2.6) have the file name “manifest.rdf”. The metadata manifest file for a document (see 2.1) shall be stored in root of the package. Metadata manifest files for sub documents shall be stored in the sub document's directories.

Metadata manifest files enumerate metadata files and their relationships to other files in that document or sub document as defined by this specification.

The relationships are expressed in the metadata manifest files using [RDF-XML] and the [OWL] Metadata Manifest Description ontology that is defined in appendix B. The following OWL classes and properties are defined.

5.1pkg:Document

An instance of the pkg:Document class in the metadata manifest file represents the document or sub document itself.

The following property is defined for the pkg:Document class: pkg:hasPart 5.5.

5.2pkg:File

A file in an OpenDocument package is represented by an instance of class pkg:File or by one of its subclasses, for example pkg:MetadataFile.

An instance of the pkg:File class (or one of its subclasses) is identified by an URL.

The relationship between a file and a package is expressed using the property pkg:hasPart 5.5.

The following property is defined for the pkg:File class: pkg:mimeType 5.6.

5.3pkg:MetadataFile

An instance of the pkg:MetadataFile class represents a metadata file.

The pkg:MetadataFile class is a subclass of pkg:File 5.2.

5.4pkg:Element

The pkg:Element class describes an XML element contained in a file within an OpenDocument package.

5.5pkg:hasPart

The pkg:hasPart property locates a file described by pkg:File or its subclasses within a document or sub document.

This property can be used with the following class: pkg:Document 5.1.

5.6pkg:mimeType

The pkg:mimeType property is used to specify the MIME media type [RFC4288] of file described by an pkg:File class or one of its subclasses.

This property can be used with the following class: pkg:File 5.2.

6Datatypes

6.1Introduction

The possible values of attributes and elements are constrained by datatypes. These datatypes either are datatypes defined within [xmlschema-2], or are defined by this specification itself. Datatypes for which no [xmlschema-2] datatype does exist are expressed in the schema by [xmlschema-2] datatypes which have have additional constrains. These constrains are either specified in the schema, or in this specification.

6.2W3C Schema Datatypes

The following [xmlschema-2] datatypes are used in this specification:

• •anyURI 

• •base64Binary 

• •nonNegativeInteger 

• •string 

6.3Other Datatypes

6.3.1namespacedToken

A namespaced token is a token id that makes use of the XML namespace mechanism for modularization purposes.

7Conformance

7.1Introduction

The OpenDocument package specification defines conformance for package files, consumers, and producers with two conformance classes called conforming and extended conforming..

7.2Package Conformance

7.2.1Conforming OpenDocument Packages

1. (PD1)A conforming OpenDocument package shall adhere to the specification described in this document and shall meet the requirements: 

   1. (PD1.1)It shall be a ZIP file, as defined by [ZIP]. 

   2. (PD1.2)It shall contain a file “META-INF/manifest.xml”. This file shall meet the  requirements: 

      1. (PD1.2.1)The file shall be a well formed XML document in accordance with the  [XML1.0] specification. 

      2. (PD1.2.2)The XML root element of the file shall be a <manifest:manifest> element 3.2. 

      3. (PD1.2.3)The XML file shall be valid with respect to the manifest schema defined in appendix A.1 OpenDocument Manifest Schema. 

      4. (PD1.2.4)The file shall not contain <manifest:file-entry> elements 3.3 whose manifest:full-path attribute  3.8.4 value references any of these files: 

         1. 1.The “META-INF/manifest.xml” file itself. 

         2. 2.Any other files whose relative path start with  “META-INF/”. 

         3. 3.The “mimetype” file. 

      5. (PD1.2.5)For all files contained in a Zip file, with exception of those files listed in (PD1.2.4), the “META-INF/manifest.xml” file shall contain exactly one <manifest:file-entry> element whose manifest:full-path attribute's value references the file. 

      6. (PD1.2.6)The file should contain a <manifest:file-entry> element whose manifest:full-path attribute has the value "/". This entry shall provide information regarding the content stored in the package.  

      7. (PD1.2.7)Any manifest:algorithm-name attribute 3.8.1, manifest:checksum-type attribute 3.8.3, manifest:start-key-generation-name attribute 3.8.6 and manifest:key-derivation-name attribute  3.8.9 shall not specify an alternative algorithm which is neither defined by this specification nor by [xmlenc-core]. 

   3. (PD1.3)It should contain a file “mimetype”. This file shall meet the requirements: 

      1. (PD1.3.1)It should be the first file of the zip file. 

      2. (PD1.3.2)It shall not be compressed. 

      3. (PD1.3.3)It shall not use an 'extra field' in its header. 

      4. (PD1.3.4)If the file named “META-INF/manifest.xml” contains a <manifest:file-entry> element whose manifest:full-path attribute has the value "/", then the content of the “mimetype” file shall be equal to the value of the manifest:media-type attribute  3.8.10 of that element. 

   4. (PD1.4)It may contain files whose relative paths begin with “META-INF/” and whose names contain the term “signatures”. These file shall meet the requirements: 

      1. (PD1.4.1)The files shall be well-formed XML files in accordance with  [XML1.0]. 

      2. (PD1.4.2)The XML root element of each file shall be a <dsig:document-signatures> element 4.2. 

      3. (PD1.4.3)The XML root element of the file shall be valid with respect to the digital signature schema defined in appendix A.2  OpenDocument Digital Signature Schema. 

   5. (PD1.5)It shall not contain other files whose relative path begins with  “META-INF/” other than than those listed in (PD1.2) and (PD1.4). 

   6. (PD1.6)The files listed in (PD1.2) and (PD1.5) meet the requirements: 

      1. (PD1.6.1)They shall be namespace-well-formed with regard to the XML Namespaces specification [xml-names]. 

      2. (PD1.6.2)They shall conform to the xml-id specification [XML-ID]. 

7.2.2Conforming OpenDocument Extended Packages

1. (PD2)A conforming OpenDocument extended package shall meet all requirements of a conforming package except (PD1.3.4) 

7.3Producer Conformance

7.3.1Conforming OpenDocument Package Producer

1. (PP1)A Conforming OpenDocument Package Producer is a program that creates conforming OpenDocument packages, and that meets the additional requirements: 

   1. (PP1.1)It may produce conforming OpenDocument extended packages, but it shall have a mode of operation where all OpenDocument packages that are created are conforming OpenDocument packages. 

   2. (PP1.2)It shall be accompanied by a document that defines all implementation-defined values used by the OpenDocument package producer. 

7.3.2Conforming OpenDocument Package Extended Producer

1. (PP2)A Conforming OpenDocument Package Extended Producer is a program that creates conforming OpenDocument extended packages, and that meets the additional requirement: 

   1. (PP2.1)It shall be accompanied by a document that defines all implementation-defined values used by the OpenDocument package producer. 

7.4Consumer Conformance

1. (PC1)A Conforming OpenDocument Package Consumer is a program that can parse and interpret OpenDocument packages, and that meets the following additional requirements: 

   1. (PC1.1)It shall be able to parse and interpret OpenDocument packages and OpenDocument extended packages, but it need not interpret the semantics of all elements, attributes and attribute values. 

   2. (PC1.2)The XML parser used to parse the files listed in (PD1.2) and (PD1.4) meets the  requirements: 

      1. (PC1.2.1)It shall be a non validating XML processor with regard to the XML 1.0 specification [XML1.0]. 

      2. (PC1.2.2)It shall be  a conforming processor with regard to the XML Namespaces specification [xml-names]. 

      3. (PC1.2.3)It shall conform to the xml-id specification [XML-ID]. 

1. Appendix A. Schemas 

   1. A.1.OpenDocument Manifest Schema 

The OpenDocument manifest schema is defined by a separate document, which is located here:

http://docs.oasis-open.org/office/v1.2/part3-cd01/OpenDocument-manifest-schema-v1.2-cd1.rng

1. 1. A.2.OpenDocument Digital Signature Schema 

The OpenDocument digital signature schema is defined by a separate document, which is located here:

http://docs.oasis-open.org/office/v1.2/part3-cd01/OpenDocument-dsig-schema-v1.2-cd1.rng

1. Appendix B.OpenDocument Metadata Manifest Ontology 

The OpenDocument metadata manifest ontology is defined by a separate document, which is located here:

http://docs.oasis-open.org/office/v1.2/part3-cd01/OpenDocument-package-metadata-v1.2-cd1.owl

1. Appendix C.Zip File Structure (Non normative) 

A Zip file starts with a sequence of files, each of which can be compressed or stored in raw format. Each file has a local header immediately before its data, which contains most of the information about the file, including time-stamps, compression method and file name. The compressed file contents immediately follow, and are terminated by an optional data descriptor. The data descriptor contains the CRC and compressed size of the file, which are frequently not available when writing the local file header. If these details were included, the data descriptor can be skipped.

Each file in the archive is laid down sequentially in this format, followed by a central directory at the end of the Zip archive. The central directory is a contiguous set of directory entries, each of which contains all the information in the local file header, plus extras such as file comments and attributes. Most importantly, the central directory contains pointers to the position of each file in the archive for navigation of the Zip file.

 

 

For more details about the Zip file format, see [ZIP].

1. Appendix D.Changes From “Open Document Format for Office Applications (OpenDocument) v1.1” (Non Normative) 

The OpenDocument specification has been divided into three parts and has been restructured.

This appendix describes changes that are related to part 3 of this specification.

The following is a list of major features that have been added. For minor features please see the lists of new and changed elements and attributes.

• •Digital Signatures 2.5 

• •RDF based metadata 2.6 

• •Support for additional encryption algorithms 2.4 

The following element is new for manifest files:

• •<manifest:start-key-generation> 3.6 

The following attributes are new for manifest files:

• •manifest:key-size 3.8.7 

• •manifest:preferred-view-mode 3.8.11 

• •manifest:start-key-generation-name 3.8.6 

• •manifest:version 3.8.14 

The value types of the following attributes changed:

• •manifest:algorithm-name 3.8.1 of <manifest:algorithm> 3.5 

• •manifest:checksum-type 3.8.3 of <manifest:encryption-data> 3.4 

• •manifest:key-derivation-name 3.8.9 of <manifest:key-derivation> 3.7 

1. Appendix E.Acknowledgments (Non Normative) 

The following individuals have participated in the creation of this specification and are gratefully acknowledged:

Participants:

Chieko Asakawa, IBM

Waldo Bastian, Intel Corporation

Thorsten Behrens, Novell

Nathaniel Borenstein, IBM

Michael Brauer, Sun Microsystems

Pete Brunet, IBM

Manuel Cano

Robin Cover, OASIS

Pierre Ducroquet

Jerome Dumonteil, Ars Aperta

Patrick Durusau

Ezer Farhi

David Faure

Andreas J. Guelzow

Bettina Haberer, Sun Microsystems

Dennis E. Hamilton

Donald Harbison, IBM

Mingfei Jia, IBM

Bob Jolliffe, South Africa Dept. of Science & Technology

Peter Junge, Beijing Redflag Chinese 2000 Software Co., Ltd.

Peter Korn, Sun Microsystems

Jirka Kosek

Marcus Lange, Sun Microsystems

Fong Lin, Novell

Jun Ma, Beijing Redflag Chinese 2000 Software Co., Ltd.

Yue Ma, IBM

John Madden, Duke University

Doug Mahugh, Microsoft Corporation

James Mason, ISO/IEC JTC1/SC34

Duane Nickull, Adobe Systems

Michael Paciello

Eric Patterson, Microsoft Corporation

David Pawson

Stephen Peront, Microsoft Corporation

Eike Rathke, Sun Microsystems

Florian Reuter, Novell

Janina Sajka

Svante Schubert, Sun Microsystems

Charles Schulz, Ars Aperta

Richard Schwerdtfeger, IBM

Wei Guo Shi, IBM

Michael Stahl, Sun Microsystems

Yan Shi, Beijing Sursen International Information Technology Co., Ltd.

Jomar Silva, OpenDocument Format Alliance

Frank Stecher, Sun Microsystems

Hironobu Takagi, IBM

Malte Timmermann, Sun Microsystems

Elias Torres, IBM

Warren Turkal, Google Inc.

Alex Wang, Beijing Sursen International Information Technology Co., Ltd.

Robert Weir, IBM

Oliver-Rainer Wittmann, Sun Microsystems

David A. Wheeler

Cheng XiuZhi, Beijing Redflag Chinese 2000 Software Co., Ltd.

Panrong Yin, IBM

Kohei Yoshida, Novell

Helen Yue, IBM

Jin YouBing, Beijing Redflag Chinese 2000 Software Co., Ltd.

Thorsten Zachmann

Thomas Zander, Nokia Corporation

Pine Zhang, UOML Alliance