Ecma 376 Response
From Grokdoc
1 Ecma/TC45/2007/006
2
3
4 –– Response Document ––
5
6 National Body Comments from
7 30-Day Review of the Fast Track Ballot for
8 ISO/IEC DIS 29500 (ECMA-376)
9 “Office Open XML File Formats”
10
11 Prepared by Ecma International
12 2007-02-28
Contents |
Introduction
1
2 On receipt of the National Body comments from the ISO/IEC JTC 1 Secretariat, Ecma International, using the
3 expertise of Ecma TC 45, reviewed those comments in detail. This response document is the result of that
4 review.
5 A number of NBs submitted comments that appear to be identical, equivalent, or closely related to each other.
6 These issues are discussed in detail in §2, “Responses to Common Issues”, and referred to from the subclauses
7 of §3, “Responses to NB Comments”, as appropriate.
8 Ecma found that comments submitted during this period were of various natures, including perceived
9 contradictions, comments of a technical nature (which, as such, are best handled during the 5-month ballot and
10 the subsequent Ballot Resolution Meeting), and general-purpose statements expressing concerns or support. In
11 any event, Ecma gave consideration to all comments, providing a response to each one.
12 For simplicity, throughout this document, the following abbreviations are used:
13 *Ecma — Ecma International
14 *JTC 1 — ISO/IEC JTC 1 or its Secretariat, as appropriate
15 *NB — National Body
16 *ODF — ISO/IEC 26300:2006 “Open Document Format for Office Applications (OpenDocument) v1.0”
17 *OpenXML — ISO/IEC DIS 29500 (ECMA-376) “Office Open XML File Formats”
18 This document contains many links to other places in the same document. As such, it is most effectively used in
19 electronic form.
2. Responses to Common Issues
2 A number of NBs submitted comments that appear to be identical, equivalent, or closely related to each other.
3 Those issues are discussed here in detail, and referenced in the subclauses of §3, “Responses to NB Comments”,
4 where they were raised by individual NBs. The common issues are:
5 • Overlap in Scope with ISO/IEC 26300:2006 (ODF) (§2.1), raised by 12 NBs.
6 • Intellectual Property Rights (IPR) (§2.2), raised by six NBs.
7 • ISO/IEC JTC 1 Directives – Definition of Contradiction (§2.3.1), raised by four NBs.
8 • ISO/IEC JTC 1 Directives – Length of Review Period (§2.3.2), raised by eight NBs.
9 • Missing Annexes (§2.4), raised by three NBs.
10 • Consistency with ISO 216 (paper sizes) (§2.5.1), raised by two NBs.
11 • Consistency with ISO 639 (language name codes) (§2.5.2), raised by seven NBs.
12 • Consistency with ISO 8601 (date/time representation) (§2.5.3), raised by nine NBs.
13 • Consistency with ISO 8879 (SGML) (§2.5.4), raised by one NB.
14 • Consistency with ISO/IEC 8632 (picture metafile) (§2.5.5), raised by eight NBs.
15 • Consistency with ISO/IEC 15445 (HTML) (§2.5.7), raised by two NBs.
16 • Undocumented Legacy Features (§2.6), raised by three NBs.
2.1 Overlap in Scope with ISO/IEC 26300:2006 (ODF)
18 Comment source: Australia, Canada, Denmark, France, Germany, Japan, Kenya, New Zealand, Norway,
19 Sweden, Singapore, and the United Kingdom.
20 The responses to comments raised on this topic are organized as follows:
21 Overlap in Scope of ISO/IEC standards is common and can serve a practical purpose (§2.1.1)
22 • OpenXML addresses distinct user requirements (§2.1.2)
23 • ODF and OpenXML are Structured to Meet Different User Requirements (§2.1.3)
24 • OpenXML and ODF can and do coexist (§2.1.4)
25 Each of these is discussed below.
2.1.1 Overlap of ISO/IEC Standards is Common and Can Serve a Practical Purpose
28 Based on experience, it is quite common to have ISO/IEC standards whose scopes overlap partially or
29 completely. Below are detailed studies of some cases in areas close to this OpenXML discussion. Overlap is
30 warranted when the standards address distinct user requirements and/or allow for diversity and evolution of the
31 technologies.
32 1. Document formats – ODF (ISO/IEC 26300:2006 [ODF]), HTML (ISO/IEC 15445:2003), PDF/A (ISO
33 19005-1:2005). All of these standards can represent office documents. For example, a simple report
1 could be prepared in a typical office editing environment using an XML-based format, published to the
2 web in HTML format, and archived as a business record in PDF/A format. Further, the typical office
3 editing environment might use OpenXML for a document whose functionality is consistent with an
4 existing corpus of documents or might use ODF when there is no requirement for full compatibility. All
5 of the formats noted above can exist in a document store as the user requires, without any conflict
6 between them. Tools exist to manipulate and index all these formats, and many tools can save
7 information in any of the named formats.
8 2. Vector graphic formats – CGM (ISO/IEC 8632:1999), SVG as included in ODF. From the 2003 W3C
9 Graphics Activity Statement, “It became apparent that there were two different markets for vector
10 graphics: In one, technical documentation for industry, there was no desire for restylable graphics or for
11 graduated fills, but precise specification of line and hatch styles and use of Computer Graphics Metafile
12 (CGM) was an important requirement. This market had already standardized on CGM, but lacked a
13 vendor-neutral and interoperable hyperlinking mechanism. To satisfy the needs of this market, which
14 covers the aerospace, defense, automotive and electronics industries, the WebCGM profile was
15 developed in collaboration with CGM Open. CGM is an ISO standard for vector graphics. The
16 WebCGM profile adds additional constraints to improve interoperability, defines how hyperlinking
17 works, and defines mechanisms for use in HTML. The other market, graphic design for advertising, clip
18 art, business presentations and general Web use, needs complex fills, restyling, image clipping and
19 manipulation, and re-usable components. For this market, use of CGM was regarded as less important
20 than good integration with XML and other W3C specifications. W3C therefore developed a new
21 standard format for vector graphics, Scalable Vector Graphics (SVG), written in XML and usable as an
22 XML namespace, that matches the needs of content providers and browser vendors alike. It is designed
23 to be stylable, and to work well across platforms, output resolutions, color spaces, and a range of
24 available bandwidths.”
25 3. Raster image formats – JPEG (ISO/IEC 10918-1:1994) and PNG (ISO/IEC 15948:2004). JPEG was
26 developed as a compressed format for continuous-tone natural images, such as photographs. Its lossy
27 compression can achieve high compression ratios with relatively moderate loss of quality on typical
28 photographic content. Its lossless compression mode is less efficient. PNG uses a different, lossless
29 compression method that is well suited for preserving sharp edges in images at a specific resolution, as
30 is typical in raster images of drawings and text, although its applicability is considerably broader. Both
31 JPEG and PNG have features, such as progressive rendering, that were designed for Web use. Both
32 JPEG and PNG are broadly supported in Web browsers. Beyond the context of delivery on the Web,
33 JPEG (ISO/IEC 10918-1:1994), JPEG2000 (ISO 15444:2000), and JPEG-LS (ISO/IEC 14495-1:1999)
34 coexist in the arena of continuous-tone color still images. Similarly, JBIG1 (ISO/IEC 11544:1994) and
35 JBIG2 (ISO/IEC 14492:2000) coexist in the arena for bi-level and multi-tone still images suitable for
36 scanned or computer generated text, drawings, half-tone images and palletized colored images (and the
37 combinations thereof). In other words, all the above standards are “tool box” type of standards, with a
38 large degree of overlapping functionalities. Yet they all exist and users choose the most appropriate
39 format based on the nature of the image content and the relative importance of factors such as efficient
40 compression, decoding performance, and fidelity to an original source.
41 4. Schema languages – RELAX NG (ISO/IEC 19757-2:2003), DTD as included in SGML (ISO
42 8879:1986). Both of these standards can specify how to define the names, structure, and content of the
43 elements and attributes of an XML document. Both standards are widely used, and provide different
44 options for validating content models. For example, a RELAX NG schema specifies a pattern for the
