ISO/IEC 26300:2006/Amd 1:2012
(Amendment)Information technology — Open Document Format for Office Applications (OpenDocument) v1.0 — Amendment 1: Open Document Format for Office Applications (OpenDocument) v1.1
Information technology — Open Document Format for Office Applications (OpenDocument) v1.0 — Amendment 1: Open Document Format for Office Applications (OpenDocument) v1.1
Technologies de l'information — Format de document ouvert pour applications de bureau (OpenDocument) v1.0 — Amendement 1: Format de document ouvert pour applications de bureau (OpenDocument) v1.1
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 26300
First edition
2006-12-01
AMENDMENT 1
2012-03-15
Information technology — Open
Document Format for Office Applications
(OpenDocument) v1.0
AMENDMENT 1: Open Document Format
for Office Applications (OpenDocument) v1.1
Technologies de l'information — Format de document ouvert pour
applications de bureau (OpenDocument) v1.0
AMENDEMENT 1: Format de document ouvert pour applications de
bureau (OpenDocument) v1.1
Reference number
ISO/IEC 26300:2006/Amd.1:2012(E)
©
ISO/IEC 2012
---------------------- Page: 1 ----------------------
ISO/IEC 26300:2006/Amd.1:2012(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2012
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2012 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 26300:2006/Amd.1:2012(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
Amendment 1 to ISO/IEC 26300:2006 was prepared by Joint Technical Committee ISO/IEC JTC 1,
Information technology, Subcommittee SC 34, Document description and processing languages.
This Amendment should be read in conjunction with ISO/IEC 26300:2006 and the associated Technical
Corrigenda 1 and 2. The current edition of ISO/IEC 26300 should be understood by first applying the change
specified in the Technical Corrigenda, then applying the changes specified in this Amendment.
© ISO/IEC 2012 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC 26300:2006/Amd.1:2012
Notation conventions
The title of each change is the complete reference to the section or sub-section being modified. In all cases
(except for an amendment inserting two new Appendices) the title begins with the section or sub-section
number, the section or sub-section name, and the page number. In most cases the location of the
amendment is more precisely indicated by a paragraph number or other indicator. Paragraph numbers are
determined by counting the number of paragraphs from the beginning of the section or sub-section in
question, ignoring lists, tables and examples.
In the case of amendments to the normative Relax-NG schema, the lines of the schema that are amended
are indicated in italics below the heading. Schema line numbers refer to the amended schema. Other
guidance on the intended application of an amendment may be given in italics below the heading.
A change can contain any one or more of the following kinds of edits:
Addition of text: New text is displayed in blue and is underlined, as demonstrated here.
Deletion of text: Deleted text is displayed in red and is struck-through, as demonstrated here.
An ellipsis '…' is occasionally used to indicate deliberate omission of fragments of the original text that are
unchanged by this Amendment and would unreasonably extend the text of this Amendment.
© ISO/IEC 2012 – All rights reserved iv
---------------------- Page: 4 ----------------------
ISO/IEC 26300:2006/Amd.1:2012(E)
Front matter, p. 1
Open Document Format for Office
Applications (OpenDocument) v1.10
(Second Edition)
Committee Specification1, 19 Jul 2006OASIS Standard, 1 Feb
2007
Document identifier:
OpenDocument-v1.1ed2-.odt
Location:
This Version: http://www.oasis-open.org/committees/office
Previous Version: http://docs.oasis-open.org/office/v1.0
Specification URIs
This Version:
http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1.odt
http://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.zip
Previous Version:
http://www.oasis-open.org/committees/download.php/19275/OpenDocument-v1.0ed2-cs1.odt
http://www.oasis-open.org/committees/download.php/19274/OpenDocument-v1.0ed2-cs1.pdf
Latest Version:
http://docs.oasis-open.org/office/v1.1/OpenDocument-v1.1.odt
http://docs.oasis-open.org/office/v1.1/OpenDocument-v1.1.pdf
http://docs.oasis-open.org/office/v1.1/OpenDocument-v1.1.html.zip
Latest Approved Version:
http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1.odt
http://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.zip
Technical Committee:
OASIS Open Document Format for Office Applications (OpenDocument) TC
Chair:
Michael Brauer, Sun Microsystems, Inc.
Editors:
Patrick Durusau, Individual
Michael Brauer, Sun Microsystems, Inc.
Lars Oppermann, Sun Microsystems, Inc.
Related Work:
This specification supersedes OASIS OpenDocument v1.0.
Declared XML Namespaces:
A list of XML namespaces declared by this specification is available in section 1.3.
Abstract:
This is the specification of the Open Document Format for Office Applications (OpenDocument)
format, an open, XML-based file format for office applications, based on OpenOffice.org XML [OOo].
© ISO/IEC 2012 – All rights reserved 1
---------------------- Page: 5 ----------------------
ISO/IEC 26300:2006/Amd.1:2012(E)
Status:
This document was last revised or approved by the membership of OASISOASIS 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.oasisopen.org/committees/office.
§ 1.4, “Relax-NG Schema”, schema fragment, p. 32
{The following text amends lines 3-4 and 9-10 of the normative Relax-NG schema, as reproduced in this
section.}
1
2
§ 1.5, “Document Processing and Conformance”, paragraph 7,
p. 34
There are no rules regarding the elements and attributes that actually have to be supported by conforming
applications, except that applications should not use foreign elements and attributes for features defined inby
the OpenDocument schema. See also appendix D.
§ 2.1.1, “Document Root Element Content Models”,
paragraph 1, p. 37
{The following text corrects an editorial error in ISO/IEC 26300:2006/Cor 1, in which part of the text of the
sentence inserted at the end of the paragraph is missing.}
The content models of the five root elements is summarized in the following table. Note that
may contain all supported top-level elements. All four subdocument root elements
together contain the same information as an element that contains the same
subdocument root elements.
2 © ISO/IEC 2012 – All rights reserved
---------------------- Page: 6 ----------------------
ISO/IEC 26300:2006/Amd.1:2012(E)
§ 2.1.1, table following paragraph 1, p. 37
{The following text amends the heading of the second column of the table.}
meta-
data
§ 2.3.1, “Text Documents”, sub-section “Text Document
Content Model”, schema fragment, p. 42
{The following text inserts a new line (line 179 of the amended schema) in the definition of pattern “text-
content” in the normative Relax-NG schema, as reproduced in this section.}
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
§ 2.3.1, “Text Documents”, following sub-section “Global Text
Documents”, p. 42
{The following text inserts a new sub-section, including reproduction of a new pattern definition “office-text-
attlist” inserted into the normative Relax-NG schema (lines 201-207 of the amended schema).}
Use Soft Page Breaks
The text:use-soft-page-breaks attribute specifies whether the document contains soft page breaks.
A soft page break is a page break that has been included by a page oriented processor at a position where
the document itself does not include a page break (e.g. by using the fo:break-before and fo:break-
after formatting properties described in section 15.5.2) .
Soft page breaks are specified by the elements described in sections 4.7 and
5.1.1:Soft Page breaks.
The use of the elements is always optional. An application generating the
format may include the element if it has computed a paginated layout. A consuming ap plication may handle
the element while computing the layout, but it shall not depend on its existence. Soft page breaks are only
supported within text documents.
A generating application that stores soft page breaks shal l indicate this by setting the text:use-page-
breaks attribute to true . A generating application that does not store soft page breaks sha ll indicate that b y
omitting this attribute, or by setting it to false .
© ISO/IEC 2012 – All rights reserved 3
---------------------- Page: 7 ----------------------
ISO/IEC 26300:2006/Amd.1:2012(E)
An application that does not support pagination and soft page-breaks, that modifies an OpenDocument file,
which includes soft page-breaks, shal l at least set the text:use-page-breaks attribute to false (or
remove it). It should also remove the elements from the document but is not
required to do so.
An application that computes a paginated layout of a document should provide a facility to turn on export of
soft page breaks for the purposes of consistent page breaks and for proper conversion to digital talking book
formats (such as [DAISY ] ) .
For elements that appear within table rows, the maximum number of
elements that appear within the single table cells determines the number o f
page breaks that appear within the table row. The elements contained in each
cell determine the positions where these page breaks appear within the cell content.
Similarly, elements that appear within text boxes and other content displayed
outside the text flow, do not start a new page, but only indicate where the text-box's content breaks between
two pages.
201
202
203
204
205
206
207
§ 2.5, “Scripts”, paragraph 2, p. 50
Scripts do not imply a scripting language or an object model. A script can for instance operate on the
Document Object Model (DOM) composed from the XML representation of a document in OpenDocument
format (see [DOM2]), operate on the Document Object Model (DOM) of a document in OpenDocument format
or on an application specific API.
§ 3, “Meta Data Elements”, section title, p. 56
{The section title is revised as follows.}
3 Metad Data Elements
§ 3.1.18, “Document Statistics”, schema fragment, pp. 62–63
{The following text moves five lines of the definition of the pattern “office-meta-data” to a new position (lines
771-775 of the amended schema) in the normative Relax-NG schema, as reproduced in this section.}
744
745
...
766
767
768
769
770
771
772
773
774
775
4 © ISO/IEC 2012 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/IEC 26300:2006/Amd.1:2012(E)
776
777
778
779
780
...
816
817
818
819
820
821
822
§ 4.3.2, “List Item”, paragraph 1, p. 71
List items contain the textual content of a list. A element can contain paragraphs,
headings, lists or soft page breaks. A list item cannot contain or lists. A list item cannot contain headings or
tables.
§ 4.3.2, “List Item”, pp. 71-72
{The following text inserts a new line in the definition of the pattern “text-list-item-content” (line 994 of the
amended schema) in the normative Relax-NG schema, as reproduced in this section.}
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
§ 4.3.2, “List Item”, sub-section “Formatted number”, example,
p. 72
This is the first list item
This is a continuation of the first list item.
This is the second list item.
It contains a sub list.
© ISO/IEC 2012 – All rights reserved 5
---------------------- Page: 9 ----------------------
ISO/IEC 26300:2006/Amd.1:2012(E)
This is a sub list item.
This is a sub list item.
This is a sub list item.
This is the third list item
§ 4.4.3, “DDE Source”, following paragraph 1, p. 77
{The following text inserts a new paragraph following existing paragraph 1 and preceding the schema
fragment.}
See section 12.6 for the use of DDE connections.
§ 4.6.4, “Deletion”, second bulleted list, p. 80
• If the change mark is inside a paragraph, insert the text content of the element as if the
beginning and final tags were missing.
• If the change mark is inside a header, proceed as above, except adapt the end tags to matchinserted tags
to math their new counterparts.
• Otherwise, simply copy the text content of the element in place of the change mark.
§ 4.6.4, “Deletion”, example, pp. 80-81
Example: Given the following change:
...
This becomes:
abcdef
HelloHello
World!World!
ghijkl
If, in the first two cases, the deletion contains complete paragraphs, then additional empty paragraphs must
be put into the element to achieve the desired result.
...
would be represented as:
.
HelloHello
World!World!
6 © ISO/IEC 2012 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/IEC 26300:2006/Amd.1:2012(E)
New section following § 4.6 “Change Tracking”, p. 82
{The following text inserts a new sub-section, including reproduction of a new pattern definition “text-soft-
page-break” (lines 1199-1203 of the amended schema) inserted into the normative Relax-NG schema.}
4.7 Soft Page Break
The element represents a soft page break.
See section 2.3.1:Use Soft Page Breaks for details regarding soft page breaks.
1199
1200
1201
1202
1203
§ 5.1.1, “White-space Characters”, paragraphs 1-3, p. 84
{The following text amends paragraphs 1 and 3 and inserts a new paragraph following existing paragraph 3.}
If the paragraph element or any of its child elements contains white-space characters, they are collapsed.
Leading white-space characters at the paragraph start as well as trailing white-space characters at the
paragraph end are ignored. In detail, the following conversions take place, in other words they are processed
in the same way that [HTML4] processes them. The following [UNICODE] characters are normalized to a
SPACE character:
The following [UNICODE] characters are normalized to a SPACE character:
• HORIZONTAL TABULATION (0x0009)
• CARRIAGE RETURN (0x000D)
• LINE FEED (0x000A)
• SPACE (0x0020)
In addition, these characters are ignored if the preceding character is a white-space character. The preceding
character can be contained in the same element, in the parent element, or in the preceding sibling element, as
long as it is contained within the same paragraph element and the element in which it is contained processes
white-space characters as described above. White-space characters at the start or end of the paragraph are
ignored, regardless whether they are contained in the paragraph element itself, or in a child element in which
white-space characters are collapsed as described above.
These white-space processing rules shall enable authors to use white-space characters to improve the
readability of the XML source of an OpenDocument document in the same way as they can use them in
HTML.
§ 5.1.1, “White-space Characters”, following sub-section “Line
Breaks”, p. 86
{The following text inserts a new sub-section, including reproduction of a new pattern definition “paragraph-
content” (lines 1266-1268 of the amended schema) inserted into the normative Relax-NG schema.}
Soft Page Break
The element represents a soft page break within a heading or paragraph.
See section 2.3.1:Use Soft Page Breaks for details regarding soft page breaks.
© ISO/IEC 2012 – All rights reserved 7
---------------------- Page: 11 ----------------------
ISO/IEC 26300:2006/Amd.1:2012(E)
1266
1267
1268
§ 5.1.4, “Hyperlinks”, paragraph 3, p. 87
The attributes that may be associated with the element are:
• Name
• Title
• Link location
• Target frame
• Text styles
§ 5.1.4, “Hyperlinks”, following sub-section “Name”, p. 87
{The following text inserts a new sub-section, including reproduction of a new pattern definition 'text-a-attlist'
(lines 1304-1310 of the amended schema) inserted into the normative Relax-NG schema.}
Title
The office:title attribute specifies a short accessible description for hint text.
See appendix E for guidelines how to use this attribute.
1304
1305
1306
1307
1308
1309
1310
§ 6.4.14, “Document Modification Time”, paragraph 2, p. 120
This element displays the information from the element. The name was chosen to avoid
confusion with fields.
§ 6.4.15, “Document Modification Date”, paragraph 2, p. 121
This element displays the information from the element. The name was chosen to avoid
confusion with fields.
§ 6.6.9, “DDE Connection Fields”, following paragraph 2, p. 137
{The following text inserts a new paragraph following paragraph 2.}
See section 12.6 for the use of DDE connections.
8 © ISO/IEC 2012 – All rights reserved
---------------------- Page: 12 ----------------------
ISO/IEC 26300:2006/Amd.1:2012(E)
§ 6.7.6, “Formula”, paragraph 2, p. 143
The formula should start with a namespace prefix that indicates the syntax and semantic used within the
formula.
§ 8.1, “Basic Table Model”, paragraph 3, p. 178
{The following text creates a new paragraph by inserting a paragraph break in the existing paragraph.}
Table rows may be empty, and different rows might contain a different number of table cells. This is not an
error, but applications might resolve this in different ways. Spreadsheet applications typically operate on large
tables that have a fixed application dependent row and column number, but may have an unused area. Only
the used area of the table is saved in files. When loading a table with empty or incomplete rows into a
spreadsheet application, empty rows typically introduce a default row (just as in an empty sheet), and
incomplete rows are filled with empty cells (just like in an empty sheet).
All other applications typically have fixed size tables. Incomplete rows are basically rendered as if they had the
necessary number of empty cells, and the same applies to empty rows. Empty cells typically occupy the space
of an empty paragraph.
§ 8.1.1, “Table Element”, schema fragment preceding sub-
section “Table Name”, p. 180
{The following text inserts three new lines in the definition of the pattern “table-rows” (lines 3579-3581 of the
amended schema) into the normative Relax-NG schema as reproduced in this section.}
3575
3576
3577
3578
3579
3580
3581
3582
3583
3584
3585
§ 8.1.1, “Table Element”, following sub-section “Print Ranges”,
p. 181
{The following text inserts a new sub-section.}
Soft Page Breaks
The element represents a soft page break between two table rows. It may
appear in front of elements .
See section 2.3.1:Use Soft Page Breaks for details regarding soft page breaks.
© ISO/IEC 2012 – All rights reserved 9
---------------------- Page: 13 ----------------------
ISO/IEC 26300:2006/Amd.1:2012(E)
§ 8.1.2, “Table Row”, sub-section “Default Cell Style”,
paragraph 1, p. 182
The table:default-cell-style-name attribute specifies a default cell style. Cells contained in the row
that don't have a table:style- name attribute use this without an individual cell style use these default cell
style.
§ 8.1.2, “Table Row”, sub-section “Default Cell Style”, following
paragraph 1, p. 182
{The following text inserts a new paragraph.}
The attribute is applied to cells that are defined by a element. It is typically not
applied to table cells that spreadsheet application may display in addition to those defined in the document.
§ 8.1.3, “Table Cell”, paragraph 2, p. 184
The element is very similar to the table cell elements of [XSL] and [HTML4], and the
rules regarding cells that span several columns or rows that exist in HTML and XSL apply to the
OpenDocument specification as well. This means that there are no elements in the
row/column grid for positions that are covered by a merged cell, that is, that are covered by a cell that spans
several columns or rows. The element exists to be able to specify cells for
such positions . It has to appear wherever a position in the row/column grid is covered by a cell that spans
several rows or columns. Its position in the grid is calculated by a assuming a column and row span of 1 for all
cells regardless whether they are specified by a or a
cell> element. The is especially used by spreadsheet applications,
where it is a common use case that a covered cell contains content.
§ 8.1.3, “Table Cell”, sub-section “Cell Content Validation”,
paragraph 1, p. 185
The table:content-validation-name attribute specifies if a cell contains a validity check. The value of
this attribute is the name of a element. If the attribute is not
present, the cell may have arbitrary content.
§ 8.1.3, “Table Cell”, sub-section “Cell Content Validation”,
paragraph 2, p. 186
See section 8.5.3 for more information on cell content validation and the
validation> element.
§ 8.2.1, “Column Description”, sub-section “Default Cell Style”,
paragraph 1, p. 190
The table:default-cell-style-name attribute specifies the default cell style. Cells that don't have a
table:style-name attribut ewithout a style use this style when there is no default cell style specified for the
cell's row as well.
10 © ISO/IEC 2012 – All rights reserved
---------------------- Page: 14 ----------------------
ISO/IEC 26300:2006/Amd.1:2012(E)
§ 8.2.1, “Column Description”, sub-section “Default Cell Style”,
following paragraph 1, p. 190
{The following text inserts a new paragraph.}
The attribute is applied to cells that are defined by a element. It is typically not
applied to table cells that spreadsheet application may display in addition to those defined in the document.
§ 8.2.2, “Header Columns”, preceding paragraph 1, p. 190
{The following text inserts a new paragraph at the start of the section.}
For accessibility purposes, header information is needed. Therefore, any columns designated as headers by
the author must be tagged as such by encapsulating them within a
element. Using style information only to designate header columns is insufficient.
§ 8.2.2, “Header Columns”, paragraph 1, p. 190
If a table does not fit on a single page, a set of adjacent table columns can be automatically repeated on every
page. To do so, their columns descriptions have to be included in a
element. Descriptions of columns that shall not be repeated on every page can be included into a
element, but don't have to. table columns that are included in a
header-columns> element are automatically repeated on every page . A table must not contain more than
one element, and a must not follow
another element. T, with the only exception areof tables that contain grouped
columns (see 8.2.3). Such tables may contain more than one element,
provided that they are contained in different column groups and the columns contained in the elements are
adjacent.
§ 8.2.4, “Header Rows”, preceding paragraph 1, p. 191
{The following text inserts a new paragraph at the start of the section.}
For accessibility purposes, header information is needed. Therefore, any rows designated as headers by the
author must be tagged as such by encapsulating them within a
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.