1、 ECMA-376, 4th Edition Office Open XML File Formats Open Packaging Conventions December 2012 Table of Contents iii Table of Contents Foreword vii Introduction viii 1. Scope 1 2. Conformance . 2 3. Normative References 3 4. Terms and Definitions 5 5. Notational Conventions . 9 5.1 Document Convention
2、s . 9 5.2 Diagram Notes . 9 6. Acronyms and Abbreviations 11 7. General Description . 12 8. Overview . 13 9. Package Model 14 9.1 Parts . 14 9.1.1 Part Names 14 9.1.2 Content Types . 17 9.1.3 Growth Hint . 18 9.1.4 XML Usage . 18 9.2 Part Addressing . 19 9.2.1 Relative References . 19 9.3 Relationsh
3、ips . 20 9.3.1 Relationships Part 20 9.3.2 Relationship Markup . 20 9.3.3 Representing Relationships . 24 9.3.4 Support for Versioning and Extensibility . 26 10. Physical Package 27 10.1 Physical Mapping Guidelines . 27 10.1.1 Mapped Components 28 10.1.2 Mapping Content Types 28 10.1.3 Mapping Part
4、Names to Physical Package Item Names 33 10.1.4 Interleaving . 35 10.2 Mapping to a ZIP Archive 37 10.2.1 Mapping Part Data 37 10.2.2 ZIP Item Names . 37 10.2.3 Mapping Part Names to ZIP Item Names 38 10.2.4 Mapping ZIP Item Names to Part Names 38 10.2.5 ZIP Package Limitations . 38 10.2.6 Mapping Pa
5、rt Content Type 39 10.2.7 Mapping the Growth Hint . 39 ECMA-376 Part 2 iv 10.2.8 Late Detection of ZIP Items Unfit for Streaming Consumption 40 10.2.9 ZIP Format Clarifications for Packages 40 11. Core Properties 41 11.1 Core Properties Part 42 11.2 Location of Core Properties Part . 44 11.3 Support
6、 for Versioning and Extensibility . 44 11.4 Schema Restrictions for Core Properties 44 12. Thumbnails 46 12.1 Thumbnail Parts. 46 13. Digital Signatures . 47 13.1 Choosing Content to Sign 47 13.2 Digital Signature Parts . 47 13.2.1 Digital Signature Origin Part 48 13.2.2 Digital Signature XML Signat
7、ure Part 48 13.2.3 Digital Signature Certificate Part . 49 13.2.4 Digital Signature Markup 49 13.3 Digital Signature Example 59 13.4 Generating Signatures . 61 13.5 Validating Signatures . 62 13.5.1 Signature Validation and Streaming Consumption . 63 13.6 Support for Versioning and Extensibility . 6
8、3 13.6.1 Using Relationship Types 63 13.6.2 Markup Compatibility Namespace for Package Digital Signatures . 63 Annex A. (normative) Resolving Unicode Strings to Part Names 65 A.1 Creating an IRI from a Unicode String . 65 A.2 Creating a URI from an IRI . 65 A.3 Resolving a Relative Reference to a Pa
9、rt Name 66 A.4 String Conversion Examples 66 Annex B. (normative) Pack URI . 67 B.1 Pack URI Scheme . 67 B.2 Resolving a Pack URI to a Resource . 69 B.3 Composing a Pack URI . 69 B.4 Equivalence . 70 Annex C. (normative) ZIP Appnote.txt Clarifications 71 C.1 Archive File Header Consistency . 71 C.2
10、Data Descriptor Signature . 71 C.3 Table Key . 71 Annex D. (normative) Schemas - W3C XML Schema 82 D.1 Content Types Stream . 82 D.2 Core Properties Part 83 D.3 Digital Signature XML Signature Markup 84 D.4 Relationships Part 85 Annex E. (informative) Schemas - RELAX NG . 86 Table of Contents v E.1
11、Content Types Stream . 86 E.2 Core Properties Part 87 E.3 Digital Signature XML Signature Markup 87 E.4 Relationships Part 88 E.5 Additional Resources . 89 E.5.1 XML 89 E.5.2 XML Digital Signature Core 89 Annex F. (normative) Standard Namespaces and Content Types 90 Annex G. (informative) Physical M
12、odel Design Considerations 92 G.1 Access Styles 93 G.1.1 Direct Access Consumption . 93 G.1.2 Streaming Consumption 93 G.1.3 Streaming Creation . 93 G.1.4 Simultaneous Creation and Consumption 93 G.2 Layout Styles 93 G.2.1 Simple Ordering. 93 G.2.2 Interleaved Ordering . 94 G.3 Communication Styles
13、. 94 G.3.1 Sequential Delivery . 94 G.3.2 Random Access 94 Annex H. (informative) Guidelines for Meeting Conformance 95 H.1 Package Model 95 H.2 Physical Packages 103 H.3 ZIP Physical Mapping . 108 H.4 Core Properties 112 H.5 Thumbnail 114 H.6 Digital Signatures . 114 H.7 Pack URI . 125 Annex I. (in
14、formative) Differences Between ECMA-376:2012 and ECMA-376:2006 . 127 I.1 XML Elements 127 I.2 XML Attributes. 127 I.3 XML Enumeration Values 127 I.4 XML Simple Types 127 Annex J. (informative) Index . 128 Foreword vii Foreword Changes from the 3rd edition were made to align this 4th edition Standard
15、 with ECMA-376:2012. Both this 4th edition and ISO/IEC 29500:2012 refer to the 1st edition. As such, this 4th edition does not cancel or replace the 1st edition. This 4th edition does, however, cancel and replace the 3rd edition. Some important differences between ECMA-376:2012 and ECMA-376:2006 are
16、 given in Annex I. ECMA-376 consists of the following parts: Part 1: Fundamentals and Markup Language Reference Part 2: Open Packaging Conventions Part 3: Markup Compatibility and Extensibility Part 4: Transitional Migration Features Annexes A, B, C, D, and F form a normative part of this Part of EC
17、MA-376. Annexes E, G, H, I, and J are for information only. This Part of ECMA-376 includes two annexes (Annex D and Annex E) that refer to data files provided in electronic form. The document representation formats defined by this Part are different from the formats defined in the corresponding Part
18、 of ECMA-376:2006. Some of the differences are reflected in schema changes, as shown in Annex I of this Part. ECMA-376 Part 2 viii Introduction ECMA-376 specifies a family of XML schemas, collectively called Office Open XML, which define the XML vocabularies for word-processing, spreadsheet, and pre
19、sentation 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,
20、 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. The following organizations have participated in the creation of ECMA-376 and their contributions are gratefully acknowledged: Apple
21、, Barclays Capital, BP, The British Library, Essilor, Intel, Microsoft, NextPage, Novell, Statoil, Toshiba, and the United States Library of Congress 1. Scope 1 1. Scope This Part of ECMA-376 specifies a set of conventions that are used by Office Open XML documents to define the structure and functi
22、onality 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
23、 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 ECMA-376. The phys
24、ical 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 ECMA-376 also describes certain features that might be supported in a package, including core properties for package metadata, a thumbnail for gra
25、phical representation of a package, and digital signatures of package contents. Because this Part of ECMA-376 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 com
26、patibility between software systems based on different versions of this Part of ECMA-376 while allowing package creators to make use of new or proprietary features. This Part of ECMA-376 specifies requirements for documents, producers, and consumers. Conformance requirements are identified throughou
27、t the text of this Part of ECMA-376. A formal conformance statement is given in 2. An informative summary of requirements relevant to particular classes of developers is given in Annex H. ECMA-376 Part 2 2 2. Conformance Each conformance requirement is given a unique ID comprised of a letter (M MAND
28、ATORY; S SHOULD; O OPTIONAL), an identifier for the topic to which it relates, and a unique ID within that topic. (Producers and consumers might use these IDs to report error conditions.) Mandatory requirements are those stated with the normative terms “shall,“ “shall not,“ or any of their normative
29、 equivalents. Should items are those stated with the normative terms “should,“ “should not,“ or any of their normative equivalents. Optional requirements are those stated with the normative terms “can,“ “cannot,“ “might,“ “might not,“ or any of their normative equivalents. Example: Package implement
30、ers shall not map logical item name(s) mapped to the Content Types stream in a ZIP archive to a part name. M3.11 end example Each Part of this multi-part standard has its own conformance clause, as appropriate. The term conformance class is used to disambiguate conformance within different Parts of
31、this multi-part standard. This Part of ECMA-376 has only one conformance class, OPC (that is, Open Packaging Conventions). A document is of conformance class OPC if it obeys all syntactic constraints specified in this Part of ECMA-376. OPC conformance is purely syntactic. 3. Normative References 3 3
32、. Normative References The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. American National Standard
33、s Institute, Coded Character Set 7-bit American Standard Code for Information Interchange, ANSI X3.4, 1986. ISO 8601, Data elements and interchange formats Information interchange Representation of dates and times. ISO/IEC 9594-8 | ITU-T Rec. X.509, Information technology Open Systems Interconnectio
34、n The Directory: Public-key and attribute certificate frameworks. ISO/IEC 10646, Information technology Universal Coded Character Set (UCS). ECMA-376-3, Information technology Document description and processing languages Office Open XML File Formats, Part 3: Markup Compatibility and Extensibility.
35、Dublin Core Element Set v1.1. http:/purl.org/dc/elements/1.1/ Dublin Core Terms Namespace. http:/purl.org/dc/terms/ Extensible Markup Language (XML) 1.0 (Third Edition), W3C Recommendation, 04 February 2004. Namespaces in XML 1.1, W3C Recommendation, 4 February 2004. RFC 2616 Hypertext Transfer Prot
36、ocol HTTP/1.1, The Internet Society, Berners-Lee, T., R. Fielding, H. Frystyk, J. Gettys, P. Leach, L. Masinter, and J. Mogul, 1999, http:/www.ietf.org/rfc/rfc2616.txt. RFC 3986 Uniform Resource Identifier (URI): Generic Syntax, The Internet Society, Berners-Lee, T., R. Fielding, and L. Masinter, 20
37、05, http:/www.ietf.org/rfc/rfc3986.txt. RFC 3987 Internationalized Resource Identifiers (IRIs), The Internet Society, Duerst, M. and M. Suignard, 2005, http:/www.ietf.org/rfc/rfc3987.txt. RFC 4234 Augmented BNF for Syntax Specifications: ABNF, The Internet Society, Crocker, D., (editor), 2005, http:
38、/www.ietf.org/rfc/rfc4234.txt. The Unicode Consortium. The Unicode Standard, http:/www.unicode.org/standard/standard.html. W3C NOTE 19980827, Date and Time Formats, Wicksteed, Charles, and Misha Wolf, 1997, http:/www.w3.org/TR/1998/NOTE-datetime-19980827. ECMA-376 Part 2 4 XML, Tim Bray, Jean Paoli,
39、 Eve Maler, C. M. Sperberg-McQueen, and Franois Yergeau (editors). Extensible Markup Language (XML) 1.0, Fourth Edition. World Wide Web Consortium. 2006. http:/www.w3.org/TR/2006/REC-xml-20060816/. Implementers should be aware that a further correction of the normative reference to XML to refer to t
40、he 5th Edition will be necessary when the related Reference Specifications to which this International Standard also makes normative reference and which also depend upon XML, such as XSLT, XML Namespaces and XML Base, are all aligned with the 5th Edition. XML Namespaces, Tim Bray, Dave Hollander, An
41、drew Layman, and Richard Tobin (editors). Namespaces in XML 1.0 (Third Edition), 8 December 2009. World Wide Web Consortium. http:/www.w3.org/TR/2009/REC-xml-names-20091208/ XML Base, W3C Recommendation, 27 June 2001. XML Path Language (XPath), Version 1.0, W3C Recommendation, 16 November 1999. XML
42、Schema Part 1: Structures, W3C Recommendation, 28 October 2004. XML Schema Part 2: Datatypes, W3C Recommendation, 28 October 2004. XML-Signature Syntax and Processing, W3C Recommendation, 12 February 2002. .ZIP File Format Specification from PKWARE, Inc., version 6.2.0 (2004), as specified in http:/
43、 Note: The supported compression algorithm is inferred from tables C-3 and C-4 in Annex C. end note 4. Terms and Definitions 5 4. Terms and Definitions For the purposes of this document, the following terms and definitions apply. Other terms are defined where they appear in italic typeface. Terms ex
44、plicitly defined in this Part of ECMA-376 are not to be presumed to refer implicitly to similar terms defined elsewhere. The terms base URI and relative reference are used in accordance with RFC 3986. access style The style in which local access or networked access is conducted. The access styles ar
45、e as follows: streaming creation, streaming consumption, simultaneous creation and consumption, and direct access consumption. behavior External appearance or action. behavior, implementation-defined Unspecified behavior where each implementation shall document that behavior, thereby promoting predi
46、ctability and reproducibility within any given implementation. (This term is sometimes called “application-defined behavior”.) behavior, unspecified Behavior where this Open Packaging specification imposes no requirements. byte A sequence of 8 bits treated as a unit. communication style The style in
47、 which package contents are delivered by a producer or received by a consumer. Communication styles include random access and sequential delivery. consumer Software or a device that reads packages through a package implementer. A consumer is often designed to consume packages only for a specific phy
48、sical package format. content type Describes the content stored in a part. Content types define a media type, a subtype, and an optional set of parameters, as defined in RFC 2616. Content Types stream A specially-named stream that defines mappings from part names to content types. The content types
49、stream is not itself a part, and is not URI addressable. device Hardware, such as a personal computer, printer, or scanner, that performs a single function or set of functions. format consumer A consumer that consumes packages conforming to a format designers specification. format designer The author of a particular file format specification built on this Open Packaging Conventions specification. format producer A producer that produces packages conforming to a for
