Open Document Format for Office Applications (OpenDocument) Version 1.1 Errata 01
Working Draft 00 - Test03
23 May 2011
{EdNote 2011-01-22: This is a pre-WD01 test version based on the template for OASIS Errata Working Drafts. This document contains Editorial Notes serving as placeholders for pending work, explanations of the editorial approach and its status, and identification of provisional content.
Only Editorial Notes identifying provisional material are retained in Committee Drafts of the Errata. There shall be no Editorial Notes in the candidate Committee Draft for achievement of Errata Committee Specification/OASIS Approved Errata.
This document is used to demonstrate the approach to presentation and accounting for ODF 1.1 Errata 01 errata items. It is also used as a small manageable demonstration that the Errata items are properly preserved in the requisite PDF and HTML derivations that must be produced for Committee Drafts and beyond.
This Test03 version has minor adjustments. It is also being used to determine whether LibreOffice 3.4.0-rc1 is handling any of the conversions better than is the experience with 3.3.2, the current stable release.}
Abstract:
[Summary of the technical purpose of this document]
Status:
This Working Draft (WD) has been produced by one or more TC Members; it has not yet been voted on by the TC or approved as a Committee Draft (Committee Specification Draft or a Committee Note Draft). The OASIS document Approval Process begins officially with a TC vote to approve a WD as a Committee Draft. A TC may approve a Working Draft, revise it, and re-approve it any number of times as a Committee Draft.
Copyright © OASIS Open 2011. All Rights Reserved.
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.
[All text is normative unless otherwise labeled]
{EdNote 2011-05-21: This is the style of Editorial Notes added to Working Drafts as placeholders until they are acted on and removed. The ODF Style Name is “EdNote”, making it easy to hide all such notes. The use of a colored, bold text and bracketing is intended to make the notes easy to recognize and maintain.}
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].
{EdNote: Change to use the ISO/IEC Version of Conformance Language.}
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.
[Reference] [Full reference citation]
{EdNote 2011-05-21: Deal with this too. I assume that ODF 1.1 Specification is a Normative Reference. Perhaps there are normative references to the Errata Documents and, the COR1/2 and the AMD1, or else non-normative references. For the moment, I assume that related specifications are referenced non-normatively, since Errata are described as non-normative documents.}
[Reference] [Full reference citation]
NOTE: The proper format for citation of technical work produced by an OASIS TC (whether Standards Track or Non-Standards Track) is:
[Citation Label]
Work Product title (italicized). Approval date (DD Month YYYY). Stage Identifier and Revision Number (e.g., Committee Specification Draft 01). Principal URI (version-specific URI, e.g., with filename component: somespec-v1.0-csd01.html).
For example:
[CAP-1.2]
Common Alerting Protocol Version 1.2. 01 July 2010. OASIS Standard. http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html.
{Ed.Note: The Non-Normative References will be [ODF 1.0 Errata 01], [ODF 1.0 Errata 02], [COR1], [COR2], [AMD?], [ODF 1.0], [ODF 1.1], and [IS 26300]. }
{EdNote 2011-05-21: This is for an additional section that explains the table layout, the way that changes are described, and the various columns.}
{EdNote 2011-05-22: Tabulations in the Appendixes are not described.}
Section/ | Instruction | Issue | Source | Amd? |
{EdNote 2011-05-22: Will explain the use of underlining, strike-through, double underlining, text colors, ellipsis, and the “white brackets” around informational text outside of the changed text itself.}
{EdNote 2011-05-22: This section accounts for the association of an Errata item with related work, explaining the interdependency with establishment of textual equivalence between the ISO/IEC JTC1 International Standard for ODF and the ODF 1.1 OASIS Standard.}
{EdNote 2011-05-22: The Priority Issues to identify for Errata 01 are those with “Amd?” other than “-” and “Y”. That is so those can be introduced into the proposed Amendment before the final version is sent to ITTF. The second priority is those with “Y” since forwarding of the proposed Amendment is already conditional on those being reflected in the OASIS ODF 1.1 Errata 01.}
The Issue entry identifies the original defect report or ODF TC JIRA issue that led to the Errata item. Defect reports and JIRA issues that arose with respect to IS 26300:2006 and the ODF 1.0 OASIS Standard are identified when those issues also apply to the text of the ODF 1.1 OASIS Standard. If the Issue entry has a hyperlink, that will be to an ODF TC JIRA Issue that accounts for the issues disposition here.
For completeness, those issues that are not relevant to the ODF 1.1 OASIS Standard are accounted for in Appendix B.
The Source entry identifies any previous Errata or Corrigenda which has an item corresponding to a given item in this Errata. In that case, disposition here is equivalent to the disposition in the other specification. When the errata item arose originally with respect to the ODF 1.1 OASIS Standard, the source will be the TC or WG6 and the Issue will identify a JIRA issue that accounts for this disposition.
The “Amd?” entry when other than “-” indicates that there is a provisional requirement for reflection of this Errata item in the amendment of IS 26300:2006 for preservation of technical equivalence and practical text alignment with the ODF 1.1 OASIS Standard as supplemented by this Errata. An entry of “Y” indicates that the currently-proposed amendment already contains a provisional counterpart of the item.
An “Amd?” entry of “New” indicates that the errata item is not reflected in any IS 26300 Corrigenda nor the proposed amendment. Such items are recommendation for incorporation in the proposed amendment.
Other “Amd?” entries signify special circumstances. In all cases, non-”-”/”Y” entries are individually described further in Appendix C.
{EdNote 2011-05-22: Because the “Amd?” entries are provisional, and there are already reciprocal provisional dependencies in the proposed amendment, this aspect of the ODF 1.1 Errata 01 Working Drafts and Committee Drafts is subject to modification and possibly even elimination as ODF 1.1 with Errata 01 and the proposed amendment to IS 26300:2006 come into official alignment.}
{EdNote 2011-05-22: To ensure reliable application of the instructions, ensure that automatic hyphenation is disabled in the Instruction column.}
Section/ | Instruction | Issue | Source | Amd? |
1.3 | 〚In the Prefix column ofTable 1〛 drawing | COR2 | - | |
1.6 | 〚Change the entire section〛 1.6 White-Space Processing and EOL Handling ODF processing of whitespace characters is in conformance with the provisions of In conformance with the W3C XML specification [XML1.0]., In addition, ODF processors shall ignore all element children ([RNG] section 5, Data Model) of ODF-defined elements that are strings consisting entirely of whitespace characters and which do not satisfy a pattern of the ODF schema definition for the element. Any special treatment of additional occurrences of white-space characters depend on the specific definitions of individual ODF elements, attributes, and their datatypes. See, in particular, section 5.1.1. optional white-space characters that are contained in elements that have element content (in other words that must contain elements only but not text) are ignored. This applies to the following white-space and end-of-line (EOL) [UNICODE] characters: . . . 〚deleting the remainder of the section〛 . . . As a consequence of the white-space and EOL processing rules, any CARRIAGE RETURN characters that are contained either in the text content of an element or in an attribute value must be encoded by the character entity 
. The same applies to the HORIZONTAL TABULATION and LINE FEED characters if they are contained in an attribute value. | COR2 | - | |
2.1.1 | 〚Change the first paragraph of the section〛 The content models of the five root elements is summarized in the following table. Note that <office:document> may contain all supported top-level elements. AllNone of the four subdocument root elements contain the complete data, but four combined dotogether contain the same information as an <office:document> element that contains the same subdocument root elements. | N0942:41 | 1.0-01 | COR1 |
2.1.2/ Version | 〚Change the first paragraph of the subsection〛 All root elements take an office:version attribute, which indicates which version of this specification it complies with. The version number is in the format revision.version. If the file has a version known to an XML processor, it may validate the document. Otherwise, it is optional to validate the document, but the document must be well formed. | COR2 | - | |
2.3.1/ | 〚Change the fifth and sixth paragraph of the subsection〛 A generating application that stores soft page breaks shall indicate this by setting the text:use-page-breaks attribute to true. A generating application that does not store soft page breaks shall indicate that by omitting this attribute, or by setting it to false. An application that does not support pagination and soft page-breaks, that modifies an OpenDocument file, which includes soft page-breaks, shall at least set the text:use-page-breaks attribute to false (or remove it). It should also remove the <text:soft-page-break> elements from the document but is not required to do so. | WG6 | Y | |
15.4.19 | 〚Change the first sentence of the second paragraph〛 The value of these propertyies is either an absolute length or a percentage as described in §78.8.4 of [XSL]. | WG6 | New |
The last numbered section in the specification must be the Conformance section. Conformance Statements/Clauses go here.
{EdNote: There are no Conformance clauses in an Errata document, although the Errata might apply to conformance clauses and certainly normative text of the document to which the Errata instructions apply. This will be explained.}
The following individuals have participated in the creation of this specification and are gratefully acknowledged:
Participants:
[Participant Name, Affiliation | Individual Member]
[Participant Name, Affiliation | Individual Member]
{EdNote 2011-05-22: There are issues that are not reflected in ODF 1.1 Errata 01 because they do not apply to this text or they have been disposed of in some other manner. This informative Appendix provides an account of those so it can be understood why those issues are not reflected here. This material can also be used to verify that no previous issues and defect reports have been overlooked.}
Section/ | Explanation | Issue | Source | Amd? |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
{EdNote 2011-05-22: When an “Amd?” entry is other than “-” or “Y”, some synchronization activity may be required in aligning the proposed IS 26300:2006/Amd1 with the ODF 1.1 OASIS Standard with Errata 01. This informative appendix explains the nature of the reconciliation that is suggested. This is offered as assistance in the efforts of ISO/IEC JTC1 SC34 WG6 in assuring alignment of the amendment with ODF 1.1.}
Section/ | Explanation | Issue | Source | Amd? |
2.1.1 | The ISO-published [COR1] omits <office:document> before the word “element” in the added text at the end of the paragraph. This makes the change unintelligible. | N0942:41 | 1.0-01 | COR1 |
15.4.19 | This change corrects an incorrect [XSL] section reference reported against a different section in N0942:30. N0942:30 is now considered addressed. The correction should be reflected in IS 26300:2006/Amd1 as well. | WG6 | New | |
|
|
|
|
|
Revision | Date | Editor | Changes Made |
[Rev number] | [Rev Date] | [Modified By] | [Summary of Changes] |