SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
|
| News: Cover Stories |  |  |
| Office Open XML File Formats Published as ISO/IEC 29500:2008 Final Standard. |
Contents
Announcements from the ISO/IEC JTC 1/SC 34 Secretariat and ISO News Media reported on the publication of the Office Open XML File Formats specification as an ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission) joint standard. A new ISO "Document Interoperability" Working Group has been established to help align this ISO/IEC 29500 Standard with ISO/IEC 26300 (OpenDocument). The four-part standard is freely available online, or on CD ROM from the ISO Store.
ISO/IEC 29500 "specifies a family of XML schemas, collectively called Office Open XML, which define the XML vocabularies for word-processing, spreadsheet, and presentation documents, as well as the packaging of documents that conform to these schemas."
"The goal is to enable the implementation of the Office Open XML formats by the widest set of tools and platforms, fostering interoperability across office productivity applications and line-of-business systems, as well as to support and strengthen document archival and preservation, all in a way that is fully compatible with the existing corpus of Microsoft Office documents."
ISO/IEC 29500 consists of the following four parts, under the general title Information technology — Document description and processing languages — Office Open XML File Formats:
"ISO/IEC 29500 was prepared by Ecma International (as ECMA-376:2006) and was adopted, under a special 'fast-track procedure', by Joint Technical Committee ISO/IEC JTC 1, Information technology, in parallel with its approval by the national bodies of ISO and IEC."
"ISO/IEC 29500 defines a set of XML vocabularies for representing word-processing documents, spreadsheets and presentations. On the one hand, the goal of ISO/IEC 29500 is to be capable of faithfully representing the preexisting corpus of word-processing documents, spreadsheets and presentations that had been produced by the Microsoft Office applications (from Microsoft Office 97 to Microsoft Office 2008, inclusive) at the date of the creation of ISO/IEC 29500. It also specifies requirements for Office Open XML consumers and producers. On the other hand, the goal is to facilitate extensibility and interoperability by enabling implementations by multiple vendors and on multiple platforms."
Several organizations have participated in the creation of ISO/IEC 29500, "and their contributions have been gratefully acknowledged: Apple, Barclays Capital, BP, The British Library, Essilor, Intel, Microsoft, NextPage, Novell, Statoil, Toshiba, and the United States Library of Congress."
Doug Mahugh, Senior Product Manager at Microsoft and leader of Office Open XML team reported that
the final published standard "includes all of the changes agreed to at the BRM, including the strict-vs-transitional structure and many others from the various national bodies involved. This has been a global process, with participation from dozens of countries and hundreds of individuals. The final text, reflecting all of those contributions, was prepared by project editor Rex Jaeschke and his BRM assistant Tristan Davis in recent months.
Going forward, the IS29500 standard will be maintained by Working Group 4 (WG4) of SC 34. This working group was formed at the SC 34 plenary in Jeju (Korea), based on the planning work that has been done in last spring's SC 34 plenary in Oslo, and the two-day meeting of AHG1 in London in July. AHG1 is an 'ad-hoc group' that was formed to create WG4, led by Alex Brown of the UK. Murata Makoto is the chair of WG4..."
Information technology — Document description and processing languages — Office Open XML File Formats — Part 1: Fundamentals and Markup Language Reference. Technologies de l'information — Description des documents et langages de traitement — Formats de fichier "Office Open XML" — Partie 1: Principes essentiels et référence de langage de balisage. ZIP file format with PDF. International Standard. ISO/IEC 29500-1. First edition: 2008-11-15. 5572 pages. Reference number: ISO/IEC 29500-1:2008(E). Copyright © ISO/IEC 2008. Annexes A, G and H form a normative part of this Part of ISO/IEC 29500. Annexes B-F and I-N are for information only. This Part of ISO/IEC 29500 includes five annexes (Annex A, Annex B, Annex G, Annex H, and Annex I) that refer to data files provided in electronic form.
Electronic inserts for Part 1: Fundamentals and Markup Language Reference. This ZIP archive contains file packages, in files OfficeOpenXML-DrawingMLGeometries.zip,
OfficeOpenXML-RELAXNG-Strict.zip,
OfficeOpenXML-SpreadsheetMLStyles.zip,
OfficeOpenXML-WordprocessingMLArtBorders.zip,
OfficeOpenXML-XMLSchema-Strict.zip. Total files: 1432. See the complete file listing.
ISO/IEC 29500-1:2008 is also available from the ISO Store.
Table of Contents for Part 1: Fundamentals and Markup Language Reference
Introduction
1. Scope
2. Conformance
3. Normative References
4. Terms and Definitions
5. Notational Conventions
6. Acronyms and Abbreviations
7. General Description
8. Overview
8.1 Packages and Parts
8.2 Consumers and Producers
8.3 WordprocessingML
8.4 SpreadsheetML
8.5 PresentationML
8.6 Supporting MLs
9. Packages
10. Markup Compatibility and Extensibility
11. WordprocessingML
12. SpreadsheetML
13. PresentationML
14. DrawingML
15. Shared
16. Part Overview
17. WordprocessingML Reference Material
18. SpreadsheetML Reference Material
19. PresentationML Reference Material
20. DrawingML - Framework Reference Material
21. DrawingML - Components Reference Material
22. Shared MLs Reference Material
23. Custom XML Schema References
Annex A. (normative) Schemas - W3C XML Schema
Annex B. (informative) Schemas - RELAX NG
Annex C. (informative) Additional Syntax Constraints
Annex D. (informative) Namespace Prefix Mapping in Examples
Annex E. (informative) Processing Bitfields with XSLT
Annex F. (informative) WordprocessingML Custom XML Data Extraction
Annex G. (normative) WordprocessingML Page Borders
Annex H. (normative) Predefined SpreadsheetML Style Definitions
Annex I. (informative) Example Predefined DrawingML Shape and Text Geometries
Annex J. (informative) Bidirectional Support
Annex K. (informative) Accessibility Best Practices
Annex L. (informative) Root Element Locations
Annex M. (informative) Primer
Annex N. (informative) Differences Between ISO/IEC 29500:2008 and ECMA-376:2006
Information technology — Document description and processing languages — Office Open XML File Formats — Part 2: Open Packaging Conventions. Technologies de l'information — Description des documents et langages de traitement — Formats de fichier "Office Open XML" — Partie 2: Conventions de paquetage ouvert. ZIP file format with PDF. International Standard. ISO/IEC 29500-2. First edition: 2008-11-15. 138 pages. Reference number: ISO/IEC 29500-2:2008(E). Copyright © ISO/IEC 2008. Annexes A, B, C, D and F form a normative part of this Part of ISO/IEC 29500. Annexes E, G, H, I and J are for information only. This Part of ISO/IEC 29500 includes two annexes (Annex D and Annex E) that refer to data files provided in electronic form.
Electronic inserts for Part 2: Open Packaging Conventions. This ZIP archive contains the files OpenPackagingConventions-RELAXNG.zip and OpenPackagingConventions-XMLSchema.zip. See the complete file listing for the .rnc and .xsd files (opc-contentTypes.rnc, opc-contentTypes.xsd, opc-coreProperties.rnc, opc-coreProperties.xsd, opc-digSig.rnc, opc-digSig.xsd, opc-relationships.rnc, opc-relationships.xsd, xml.rnc).
ISO/IEC 29500-2:2008 is also available from the ISO Store. Information technology — Document description and processing languages — Office Open XML File Formats — Part 3: Markup Compatibility and Extensibility. Technologies de l'information — Description des documents et
langages de traitement — Formats de fichier "Office Open XML" —
Partie 3: Compatibilité et extensibilité du balisage. ZIP file format with PDF. International Standard. ISO/IEC 29500-3. First edition: 2008-11-15. 48 pages. Reference number: ISO/IEC 29500-3:2008(E). Copyright © ISO/IEC 2008.
ISO/IEC 29500-3:2008 is also available from the ISO Store. Information technology — Document description and processing languages — Office Open XML File Formats — Part 4: Transitional Migration Features. Technologies de l'information — Description des documents et langages de traitement — Formats de fichier "Office Open XML" — Partie 4: Caractéristiques de migration transitoire. ZIP file format with PDF. International Standard. ISO/IEC 29500-4. First edition: 2008-11-15. 1476 pages. Reference number: ISO/IEC 29500-4:2008(E). Copyright © ISO/IEC 2008.
Annex A forms a normative part of this Part of ISO/IEC 29500. Annexes B, C, and D are for information only. This Part of ISO/IEC 29500 includes two annexes (Annex A and Annex B) that refer to data files provided in electronic form. Normative Annex A. "Schemas - W3C XML Schema". Informative Annex B. "Schemas - RELAX NG". Informative Annex C. "Namespace Prefix Mapping in Examples". Informative Annex D. "Differences Between ISO/IEC 29500:2008 and ECMA-376:2006".
Electronic Inserts for Part 4: Transitional Migration Features. The ZIP file contains two archives: OfficeOpenXML-RELAXNG-Transitional.zip and OfficeOpenXML-XMLSchema-Transitional.zip. Total files: 119. See the complete file listing.
ISO/IEC 29500-4:2008 is also available from the ISO Store.
The following excerpts from the 4-part specification are intended to provide an overview of the technology. This extracted/adapted text is unoffical; please consult the official documents as referenced above for Part 1, Part 2, Part 3, and Part 4. Excerpts are provided for Part 1, Part 2, Part 3, and Part 4.
Part 1: Fundamentals and Markup Language Reference
This Part of ISO/IEC29500 specifies concepts for documents and applications of both strict and transitional conformance.
From Section 8 "[Informative] Overview":
8.1 Packages and Parts: "An Office Open XML document is represented as a series of related parts that are stored in a container called a package. Information about the relationships between a package and its parts is stored in the package's package-relationship ZIP item. Information about the relationships between two parts is stored in the partrelationship ZIP item for the source part. A package is an ordinary ZIP archive, which contains that package's content-type item, relationship items, and parts. (Packages are discussed further in ISO/IEC 29500-2).
A WordprocessingML document contains a part for the body of the text; it might also contain a part for an image referenced by that text, and parts defining document characteristics, styles, and fonts. A SpreadsheetML document contains a separate part for each worksheet; it might also contain parts for images. A PresentationML document contains a separate part for each slide..."
8.2 Consumers and Producers: "A tool that can read and understand a package is called a consumer, while one that can create a package is called a producer. An application can be a consumer, a producer, or both. For example, when a word processor creates a new document, it acts as a producer. When it is used to open an existing document for reading or search purposes, it acts as a consumer. When it is used to open an existing document, edit it, and save the result, it acts as both consumer and producer. Similar scenarios exist for spreadsheet and presentation applications."
8.3 WordprocessingML: "A WordprocessingML package has a relationship of type officeDocument, which specifies the location of the main part in the package. For a WordprocessingML document, that part contains the main text of the document.
A WordprocessingML package's main part starts with a word processing root element. That element contains a body, which, in turn, contains one or more paragraphs (as well as tables, pictures, and the like). A paragraph contains one or more runs, where a run is a container for one or more pieces of text having the same set of properties. Like many elements that defined a logical piece of a word processing document, each run and paragraph can have associated with it a set of properties. For example, a run might have the property bold, which indicates that run's text is to be displayed in a bold typeface.
A WordprocessingML document is organized into sections, and the layout of a page on which the text appears within a section is controlled by that section's properties. For example, each section can have its own headers and footers.
One relationship from the document part specifies the document's styles. A style defines a text display format. A style can have properties, which can be applied to individual paragraphs or runs. Styles make runs more compact by reducing the number of repeated definitions and properties, and the amount of work required to make changes to the document's appearance. With styles, the appearance of all the pieces of text that share a common style can be changed in one place, in that style's definition.
A series of paragraphs can have numbering applied to them via a numbering definition instance or a numbering style. Data in a WordprocessingML document can be organized in a table, a two-dimensional grid of cells organized into rows and columns. Cells and whole tables can have associated properties. A cell can contain text and paragraphs, for example.
Text within a WordprocessingMLdocument can be determined dynamically via the use of fields. Fields consist of field instructions (the text that dictates the field's dynamic behavior) and the field result (the text resulting from the dynamic calculation of the field instructions. For example, page numbers are represented as fields. A hyperlink consists of two pieces of information: the hyperlink itself (the text the user clicks) and the target for the link. Potential targets include external files, e-mail addresses, web sites, and bookmarks within the document itself.
A WordprocessingML document can also contain custom markup, user-defined semantics applied to arbitrary document content.
A WordprocessingML document is not stored as one large body in a single part; instead, the elements that implement certain groupings of functionality are stored in separate parts. For example, all footnotes in a document are stored in one footnote part, while each section can have up to three different header parts and three different footer parts, to support headers and footers on odd-numbered pages, even-numbered pages, and the first page..."
8.4 SpreadsheetML: "A SpreadsheetML package has a relationship of type officeDocument, which specifies the location of the main part in the package. For a SpreadsheetML document, that part contains the workbook definition. A SpreadsheetML package's main part starts with a spreadsheet root element. That element is a workbook, which refers to one or more worksheets, which, in turn, contain the data. A worksheet is a two-dimensional grid of cells that are organized into rows and columns.
The cell is the primary place in which data is stored and operated on. A cell can have a number of characteristics, such as numeric, text, date, or time formatting; alignment; font; color; and a border. Each cell is identified by a cell reference, a combination of its column and row headings. Each horizontal set of cells in a worksheet is called a row, and each row has a heading numbered sequentially, starting at 1.
Each vertical set of cells in a worksheet is called a column, and each column has an alphabetic heading named sequentially from A-Z, then AA-AZ, BA-BZ, and so on. Instead of data, a cell can contain a formula, which is a recipe for calculating a value. Some formulas (called functions) are predefined, while others are user-defined. Examples of predefined formulas are AVERAGE, MAX, MIN, and SUM. A function takes one or more arguments on which it operates, producing a result. For example, in the formula SUM(B1:B4), there is one argument, B1:B4, which is the range of cells B1-B4, inclusive. Other features that a SpreadsheetML document can contain include the following: comments, hyperlinks, images, and sorted and filtered tables.
A SpreadsheetML document is not stored as one large body in a single part; instead, the elements that implement certain groupings of functionality are stored in separate parts. For example, all the data for a worksheet is stored in that worksheet's part, all string literals from all worksheets are stored in a single shared string part, and each worksheet having comments has its own comments part..."
8.5 PresentationML: "A PresentationML package has a relationship of type officeDocument, which specifies the location of the main part in the package. For a PresentationML document, that part contains the presentation definition.
A PresentationML package's main part starts with a presentation root element. That element contains a presentation, which, in turn, refers to a slide list, a slide master list, a notes master list, and a handout master list. The slide list refers to all of the slides in the presentation; the slide master list refers to all of the slide masters used in the presentation; the notes master contains information about the formatting of notes pages; and the handout master describes how a handout looks.
A handout is a printed set of slides that can be handed out to an audience for future reference. As well as text and graphics, each slide can contain comments and notes, can have a layout, and can be part of one or more custom presentations. (A comment is an annotation intended for the person maintaining the presentation slide deck. A note is a reminder or piece of text intended for the presenter or the audience.) Other features that a PresentationML document can contain include the following: animation, audio, video, and transitions between slides.
A PresentationML document is not stored as one large body in a single part; instead, the elements that implement certain groupings of functionality are stored in separate parts. For example, all comments in a document are stored in one comment part while each slide has its own part..."
8.6 Supporting MLs: "The three markup languages described above define the structure of a package that is either a document (WordprocessingML), a spreadsheet (SpreadsheetML), or a presentation (PresentationML). However, there is also a set of shared markup languages used for common elements such as charts, diagrams, and drawing objects...
8.6.1 DrawingML — DrawingML specifies the location and appearance of drawing elements in a package. For example, these elements could be, but are not limited to, shapes, pictures, and tables. The root element of a DrawingML XML fragment specifies the presence of a drawing at this location in the document.
8.6.2 Custom XML Data Properties — Custom XML Data properties allow the ability to store arbitrary XML in a package, along with schema information used by that XML.
8.6.3 File Properties — The core file properties of a package enable users to discover, get, and set common sets of properties from within that package, regardless of whether it's a WordprocessingML, SpreadsheetML, or PresentationML package, or another use of OPC. Such properties include creator name, creation date, title, and description. Extended file properties are specific to Office Open XML packages. For example, for a WordprocessingML package, these properties include the number of characters, words, lines, paragraphs, and pages in the document. For a SpreadsheetML package, these properties include worksheet titles. For a PresentationML package, these properties include presentation format, the number of slides, the number of notes, and whether or not any slides are hidden. Custom file properties are defined by the user. Examples include the name of the client for whom the document was prepared, a date/time on which some event happened, a document number, or some Boolean status flag. Each custom file property has a value, and that value has a data type.
8.6.4 Math — Math is used, mainly in documents, to specify the structure and appearance of equations. The outermost root element can be either oMath or oMathPara, the latter being a math paragraph with one or more equations where each equation is specified using a single oMath element.
8.6.5 Bibliography — Bibliography specifies the structure for all references stored within a document, for use in citations or a bibliography. End of informative text.
Part 2: Open Packaging Conventions
From the Scope Statement:
This Part of ISO/IEC 29500 specifies a set of conventions that are used by Office Open XML documents to define the structure and functionality of a package in terms of a package model and a physical model.
The package model is a package abstraction that holds a collection of parts. The parts are composed, processed, and persisted according to a set of rules. Parts can have relationships to other parts or external resources, and the package as a whole can have relationships to parts it contains or to external resources. The package model specifies how the parts of a package are named and related. Parts have content types and are uniquely identified using the well-defined naming rules provided in this Part of ISO/IEC 29500.
The physical mapping defines the mapping of the components of the package model to the features of a specific physical format, namely a ZIP archive.
This Part of ISO/IEC 29500 also describes certain features that might be supported in a package, including core properties for package metadata, a thumbnail for graphical representation of a package, and digital signatures of package contents.
Because this Part of ISO/IEC 29500 might evolve, packages are designed to accommodate extensions and to support compatibility goals in a limited way. The versioning and extensibility mechanisms described in Part 3 support compatibility between software systems based on different versions of this Part of ISO/IEC 29500 while allowing package creators to make use of new or proprietary features.
This Part of ISO/IEC 29500 specifies requirements for documents, producers, and consumers. Conformance requirements are identified throughout the text of this Part of ISO/IEC 29500. A formal conformance statement is given in [Section] 2. An informative summary of requirements relevant to particular classes of developers is given in Annex H.
From the Overview:
"This Open Packaging specification describes an abstract model and physical format conventions for the use of XML, Unicode, ZIP, and other openly available technologies and specifications to organize the content and resources of a document within a package. It is intended to support the content types and organization for various applications and is written for developers who are building systems that process package content.
In addition, this Open Packaging specification defines common services that can be included in a package, such as Core Properties and Digital Signatures.
A primary goal is to ensure the interoperability of independently created software and hardware systems that produce or consume package content and use common services. This Open Packaging specification defines the formal requirements that producers and consumers must satisfy in order to achieve interoperability.
Various XML-based building blocks within a package make use of the conventions described in Part 3 to facilitate future enhancement and extension of XML markup. That part must be cited explicitly by any markup specification that bases its versioning and extensibility strategy on Markup Compatibility elements and attributes..."
From Section 9, "Package Model":
"A package is a logical entity that holds a collection of parts. The purpose of the package is to aggregate all of the pieces of a document (or other type of content) into a single object. [Example: A package holding a document with a picture might contain two parts: an XML markup part representing the document, and another part representing the picture. end example] The package is also capable of storing relationships between parts.
The package provides a convenient way to distribute documents with all of their component pieces, such as images, fonts, and data. Although this Open Packaging specification defines a single-file package format, the package model allows for the future definition of other physical package representations. [Example: A package could be represented physically in a collection of loose files, in a database, or ephemerally in transit over a network connection. end example]
This Open Packaging specification also defines a URI scheme, the pack URI, that allows URIs to be used as a uniform mechanism for addressing parts within a package..."
From the Annexes:
Normative Annex A. "Resolving Unicode Strings to Part Names". — "Package clients might use strings of Unicode characters to represent relative references to parts in a package. Further in this Annex, such strings are referred to as Unicode strings... This annex specifies how such Unicode strings shall be resolved to part names..." Normative Annex B. "Pack URI". — "A package is a logical entity that holds a collection of parts. This Open Packaging specification defines a way to use URIs to reference part resources inside a package. This approach defines a new scheme in accordance with the guidelines in RFC 3986. The following terms are used as they are defined in RFC 3986: scheme, authority, path, segment, reserved characters, sub-delims, unreserved characters, pchar, pct-encoded characters, query, fragment, and resource..."
Normative Annex C. "ZIP Appnote.txt Clarifications". — "The ZIP specification includes a number of features that packages do not support. Some ZIP features are clarified in the context of this Open Packaging specification. Package producers and consumers shall adhere to the requirements noted [in Annex C]..." Normative Annex D. "Schemas - W3C XML Schema". — "This Part of ISO/IEC 29500 includes a family of schemas defined using the W3C XML Schema 1.0 syntax. The normative definitions of these schemas follow below, and they also reside in an accompanying file named OpenPackagingConventions-XMLSchema.zip, which is distributed in electronic form..." Informative Annex E. "Schemas - RELAX NG". — "This Part of ISO/IEC 29500 includes a family of schemas defined using the RELAX NG syntax. The definitions of these schemas follow below, and they also reside in an accompanying file named OpenPackagingConventions-RELAXNG.zip, which is distributed in electronic form. If discrepancies exist between the RELAX NG version of a schema and its corresponding XML Schema, the XML Schema is the definitive version..." Normative Annex F. "Standard Namespaces and Content Types". — The namespaces available for use in a package are listed in Table F-1, Package-wide namespaces. Table F-2. lists Package-wide content types. Informative Annex G. "Physical Model Design Considerations". — "The physical model defines the ways in which packages are produced and consumed. This model is based on
three components: a producer, a consumer, and a pipe between them." Informative Annex H. "Guidelines for Meeting Conformance". — This annex summarizes best practices for producers and consumers implementing the Open Packaging Conventions. It is intended as a convenience; the text in the referenced clause or subclause is considered normative in all cases. Informative Annex I. "Differences Between ISO/IEC 29500:2008 and ECMA-376:2006". — XML element included in ISO/IEC 29500:2008 but not included in ECMA-376:2006: The value element (in the Core Properties Part schema in Section D.2); XML element included in ECMA-376:2006 but not included in ISO/IEC 29500:2008: The contentType element (in the Core Properties Part schema in Section D.2) Informative Annex J. "Index".
Part 3: Markup Compatibility and Extensibility
From the Overview:
"This Part of ISO/IEC 29500 describes a set of XML elements and attributes whose purpose is to collectively enable producers to explicitly guide consumers in their handling of any XML elements and attributes not understood by the consumer.
These elements and attributes are intended to enable the creation of future versions of and extensions to ISO/IEC 29500, while enabling these desirable compatibility goals:
- A markup producer can produce markup documents that exploit new features defined by versions and extensions, yet remain interoperable with markup consumers that are unaware of those versions and extensions.
- For any such markup document, a markup consumer whose implementation is aware of the exploited versions and extensions can deliver functionality that is enhanced by the markup document's use of those versions and extensions.
- For any such markup document, the markup producer can enable and precisely control graceful
degradation that might occur when the markup document is processed by a markup consumer that is
unaware of the exploited versions and extensions.
From Section 9 "Markup Compatibility Fundamentals", 9.1 "Core Concepts":
"Any XML-based document specification can use the markup language described in this Part of ISO/IEC 29500 as the basis of its compatibility with previous and future specification revisions, and to enable the creation of independent extensions of its specification.
This Part of ISO/IEC 29500 is dependent on XML namespace names, expressed as URIs. A markup specification defines a set of elements and attributes within one or more namespaces. A characteristic of a markup consumer is that it can recognize the elements and attributes within understood namespaces, including those containing elements and attributes defined in the markup specification. Markup consumers shall treat all recognized elements and attributes of any understood namespace according to the requirements of the markup specifications defining those elements or attributes.
A markup specification might require that the presence of unrecognized elements or attributes in an understood namespace be treated as an error condition; however, markup consumers shall always treat the presence of an unrecognized element or attribute from the Markup Compatibility namespace as an error condition. If a markup consumer encounters an element or attribute from a non-understood namespace, the markup consumer shall treat the presence of that element or attribute as an error condition, unless the markup producer has embedded in the markup document explicit Markup Compatibility elements or attributes that override that behavior.
Within a markup document, a markup producer might use Markup Compatibility attributes to identify ignorable namespaces. Markup consumers shall ignore elements and attributes from namespaces that are both non-understood and ignorable, and shall not treat their presence as errors. A markup producer can indicate to the markup consumer whether the content of an ignored element shall be disregarded together with the ignored element, or if the content should be processed as if it was content of the ignored element's parent, located in the same contextual position as the ignored element.
Within a markup document, a markup producer might also use Markup Compatibility attributes to suggest to a markup editor that the editor attempt to preserve some ignored elements or attributes. The markup editor can attempt to persist these ignored elements and attributes when saving a markup document, despite the editor's inability to recognize the purpose of these ignored elements and attributes.
A markup producer, aware of the existence of markup consumers with overlapping but different sets of understood namespaces, might choose to include in a markup document alternate content regions, each holding a set of markup alternatives for use by different markup consumers. A markup consumer shall use rules embedded in the markup document by the markup producer to select no more than one of these alternatives for normal processing, and shall disregard all other alternatives.
Future versions of markup specifications shall specify new namespaces for any markup that is enhanced or modified by the new version, which a markup consumer of that version of the markup specification would include as an understood namespace. Some of the namespaces introduced in the new markup specification might each subsume one of the previous version's understood namespaces. A new understood namespace subsumes a previously understood namespace if it includes all of the elements, attributes, and attribute values of the previously-understood namespace and uses identically the element local names, prefixed and unprefixed attribute names, attribute values, and element contents. Regardless of whether a new namespace subsumes a previously defined namespace, markup consumers based on a new version of a markup specification shall support all understood namespaces of the previous version unless the new version makes an explicit statement to the contrary.
This Part of ISO/IEC 29500 can be implemented using a preprocessing architecture in the form of a software module called a markup preprocessor. A markup preprocessor can use the Markup Compatibility elements and attributes to produce output that is free of all ignorable non-understood content, all Markup Compatibility elements and attributes, and all elements and attributes in subsumed namespaces. Markup consumers should report errors when processing non-conforming documents...
From Informative "Annex A. Validation Using NVDL":
"Namespace-based Validation Dispatching Language (NVDL) allows documents to be decomposed into
validation candidates, each of which can be validated independently. NVDL can be used for validation against the normative requirements of this Part of ISO/IEC 29500.
It can also be used for validation against the combination of Office Open XML documents (including the elements and attributes defined in this Part of ISO/IEC 29500) and any extensions.
A.1 Validation Against Requirements of this Part of ISO/IEC 29500: A markup document can satisfy requirements of this Annex without being an Office Open XML document. The following NVDL script examines whether a given document correctly uses the attributes and elements as defined by this Part of ISO/IEC 29500. This NVDL script first extracts elements and attributes in the Markup Compatibility namespace, and then validates them against the appropriate RELAX NG schemas...
A.2 Validation Against the Combination of Office Open XML and Extensions: An extension of Office Open XML specified using the mechanisms defined in this Part of ISO/IEC 29500 can be captured by an NVDL script that invokes the Office Open XML schema and schemas for the extension..."
Part 4: Transitional Migration Features
From the Scope Statement:
"This Part of ISO/IEC 29500 defines features for backward-compatibility and that are useful for high-quality migration of existing binary documents to ISO/IEC 29500. These features shall only be used by documents of conformance class WML Transitional, SML Transitional, or PML Transitional..."
From Section 7 "General Description"
This Part is intended for use by implementers, academics, and application programmers. As such, it contains a considerable amount of explanatory material that, strictly speaking, is not necessary in a formal specification.
Examples are provided to illustrate possible forms of the constructions described. References are used to refer to related clauses. Notes are provided to give advice or guidance to implementers or programmers. Rationale provides explanatory material as to why something is or is not in ISO/IEC 29500. Annexes provide additional information or summarize the information contained in ISO/IEC 29500...
From Section 2.1 "Document Conformance"
Document conformance is purely syntactic.
- A conforming document shall conform to the transitional W3C XML Schema, and any additional syntax constraints.
- The document shall be of category Wordprocessing, Spreadsheet, or Presentation (see Part 1, Section 4).
- The document character set shall conform to the Unicode Standard and ISO/IEC 10646:2003, with either the UTF-8 or UTF-16 encoding form, as required by the XML 1.0 standard.
- Any XML element or attribute not explicitly included in ISO/IEC 29500 shall use the extensibility mechanisms described by ISO/IEC 29500-1 and ISO/IEC 29500-3.
Each Part of this multi-part standard has its own conformance clause. The term conformance class is used to disambiguate conformance within different Parts of this multi-part standard. This Part of ISO/IEC 29500 defines the following document conformance classes:
- WML Transitional, if the document is a conforming document of category Wordprocessing that
conforms to the transitional schema.
- SML Transitional, if the document is a conforming document of category Spreadsheet that conforms to the transitional schema.
- PML Transitional, if the document is a conforming document of category Presentation that conforms to the transitional schema...
From the Annexes
Normative Annex A. "Schemas - W3C XML Schema". — "This Office Open XML specification includes a family of schemas defined using the W3C XML Schema 1.0 syntax. The normative definitions of these schemas follow below, and they also reside in an accompanying file named OfficeOpenXML-XMLSchema-Transitional.zip, which is distributed in electronic form." Informative Annex B. "Schemas - RELAX NG". — "This annex is informative. This Office Open XML specification includes a family of schemas defined using the RELAX NG syntax. The definitions of these schemas follow below, and they also reside in an accompanying file named OfficeOpenXMLRELAXNG-Transitional.zip, which is distributed in electronic form. Informative Annex C. "Namespace Prefix Mapping in Examples". — "This Annex is informative. Throughout ISO/IEC 29500, XML syntax is provided to illustrate the concepts being documented. These examples leverage XML namespace prefixes, and, typically, for brevity, do not show the actual namespace mappings. This Annex lists the namespace prefix mappings that are used within these examples. Informative Annex D. "Differences Between ISO/IEC 29500:2008 and ECMA-376:2006"
Formerly, many ISO publications were available only in paper or PDF format via purchase through the ISO Store or one of the NBs. In response to increasing user demand, ISO has begun making some of its standards freely available on the Internet ("made freely available for standardization purposes"): see Freely Available Standards. The following license terms (along with other international laws and conventions) are applicable to use of the downloaded ISO standards. In addition, for the ISO/IEC 29500:2008 standards discussed in this story, ISO has included Adobe licensing terms in the individual PDFs.
Licence Agreement for standards made available through the [ISO/IEC] Information Technology Task Force (ITTF) web site (Version française):
You are about to download a document made available to you exclusively for standardization purposes and which is protected by copyright law in your country.
The unauthorized reproduction or distribution of this copyrighted work is illegal and may be punishable by criminal law.
The document is a single-user, non-revisable Adobe Acrobat PDF file. You are downloading a single-user licence to store this file on your personal computer. Under no circumstances may the electronic file you are licensing be copied, transferred, or placed on a network of any sort without the authorization of the copyright owner.
You may print out and retain one-only printed copy of the PDF file.
This printed copy is fully protected by national and international copyright laws, and may not be photocopied or reproduced in any form. Under no circumstances may it be resold.
While all reasonable care is taken in the preparation and review of ISO International Standards and other deliverables, ISO does not warrant that the content of the document is accurate or up to date or that the document will be suitable for your purposes.
To the extent allowed in applicable law, in no event shall ISO be liable for any direct, indirect, punitive, incidental, special, consequential damages, or any damages whatsoever arising out of or connected with the use or misuse of this document.
This transaction is governed by and construed in accordance with the laws of Switzerland.
If you have any difficulties concerning the above terms or if you have any questions regarding copyright, please contact the following address:
ISO Copyright Office
Case postale 56
CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
Email: copyright@iso.org
WWW: http://www.iso.org
Adobe Licensing Policy
Notice provided in the ISO/IEC 29500:2008 PSD documents:
PDF Disclaimer: "This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but [emphasis added] shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address..."
A new Working Group 5 on 'Document Interoperability' was recently established within ISO/IEC JTC 1/SC 34, focused initially upon interoperability between the OpenDocument and Office Open XML File Formats (OOXML) ISO standards.
ISO/IEC JTC1 SC34 Business Plan. Period: December 2007 to October 2008. By Sam Oh, JTC1/SC34 Acting Chair (Korea) and Toshiko Kimura, JTC1/SC34 Secretariat (Japan). Page 10: "SC34 intends to act as good stewards for the two major office document formats for which it has responsibility: ISO/IEC 26300 [Open Document Format for Office Applications (OpenDocument)] and ISO/IEC 29500 [Office Open XML File Formats / OOXML]. Such work is critical to the millions of users of these formats over the World. The priority in the coming year is to establish effective functioning of SC34's new working groups that are concerned with ISO/IEC 29500 maintenance and interoperability between the two formats; and to increase our collaboration with OASIS on ISO/IEC 26300 maintenance..."
Professor Jaeho LEE (University of Seoul) has been appointed WG 5 Convenor for a three-year term. He is also SC 34 Project Editor for Project 13250-4 (Information technology — Topic Maps — Part 4: Canonicalization) and for Project 13250-7 (Information technology — SGML applications — Topic maps — Part 7: Graphical Notation).
According to Secretariat Report, WG 5 Document Interoperability: From ISO/IEC JTC 1/SC 34. Date: 2008-10-28. "SC 34/WG 5: Document Interoperability, Convener: Dr. Jaeho LEE [-KATS]. Terms of reference: Develop principles of, and guidelines for, interoperability among documents represented using heterogeneous ISO/IEC document file formats. The initial work includes preparation of the Technical Report on ISO/IEC 26300 [OpenDocument] / ISO/IEC 29500 [OOXML] translation."
A blog article by Doug Mahugh reports that: "We debated the scope of the work of WG5, the new working group on document interoperability, and there was broad consensus that this WG should focus on interoperability between approved ISO/IEC standards. The planned translation report from WG5 will cover interoperability between ISO/IEC 26300 and ISO/IEC 29500. Working Group 5 on document interoperability was established, with the initial work item being the report in translation between ISO/IEC 26300 and ISO/IEC 29500. Dr. Jaeho Lee (Korea) was appointed Convenor of WG5..."
From Resolutions of ISO/IEC JTC 1/SC 34 Plenary Meeting, 2008-10-01, Jeju, Republic of Korea, see:
- Resolution 8: Establishment of Working Group 5. SC 34 establishes Working Group 5 as follows: Title: Document Interoperability. Terms of Reference: Develop principles of, and guidelines for, interoperability among documents represented using heterogeneous ISO/IEC document file formats. The initial work includes preparation of the Technical Report on ISO/IEC 26300 — ISO/IEC 29500 translation. SC 34 instructs its Secretariat to issue a call for participation to the SC 34 members and to request ISO and IEC to publicise the existence of WG 5 to encourage participation from all who are eligible. Unanimous.
- Resolution 9: Appointment of WG 5 Convener. SC 34 appoints Dr. Jaeho Lee (Republic of Korea) as the Convener of WG 5 for a three-year term. Unanimous.
SC 34 Project 29166: Open Document Format (ISO/IEC 26300) / Office Open XML (ISO/IEC 29500) Translation. See Resolution 10: Response to Comments on NP for OpenDocument Format (ISO/IEC 26300) / Office Open XML (ISO/IEC 29500) Translation. "SC 34 approves SC 34 N 1097 as the disposition of comments on the New Work Item Proposal ballot and assigns Project 29166 to WG 5 for development. Unanimous." Also: Resolution 11: Appointment of Project Editors for 29166: Open Document Format (ISO/IEC 26300) / Office Open XML (ISO/IEC 29500) Translation. "SC 34 appoints Mr. Ning LI (China), and Mr. NAM, Dong Sun (Republic of Korea) as the co-editors of Project 29166 and notes that the National Body of Germany is expected to nominate a third co-editor. Unanimous." For earlier work, see NA 043-01-34-01 VT Working Group Translation 29500-26300. ISO/IEC NP 29166. Proposal for New Work Item on OpenDocument Format (ISO/IEC 26300) / Office Open XML (ISO/IEC 29500) Translation. Draft document. For purchase: ISO/IEC NP 29166. Proposal for New Work Item on OpenDocument Format (ISO/IEC 26300) / Office Open XML (ISO/IEC 29500) Translation. Result of voting: JTC1/SC34 N1035 (NWIP) "Proposal for New Work Item on OpenDocument Format (ISO/IEC 26300) / Office Open XML (ISO/IEC 29500) Translation."
See also information in ISO/IEC JTC 1/SC 34 N1106 ("Call for Participation - SC 34/WG 5: Document Interoperability") and ISO/IEC JTC 1/SC 34 N1099 ("Resolutions of ISO/IEC JTC 1/SC 34 Plenary Meeting, 2008-10-01, Jeju, Republic of Korea - Resolution 8: Establishment of Working Group 5").
"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 nongovernmental, 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.
ISO has developed over 17000 International Standards on a variety of subjects and 1100 new ISO standards are published every year..."
- Announcement:
- Specification sources:
- ISO and its standards:
- ISO/IEC JTC 1/SC 34:
- Office Open XML resources:
- Commentary:
|
 | Receive daily news updates from Managing Editor, Robin Cover.
 |
|
