1 2 (3) 4 5 (6) (7)
MB1 
Clause No./ 
Subclause No./ 
Annex 
(e.g. 3.1)
Paragraph/ 
Figure/Table/Note 
(e.g. Table 1)
Type of com-ment2 Comment (justification for change) by the MB Proposed change by the MB Secretariat observations 
on each comment submitted

CA-01     GE Canada Disapproves 29500 for the reasons contained in the comments given below and will consider changing its position if the Canadian comments are addressed. 

Further, Canada makes the following recommendations:

1.Convert this standard to a multi part standard, which would  mean the reversion of DIS 29500 to an acceptable level of review within the ISO/IEC JTC 1 development process,

2.If a revision is undertaken, address harmonization, insofar as possible, with other ISO/IEC standards, or where ISO/IEC standards do not exist other referencable specifications.

   
CA-02 Part 0 Office Open XML Overview Major Editorial This document is not listed as part of the ECMA 376 standard in the Forward to Part I “Fundamentals” and its status whether informative or normative is not explicitly stated.

If this paper is merely a promotional whitepaper about Ecma 376, then it cannot be included in the published standard. .

If this is meant to be an introduction as per ISO directives, it should so incorporated so as to provide a seamless integration with the main document.  
CA-03 Part 0 Throughout ED The name "Office Open XML" is often mistakenly called 'Open Office XML” implying a connection to the OpenOffice project which does not exist. This naming confusion has been documented and has occurred numerous times, including by analysts and even in Microsoft press releases and blogs. Since “Open Office” is the pre-existing name, by 6 years, Ecma should choose a new name, less apt to continue this confusion. Change the name of Office Open XML to a name which is not easily confused with OpenOffice.  
CA-04 Part 1, Appendix   ED The reference given for the Zip format does not provide a date or version, though this specification is frequently revised, Reference should be made to a particular dated and labelled version.  
CA-05 Part 1, Section 02.04 Line 22 ED This line requires conformance with “Unicode Standard” without specifying a version.   XML 1.0 referred to Unicode 2.0, though the informative Appendix A of OOXML Part 1 lists Unicode 4.0. 

Specify which is it?

The second bullet of the document conformance clause should read:

"The document character set shall conform to the XML 1.0 standard, with either the UTF-8 or UTF-16 encoding form."

 
CA-06 Part 1, Section 09.01.01   ED ASCII requires a normative reference since there are several national variations. It is greatly beneficial to all concerned to specify precisely the reference and version, which is standard procedure in ISO  
CA-07 Part 1, Section 09.01.05   ED This sub-clause, buried in introductory material, negates a provision of the more detailed OPC specification in Part 2.

It is not reasonable to expect that someone reading the packing conventions in Part 2 of a 6,000 page standard will know or remember that hundreds of pages earlier, in Part 1, they were told not to implement that feature.

Consider adding a reference to the restrictions described in Part 1 in either of the following locations:
  • In the Scope clause, after line 4, by referencing the parts of Part 2 which have restrictions defined in Part 1.
  • In Section 9.1.4 (and other sections directly affected), with the same back-reference.
 
CA-08 Part 1, Section 10.01.02   ED Incorrect Part number was given.  The comment should read:  "Reference is made to material in Part 5, Clause 12. Although a clause of that number does exist, it does not contain the material 10.1.2 references it for." The reference should be made to Part 5, Clause 11 " Application-defined Extensions Elements".  
CA-09 Part 1, Section 12.03.05   TE This binary part is said to be used for the storage of “arbitrary user-defined data”. No further detail is given as to what user action would trigger the use of this “user-defined” data. Without further definition, no interoperability of this feature is possible. Fully define the use of Custom Property Part  
CA-10 Part 1, Section 15.02.06 N/A ED What is meant by “This part shall have no contents”? Does this mean that there shall be nothing in the Zip file with the declared name?  Or does it mean that a zero-byte file shall be created with the declared name? Or something else? Change: "This part shall have no contents" to read "This part shall be a zero-byte file."  
CA-11 Part 1, Section 15.02.12  
 
 
  ED 
 
 
 
 

TE 
 

TE

There is no reference made to a particular dated version of TrueType or OpenType specifications. 
 
 
 
 
 
 
 

If TrueType and OpenType differ, then there should be different ways to refer to them, rather than calling them both “application/x-font-ttf” 
 

There is no reference made to a particular dated version of TrueType or OpenType specifications.

Canada recommends that the references for OpenType and TrueType might be drawn from the following: 

http://www.microsoft.com/typography/specs/default.htm 

Or

http://www.adobe.com/type/opentype/ 

Perhaps a note that will draw attention to it may be sufficient.

 
CA-12 Part 3, Section 08.03.04.01.01   ED The graphic provided in the example is almost impossible to read. Make an easy to read example (perhaps lighter background color).  
CA-13 Part 4 Throughout TE There are 263 uses of invalid xsd:boolean attribute values: For example, take part 4, 3.10.1.90 "sharedItems. In the definition of the attributes containsBlank, containsDate, it says: 
 
"Specifies a boolean value that indicates whether this field contains a blank value.  A value of on, 1, or true indicates this field contains one or more blank values.  A value of off, 0, or false indicates this field does not contain blank values.  The possible values for this attribute are defined by the XML Schema boolean datatype." 
 
However, XML Schema 3.2.2.1  (http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#boolean) defines allowed lexical value space for xsd:boolean as: 
"An instance of a datatype that is defined as boolean can have the following legal literals {true, false, 1, 0}  ""On" and "Off" are not allowed values. 
 
A search of Part 4 indicates 262 other instances of this problem, all in SpreadsheetML and DrawingML.
This could be fixed by amending the text to remove the "on" and "off" options or by changing the schema to refer to the ST_OnOff type defined in 2.18.67, which does allow this set of values. 

Caution may be warranted for a cascading effect to a change.

 
CA-14 Part 4

Section 03.04

lines 12-17 TE Lines 12-13 appear to contradict lines 14-16. The former indicates that formatting is (always) stored in the shared string table, while the latter indicates that when a cell has a single format, only the string itself is stored in the shared string table. 
 
Furthermore, if this contradiction is resolved such that the formatting is sometimes in the shared string table and other times in the styles part of a cell, then this becomes an accessibility issue: developers of assistive technology that must change formatting will have a difficult time dealing with this.
Add the following text: 

“The shared string table can contain all the necessary information for displaying the string: the text, formatting properties, and phonetic properties (for East Asian languages).  For exceptions to this rule see below."

 
CA-15 Part 4 page vii, line 8 Introduction ED An XML markup cannot be “fully compatible” with an “investment” Change second paragraph of intro to: "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.  
CA-16 Part 4, Section 02.03..03.19   TE This says that “The layout properties of this embedded object are specified using the VML syntax”.  However, in Part 1, Section 8.2.6 says, “VML should be considered a deprecated format included in Office Open XML for legacy reasons only and new 
9 applications that need a file format for drawings are strongly encouraged to use preferentially DrawingML”   Certainly a new document creating an OLE embedding should not be using VML.  Otherwise, all OOXML consumers will need to support VML, even where legacy documents are not present.
Provide full normative definitions for these graphical elements.  
CA-17 Part 4, Section 02.15.01.28 pg 1159, lines 6-9 TE The described processing steps are written with respect to a pseudo-language that performs bit-level operations on the data.  If this pseudo-language is to give the same answer on different machine architectures, then the assumptions regarding the runtime interpretation of this pseudo language must be make explicit. Describe the hash algorithm in a platform independent manner.  In particular define the assumptions being made on "word" size and sign and the sign and size of characters.  Also, clarify the semantics of SHR and SLR, especially in the presence of negative values.  If the algorithm allows them to be applied to negative values, are there further assumptions made about the representation of negative numbers, e.g., two complement representation  
CA-18 Part 4, Section 02.15.01.28   TE This says that document protection “shall be enforced.  “Shall” indicates required behaviour.  But then a few sentences later it says that document protection “may be ignored.” The last 4 word of Line 11 should be deleted to avoid the confusion.  
CA-19 Part 4, Section 02.15.02.32   TE This feature has been defined in a way which ignores the existence of current browsers other than Internet Explorer.  What about Firefox, Safari, or Opera? None of these can be set as target browsers. 

This section requires that “all settings which are not compatible with the target web browser shall be disabled.  It does not appear to allow an application to produce standards-compliant output? 

Does it mean yes to PNG, but no to VML? Or yes to MathML and SVG? 

It does not appear that an application can specify this.

Remove all text specifying how browser detection should be performed.  
CA-20 Part 4, Section 02.15.03.06

Part 4, Section 02.15.03.26

Part 4, Section 02.15.03.31

Part 4, Section 02.15.03.32

Part 4  Section 02.15.03.41 

Part 4, Section 02.15.03.51 

Part 4, Section 02.15.03.54 

Part 4,  Section 02.15.03.63 

Part 4, Section 02.15.03.64 

Part 4, Section 02.15.03.66

  TE Therre are about ten elements that are defined in terms of mimicking a legacy application's behavior. 
  • shapeLayoutLikeWW8” element
  • autoSpaceLikeWord95
  • wpSpaceWidth
  • footnoteLayoutLikeWW8
  • mwSmallCaps
  • suppressTopSpacingWP
  • truncateFontHeightsLikeWP6
  • useWord2002TableStyleRules
  • wpJustification
  • lineWrapLikeWord6
 

There is a lack of sufficient detail as to how replicate this behavior.

Define the intended behavior.  
CA-21 Part 4, Section 02.16.01   ED The production rule for field-switch-character is defined as:  field-switch-character: -one or two Latin letters” 
 
However, “Latin letters” is not defined in this specification.
 

Is this to be taken literally as only allowing the letters used in Latin, i.e., capital letters A-Z excluding J, U and W?

Or

Is it meant to be the ISO 8859-1, the Latin-1 character set? 

Or

Is it meant to be something quite different?

Provide a precise definition for this production rule  
CA-22 Part 4, Section 02.16.05.33   TE This sub-clause defines an INCLUDEPICTURE field which “Retrieves the picture contained in the document named”.  However, no mention is made of what formats are permissible for the picture. Provide a set of recommended interoperable formats, by pointing to the set defined in Part 1, Section 15.2.3 or by repeating it directly at this juncture of the text.  
CA-23 Part 4, Section 02.16.05.33   ED This does not define how a picture is named. Is it by a URI? By a local file system path? Either? The example given has a DOS file path, a construct which is not portable. 

This holds as well with documents.

Define how pictures are named by field-argument.  If URIs are permitted then RFC 3896 should be referenced:

http://tools.ietf.org/html/rfc3986

 
CA-24 Part 4, Section 02.16.05.34   TE This subclause defines an INCLUDETEXT field which “Inserts all or part of the text and graphics contained in the document named”. However, no mention is made of what formats are permissible for the retrieved text. Provide a recommended set of text formats, either by referencing the set included in Part 1, Section 11.3.1 or providing it inline (copied below):

[Note: Some examples of formats which might be supported include:

    ·         Text = application/txt

    ·         RTF = application/rtf

    ·         HTML = application/html

    ·         XML = application/xml

end note]

 
CA-25 Part 4, Section 02.16.05.34   ED The \t flag will apply a named XSLT transform to the input XML file and insert the resulting output. However, no proper reference is given to XSLT, so we do not know what version XSLT transform is permitted here. Canada recommends that this section should refer to either:

XSLT 1.0:

http://www.w3.org/TR/2001/REC-xsl-20011015/

or

XSLT 2.0

http://www.w3.org/TR/2007/REC-xslt20-20070123/ 

 
CA-26 Part 4, Section 02.16.05.41   ED This describes a “MACROBUTTON” field which can run a designated macro or command. But there is no mention of what programming language or API's are allowed for such a designated macro or command. If this is to be “implementer defined,” the text should so indicate in a clear and unambiguous way.  
CA-27 Part 4, Section 02.18.04 
 
 

Part 4, Section 03.07.44 
 

Part 4, Section 03.07.46

  TE The artwork provided here is of poor quality providing neither intended scale, spacing, color depth, etc. A small example diagram is an insufficient definition.   For example, are the dimensions of the borders absolute?  Or do they scale with page size? 
 
 

Some of the images, such as 'apples' or 'balloons3Colors' show copying artefacts, where extraneous lines or blotches appear. 
 
 
 

Although this observation was raised in only three places mentioned at left, it may exist elsewhere in the document.

It is strongly suggested that the images be of better quality clipart.  In so doing, it is helpful that normative definitions for these graphical elements are provided. 
 
 
 

In addition, for informative purposes, these graphics may be provided in standalone file form, preferably in a scalable graphics format like SVG images to define the page borders.

 
CA-28 Part 4, Section 02.18.04   ED No mechanism for expanding the set of art borders is provided.

Since the specified art borders are heavily Western-oriented, it would be good to provide a way for an application to supplement these styles with graphics that provide more regional flavour.

Provide an interoperable extensibility mechanism for a document author or application to specify their own art border graphics.  
CA-29 Part 4, Section 02.18.45   TE Length is said to be “exactly 3 characters”. This is inconsistent with the example given which has a length of 6 characters. Please correct or explain the inconsistency.

In particular note that xsd:hexBinary measure s length in octets, not characters

 
CA-30 Part 4, Section 02.18.51   TE There does not seem to be any language encoded by ST_LangCode that is not also encoded by ISO 639-1.  So no purpose is served by having both.  In fact, it burdens implementers with supporting both with no increase in expressivity. Drop the use of the redundant ST_LangCode  
CA-31 Part 4, Section 02.18.66 
 
 
 
 
 
 
 
 
“Chicago 
 
 
 

Counting systems

TE 
 
 

ED 
 
 
 

ED

The formatting system described here is not comprehensive, lacking, for example, support for Armenian, Tamil, Greek alphabetic, Ethiopic and Khmer numerations, all in use today, as well as the various historical systems still used by scholars. 

Format is defined in reference to the “Chicago Manual of Style”, but no edition or page reference is provided 
 
 

Several counting systems are defined to use letters of the alphabet, but nothing is mentioned about how counting continues once the letters of the alphabet are exhausted.

Use a more flexible, extensible, generative approach to numeration, such as that used by the W3C's XSLT standard in their xsl:number support 
 
 

Either include the entire definition in the standard, or provide a proper external reference including the edition number as a normative reference. 

For example: “The Chicago Manual of Style, 15th ed., 2003.” 
 

It would helpful to clarify the text to explicitly cover this case.

 
CA-32 Part 4, Section 02.18.66   TE There is nothing in this section which is normatively defined except some enumeration values.  No normative meanings to these values are given.  An informative example is insufficient in all but the most trivial cases.  For example, where is “Korean Legal Counting System” defined? Give explicit definitions of these numbering styles or proper external normative references.  
CA-33 Part 4, Section 02.18.66 decimalFullwidth TE There are several mentions of double-byte and single-byte Arabic numbering schemes.  Since the conformance clause for OOXML requires the use of Unicode in UTF8 or ITF16 encodings, there should be no mention of other encodings. Clarify the use of the terms "single byte" and "double byte" in the context of width specifications.  It is unclear the relationship between SBCS, DBCS and single width and double width terminology.  
CA-34 Part 4, Section 02.18.66 numberInDash TE Format requires use of “dash” to surround the number, but no indication of which Unicode dash is intended, en-dash, em-dash, hyphen-minus, figure-dash, quotation-dash, etc. Specify the intended dash explicitly.  
CA-35 Part 4, Section 02.18.72 

Part 4, Section 05.01.12.37

  ED No definition is provided for a “Panose-1 classification” of a font. 
 
 

What is the rationale for several different definitions for a Panose value, both in Word Processing ML as well as Drawing ML? 

Provide an external normative reference for this term. 
 
 

Since they are exactly the same they should be defined once in a shared schema

 
CA-36 Part 4, Section 02.18.85   TE The fill patterns lack definitions.  The illustrations given are insufficient.

An application needs to know what in these illustrations are required behaviors and what are not. 

For example, is the exact dithering pattern used in the illustration required?

Define layout properties of embedded objects using DrawingML rather than VML  
CA-37 Part 4, Section 03.02.29 
 

Part 4, Section 03.03.01.69

  TE A hash algorithm is provided, likely based on a legacy algorithm used in Excel. This legacy algorithm is known to be a weak algorithm and has effectively been cracked. One could argue that no hash algorithm would be effective in OOXML, since a user could simply unzip the document and hand edit the XML to remove the hash or to set it to some known value. However, some application types such as online editing via Google Docs, or other similar applications, can secure physical access to the document via other means. Editing access to the document does not necessarily presuppose physical access to the document's XML. So there is a necessity for a secure & interoperable hash algorithm, such as SHA-256 for document protection. 

As described the algorithm is technically flawed.   It is not ambiguous.  It is not poorly worded.  It does not have a spelling or grammatical error.  It is simply flawed.

The use of existing standardized hash algorithms as found in ISO/IEC 10118 part 3 is recommended if extract security is required or even desired. 

The default should be set to SHA-256.

 
CA-38 Part 4, Section 03.02.29 pg. 1916 TE This seems to imply that if a password is entered in a script like Armenian or Ethiopic then the characters will be replaced all by a single character 0x3F, making the protection feature useless. This is unacceptable 

The conversion from input password to single byte string is ambiguous. Certainly the input password could contain characters from more than one script, say some Korean, some Chinese. Do we process via multiple DBCS code pages? Or just one and then replace the unmapped characters with 0x3F? If only one DBCS code page is used, how is that determined in this case?

Canada requests that a statement be inserted within this text area which would explicitly clarify the restriction especially with the use of passwords.  
CA-39 Part 4, Section 03.02.29 pp. 1917-1922 ED No normative description of the password hashing algorithm is provided, so interoperability of this feature cannot be assumed.  In an informative section, 5-pages of C-language source code is provided as “an example”, and  this appears to involve machine-dependent bit manipulations. Provide a normative, cross-platform definition of the hashing algorithm.  Cross-platform source code can be given as an example, but the normative text should be in English, not in a programming language.  
CA-40 Part 4, Section 03.03.01.61   TE The pageSize attribute allows a set of enumerated values which does not encompass all of the page size values permitted by ISO 216, ANSI Y14.1 and similar DIN and JIS standards. Rather than trying to maintain a paper size registry, a more flexible approach would be to simply record the dimensions of the paper size selected. 

Canada requests that the use of the appropriate ISO standard (ISO-216) sizes be supported. 

As an extension there is also a need to allow for specifying user defined paper sizes.

 
CA-41 Part 4, Section 03.03.01.69   TE The securityDescriptor attribute, “defines 
user accounts who may edit this range without providing a password to access the range”.  It is a string.  But no information is given as to what user accounts are referred to here, or what the delimiter is.  Are these comma-delimited local machine user accounts?  Or semi-colon delimited LDAP DN's?  There will be no interoperability if this is not defined.
Fully define this attribute. 

It would most beneficial if the text would describe how multiple user accounts in a security descriptor are encoded.

 
CA-42 Part 4, Section 03.17.02   ED This clause has two references to a nonexistent section ('§0'). Fix the reference and ensure that no cascading effect takes place

Suggest the reference to be: 3.17.2.2

 
CA-43 Part 4, Section 03.17.02.01   TE The syntax of constants is defined using an unspecified notation, which appears to borrow some characteristics of Backus-Naur Form for grammar productions, some notations from popular ways of specifying command line applications options, etc., all without formally defining the notation used.

Note that other parts of the syntax for formulas similarly lack a proper format definition. The reference to the “constants” section is one example.

Either adopt a formal lexical-syntactic notation by reference (for example ISO 14977:1996 EBNF), or explicitly define your own.  
CA-44 Part 4, Section 03.17.04.01   TE The mandated incorrect date calculations for 1900 in the 1900-based date basis is unacceptable.  An ISO standard should not be mandating incorrect values for the well-established Gregorian Calendar.  To do so will only lead to confusion, poor interoperability and  perpetuation of errors. If needed for legacy reasons with legacy spreadsheet documents, then introduce an additional attribute tag such as “treat1900AsLeapYear” or similar.  This is the approach recommended elsewhere in OOXML for legacy features.  
CA-45 Part 4, Section 03.17.04.01 page 2522, lines 16&18 ED The documented upper limits for serial date times match 9999-12-31 00:00:00, which is most probably not what was intended.  The expected upper limits would match 9999-12-31 23:59:59. Validate the upper limits.  
CA-46 Part 4, Section 03.17.04.01 page 2522, lines 14-18 TE The text proposes a dual date base system. There is no clear advantage to having two slightly different systems, and this brings significant costs and confusion, as illustrated by the need to specify a default base system, etc. Allow the use of an ISO date format and include a flag such that applications would know if date based calculations are done in a special way.

One could use ISO date format and include a flag such that applications would know if they need to treat date based calculations in a peculiar way.

 
CA-47 Part 4, Section 03.17.07 Throughout TE There appears to be a production issue in the creation of the PDF version of this DIS.  Many of the mathematical formulas that define the spreadsheet functions are illegible, and all of them are of low quality. For example, 3.17.7.24, 3.17.7.32, 3.17.7.38, etc. 

For example:

3.17.7.32 BINOMDIST on page 2558.  What power is (1-p) raised to 

3.17.7.38 CHITEST on page 2565, what is the subscript on A

3.17..7.233 NEGBINOMDIST on page 2721, what is p' ? p-rime?  a first derivitive of p?  or a degenerate p^r?

Provide higher resolution of the mathematical equations.  
CA-48 Part 4, Section 03.17.07.12 ASIN ED It is not indicated whether the argument shall be in radians or degrees.  This same omission is evident in the definition of ACOS, ATAN, SIN, COS, TAN and TAN2 functions. Specify the angular units to be in radians as reflected in the example.  
CA-49 Part 4, Section 03.17.07.243 OR TE It is not specified whether this function short-circuits or not. In other words, must the remaining arguments be evaluated once one of them is found to be TRUE? Since some functions have side effects, it is necessary to define this in order to ensure interoperability. 

The same ambiguity applies to the AND function.

Specify if this function allows short-circuit evaluation.  
CA-50 Part 4, Section 03.17.07.249   ED The provided example contradicts the description, since it displays 10 significant digits in its fractional part instead of the (minimum) 15 significant digits which is stated as a requirement. Fix the example or the text, so this contradiction is 
resolved
 
CA-51 Part 4, Section 03.17.07.348 YEARFRAC TE This function is ambiguous. Specifically it does not treat the calculation in the presence of leap years. In the Actual/Actual basis, do we ever divide by 366? Or only by 365? Would we divide by 366 only if the leap day is between start-date and end-date? Of either start-date or end-date are in the leap year? If both start-date and end-date are in a leap year? Clarify the definition of the function when involving leap years.  
CA-52 Part 4, Section 03.17.07.49 CORREL TE The definition of the arguments in the function is incorrect. It should say that x-bar and y-bar are the sample means, not x and y. 
 
This error also occurs in many of the other statistical functions, including:  PEARSON, RSQ, SLOPE,STDEV,STDEVA,STDEVP,STDEVPA,STEYX,VAR,VARA and VARP 
Change the text of each of these clauses so it matches the notation of the equation given.  In most cases this will be a change from "where x is the sample mean" to "where x-bar is the sample mean."  
CA-53 Part 4, Section 03.17.07.65 CUBEKPIMEMBER TE The “kpi-property” parameter lists a number of values which are undefined such as “temporal context”, “relative importance”, etc. This is made even more cryptic by the fact that this function, unlike almost all the others, has examples that fail to illustrate the returned values. If there is to interoperability in the use of this function, semantics in additional to syntax will need to be specified. Provide the semantics for this function, as well as, provide some examples.  
CA-54 Part 4, Section 03.17.07.76 DATEVALUE TE This function says that it can take a string in any valid date and/or time format. It further says that if the year portion of the input string is omitted, that the current year is used. But what if the date is omitted as well, e.g.,, someone passes in a pure time string like “10:34”? Is it to be assumed as current date? Or assume January 1st of the current year? Describe the boundary conditions for when only the time format is specified.  
CA-55 Part 4, Section 03.17.07.91 DISC TE The function is defined in terms of $100 face value, but there is nothing about the security discounting that is intrinsically tied to the US Dollar Recommend the use of the generic currency sign here (U+00A4)  
CA-56 Part 4, Section 03.18.95   ED All of the URL’s provided here are incorrect.  They lack the colon following “http”. Correct the URL’s as provided below.

[1] http://www.w3.org/TR/2004/REC-webarch-20041215/

[2] http://www.w3.org/Provider/Style/URI.html

 
CA-57 Part 4, Section 05.01.03.04   ED This describes the attachment of a QuickTime video to a presentation object.  No description of the QuickTime format is provided.  Without specifying a version and supported codecs, there will be no interoperability. Provide an external reference for the version(s) of QuickTime format intended here as well as an interoperable codec. 

http://developer.apple.com/reference/QuickTime/

 
CA-58 Part 4, Section 05.01.12.28   ED This type is used in only two places, 5.1.2.2.32 and 5.1.2.2.33, in both cases to represent an RGB color value. Recommend the use of the already defined  ST_HexColorRGB type, and remove ST_HexBinary3  
CA-59 Part 4, Section 06.01.02.19   TE This section describes the "equationxml" attribute of "shape" elements, "used to rehydrate an equation using the Office Open XML Math syntax". However, the "actual format of the contents of this attribute are application-defined", which makes them impossible to exchange between applications.

If it is the intent to have a new math markup language in XML, and ignore the existing MathML, then at least use the new markup in its elemental form, as well-formed XML (not stuffed into an attribute value), and without extending it in application-dependent ways.

Change the following text:

"Specifies alternate XML markup which may be used to rehydrate an equation using the Office Open XML Math syntax. The actual format of the contents of this attribute are application-defined, but shall contain Office Open XML Math as well as any applicationspecific content.

The XML markup stored in this attribute shall be escaped as needed to contain only those characters legal in an attribute value.

The possible values for this attribute are defined by the XML Schema string datatype."

to the following:

"Specifies optional application-defined XML markup which may be used to store an equation.

The XML markup stored in this attribute shall be escaped as needed to contain only those characters legal in an attribute value.

The possible values for this attribute are defined by the XML Schema string datatype.

Note: The actual format of the contents of this attribute may contain Office Open XML Math as well as any application specific content."

 
CA-60 Part 4, Section 06.04.02.04 AutoFill TE The text says, “This element specifies that the object is an AutoFill object. If this element is specified without a value, it is assumed to be true. This is a general-use element.” However, nowhere in the spec is an “AutoFill object” defined. Define the behaviour of an “AutoFill 
object
 
CA-61 Part 4, Section 06.04.02.05 AutoLine TE The text states: “This element specifies that the object is an AutoLine object. If this element is specified without a value, it is assumed to be true. This is a general-use element.”   However, nowhere in the spec is an “AutoLine object” defined. Define the behaviour of an “AutoLine” object  
CA-62 Part 4, Section 06.04.02.08   TE This element specifies that the object is a camera object. A camera object shows a live view of another part of the spreadsheet. If this element is specified without a value, it is assumed to be true. This element is used for cameras."  However, a “camera” is not defined in this context, nor its behaviour. Define a "camera object" in this context.  
CA-63 Part 4, Section 06.04.02.10   ED This element is defined as providing a, “general-use element for objects  that use an image representation, such as OLE objects, embedded controls, cameras and signature lines.”  However, the allowed values, EMF, WMF, etc., refer to formats for which no reference has been given. Provide a proper external normative reference for the allowed formats containable within this element.  
CA-64 Part 4, Section 07.04.02.04   ED The presence of non-XML characters, escaped, or not escaped in an OOXML document, is contrary to interoperability of XML and XML-based tools.  The W3C's Internationalization Activity confirms this interpretation, saying  Control codes should be replaced with CA-appropriate markup.  Since XML provides a standard way of encoding structured data, representing control codes other than as markup would undo the actual advantages of using XML.  Use of control codes in HTML and XHTML is never appropriate, since these markup languages are for representing text, not data.” Change the following text:

For all characters that cannot be represented in XML as defined by the XML 1.0 specification, the characters are escaped using the Unicode numerical character representation escape character format _xHHHH_, where H represents a hexadecimal character in the character's value.

to the following (adding the word UNICODE near the beginning of the sentence):

"For all UNICODE characters that cannot be represented in XML as defined by the XML 1.0 specification, the characters are escaped using the Unicode numerical character representation escape character format _xHHHH_, where H represents a hexadecimal character in the character's value."

In addition this Section should make it clear that valid XML 1.0 UNICODE characters are permitted in the bstr value and not just UNICODE characters that cannot be represented.

 
CA-65 Part 4, Section 07.04.02.04   TE This defines a new XML string type which allows the inclusion via an escape mechanism of Unicode characters which are otherwise impermissible in XML documents.  However, any escape mechanism must also specify a mechanism for “escaping the escape”.  So, how does one represent the literal example given in 7.4.2.4 in a bstr? Complete the definition of the escape mechanism  
CA-66 Part 4, Section 07.04.02.05   ED This section should clarify:

a) the string encoding for the null-terminated case

b) how long and GUID values are base64-binary encoded including byte ordering considerations

c) the use of this data type with one or more examples

d) the positive value case since it is unclear reading the text that this actually represents the length of the string and not the string itself

e) That the string encoding value can be used for clipboard formats for other platforms.

The content of this section is hard to understand and too terse.  
CA-67 Part 4, Section 07.04.02.05 Refers to line 10, row corresponding to Format Value -1 TE The value of -3 specifies a GUID that contains a format identifier (FMTID).  The required format for neither a GUID nor a FMTID is specified. Request that GUID to be defined so interoperability may be achieved.  
CA-68 Part 4, Section 07.04.02.05   TE Even within a single platform, there is not enough information given to achieve interoperability.  For example, what are the allowed values and meanings for a “built-in Windows clipboard format value”? Define Clipboard Format values  
CA-69 Part 4, Section 2.16.17 page 1585 TE The standard does not provide the function of labelling an actionable form element. There is also no explicit relationship between a label and its associated form field (textInput - 2.16.33, checkBox - 2.16.7, and ddList - 2.16.7). Where a label is a human readable text string identifying the choice to be made or the text to be filled into the text field that is accessible to a screen reader. This functionality is different from a name. Provide the functionality of a label for actionable form elements and provide a way to explicitly link labels to their text fields.  
CA-70 Part 4, Section 3.17.7.17   ED The example given is incorrect. It is a formula for calculating the number of combinations of n things taken k at a time. This does not concern absolute deviation. Perhaps the formula below may be beneficial to be included: 
 
 
CA-71 Part 4, Section 3.17.7.341   TE As written this function mandates an incorrect calculation for day of week for certain dates in the year 1900.  An ISO standard should not be mandating incorrect values for the well-established Gregorian Calendar.  To do so will only lead to confusion, poor interoperability and  perpetuation of errors. If needed for legacy reasons with legacy spreadsheet documents, then introduce an additional attribute tag such as  treat1900AsLeapYear  or similar.  This is the approach recommended elsewhere in OOXML for legacy features.  
CA-72 Part 4, Section 4.4.1.35 Page 3044 TE There is no way to explicitly specify the navigation order among elements on a presentation slide. Provide a specific mechanism for defining the ordering of objects on a slide - for example, considers amending the “id” attribute on the cNvPr element (page 3022) to specifically state that it shall be used for this purpose.  
CA-73 Part 4, Section 5.5.2.5 Page 3909 TE It is not clear how DIS 29500 can be used to create an image map. One possible method is to compose a set of separate images each with their own linked region and label/descriptive text.  If this technique is used, how is a label/descriptive text applied to the composite set of images? Provide consistent instructions in how to create an image map. Provide the function of specifying Alternative text descriptions for all linked regions of an image map including the overall image map.  
CA-74 Part 4, Section 6.4.3.1   TE The allowed values of this enumeration, EMF, WMF, etc., are Windows-specific formats. No allowance seems to have been made for use by other operating systems. For example, in Linux images are typically copied on the clipboard in an open standard format like PNG. There are several approaches here to better support portability and cross-platform interoperability. For example: 
 
1) Define the ST_CF type as being a union of xsd:string and the existing enumeration. 
 
2) Augment the existing enumeration with a fuller list of clipboard formats, including those commonly used on non-Windows platforms. 
 
3) Define an additional attribute whose value can contain additional clipboard types.
 
CA-75   Throughout TE It is recommended that this standard interoperate with  accessibility-vetted approaches, such as XLinks, XForms and SMIL Provide  an “Informative” annex which would provide information on accessibility features and hooks in the development of assistive technologies. 

Canada recommends a full review of the standard for Accessibility for future versions of this standard.

 
CA-76 Part 4, Section 6. To go to the end TE All subsections of Section 6 describe deprecated only material, making Section 6 deprecated as a whole. A new standard should not contain deprecated parts. Change Section 6 to an “Informative” Annex or separate document.  
CA-77 Part 4, Section 7.1   TE This is the specification of Office Open Math Markup Language, a specialized XML vocabulary for the describing the layout of mathematical equations.  This solves the same problem as MathML, a long-established W3C standard and an ongoing activity in the W3C.  Since the equation editing feature of Word was entirely rewritten in Word 2007, there doesn't not seem to be the argument that an additional equation language must be introduced for the sake of legacy documents. A future version of the standard shall consider permitting the use of W3C MathML 2.0 Recommendation or the W3C MathML 3.0 specification (currently under development) as an alternative to Office Open Math Markup language (see Part 4 Section 7 and the oMathPara element).  
CA-78   Throughout GE An accessible standard must make it easy to create a compatible assistive technology (this is referred to as access-system friendliness). This requires a standard that is easy to follow, that is consistent (without a large number of exceptions), that uses other open standards wherever possible, that harmonizes with other standards in the domain, and that makes necessary semantics programmatically available to the assistive technology. It is not clear how this standard meets the above criteria. Provide  an “Informative” annex which would provide information on accessibility features and hooks in the development of assistive technologies. 

Canada recommends a full review of the standard for Accessibility for future versions of this standard.

 
CA-79 Part 4, Section 2.15.3. 1368 TE This comment is with respect to the ten legacy-application-mimicking elements defined in section 2.15.3 (shapeLayoutLikeWW8, autoSpaceLikeWord95, wpSpaceWidth, footnoteLayoutLikeWW8, mwSmallCaps, suppressTopSpacingWP, truncateFontHeightsLikeWP6, useWord2002TableStyleRules, wpJustification, lineWrapLikeWord6).

Not only is there not sufficient detail as to how to replicate this behaviour, but referring to this proprietary behaviour makes it difficult for developers to make compatible Assistive Technologies. By making these part of the standard (as opposed to application-specific extensions), this increases the necessary complexity of AT's for  
*all* applications when the elements only apply to specific applications.

Explicitly indicate that these functions are generic.  

image

MB = Member body (enter the ISO 3166 two-letter country code, e.g. CA for Canada; comments from the ISO/CS editing unit are identified by **)

2 Type of comment: ge = general te = technical  ed = editorial

NOTE Columns 1, 2, 4, 5 are compulsory.

page  of 27

ISO electronic balloting commenting template/version 2001-10


Top