Balloted document: ISO/IEC DIS 29500    Information technology -- Office Open XML file formats  
            Vote: Approve   
    1 2 3 4 5
DIS 
(ISO 29500)
No. Category Clause, Sub-clause Page Comment and rationale Proposed change
Part 1
CO 1 te Introduction xii(12) The second paragraph states that the format "is fully compatible with the large existing investments in Microsoft Office documents". Since the format for Microsoft documents is proprietary no such mapping is available, so this claim cannot be proven. Also  a standard cannot be compatible with an investment. The claim must be proven or removed.
CO 2 te Section 2.6 4(16) The requirements presented as necessary for interoperability only addresses a part of the problem. Apart of what is mentioned, it is also important to properly limit and define the use of extensions, as this will inevitably lead to problems of interoperability and portability, since documents using undocumented extensions will be valid OOXML documents, but will make the document unreadable by different applications than the one which created it. Enforce interoperability throughout the standard. A document-producing application must inform the user when extensions which will break interoperability and portability are used, to avoid misleading the user into thinking that particular document can be consumed by any other OOXML compliant application. The standard should mandate the use of some mechanism to mark the document as “extended”, e.g. a warning message or a different document extension. Sections which include non-portable extensions in Part 4 include: 2.3.3.17, 2.16.5.33, 2.16.5.34, 2.17.3, 3.2.7, 4.6.9, 4.6.68, 4.6.69, 4.6.70, 4.6.93, 5.1.3.2, 5.2.3.4, 5.1.3.6, 5.1.3.7, 6.1.2.19
CO 3 te Section 4 6(18) The definition given here for “behavior, implementation-defined” contradicts its use in the normative sections of the standard. Although it is defined as "promoting predictability and reproducibility within any given implementation", the actual use of this term in the standard always implies undefined and unreferenced propietary behiour which in fact makes predictability and reproducibility impossible. Adjust this definition to the actual contents of the standard, or better yet, revise the standard to make this this statement true by defining each particular "application specific" behavior (see further comments for section 4)
CO 4 te Section 9.1    According to this point (Constraints on Office Open XML's Use of OPC), OPC, Open Packaging Conventions, are more general than needed for the purpose of OOXML. This is due to bring confusion, and should be resolved Propose OPC as a separate standard.
CO 5 te Section 15.2.14 155(167) OOXML allows the inclusion of binary data for printer settings (DEVMODE), which presents a potential security risk. These configurations should be expressed with proper XML, and since they are platform specific, there should be proper definitions for each platform.
Part 3
CO 6 te Introduction xii(12) The second paragraph states that the format "is fully compatible with the large existing investments in Microsoft Office documents". Since the format for Microsoft documents is proprietary no such mapping is available, so this claim cannot be proven. Also  a standard cannot be compatible with an investment. The claim must be proven or removed.
CO 7 ed 2.3.1 4(16) Closing quotes missing in example Fix
CO 8 ed 2.4.1 4(16){36} The sentence “some require a designating specifying" makes no sense Fix
CO 9 ed 2.4.2 5(17){30} The word  “emphasized” must be in italics to agree with the example Fix
CO 10 ed 2.4.2 6(18){4} tag <w:rPr> should be</w:rPr> Fix
CO 11 ed 2.4.2 6(18){17} tag <w:rPr> should be</w:rPr> Fix
CO 12 ed 2.4.2 6(18){23} tag <w:rPr> should be</w:rPr> Fix
CO 13 ed 2.4.2 6(18){28} The sentence “the properties of only some the text” is not complete Fix
CO 14 ed 2.5.2 10(22){17} Closing quotes missing Fix
CO 15 ed 2.5.2 12(24){5} Use straight quotes instead of curly Fix
CO 16 ed 2.5.2 12(24){26} Use straight quotes instead of curly Fix
CO 17 ed 2.5.4 13(25){31} “World” should not be capitalized to agree with example Fix
CO 18 ed 2.5.4 14(26){13} the line is not valid XML Delete the line
CO 19 te 2.6.2 22(34){3} www.contoso.com points to the Microsoft Office website Use a neutral example
CO 20 te 2.6.2 22(34){13} www.contoso.com points to the Microsoft Office website Use a neutral example
CO 21 te 2.6.2 22(34){26} www.contoso.com points to the Microsoft Office website Use a neutral example
CO 22 ed 2.7.1 28(40){1} This listing appears identical in the previous page Remove the duplicate text
CO 23 ed 2.8.2 30(42){2} “heading 1” should “Heading 1” to agree with the text Fix
CO 24 ed 2.8.2 30(42){6} Element <w:style> has no child <w:priority>. Fix
CO 25 ed 2.8.2 30(42){22} The example is repeted Remove the duplicate text
CO 26 ed 2.8.5 34(46){30} The example is repeated on the same page Remove the duplicate text
CO 27 ed 2.8.6 36(48){17} Element <w:style> has no child <w:priority>. Fix
CO 28 ed 2.8.7 38(50){15} Element <w:style> has no child <w:priority>. Fix
CO 29 ed 2.8.11 42(54){26} Element <w:latentStyles> has no child <w:defPriority>. Fix
CO 30 ed 2.8.11 43(54){31-32} Element <w:style> has no child <w:priority>. Fix
CO 31 ed 2.8.11 45(54){35-36} Element <w:style> has no child <w:priority>. Fix
CO 32 ed 2.8.11 47(54){1-5} Element <w:style> has no child <w:priority>. Fix
CO 33 ed 2.14.7 78(90){29} Code should read “Some “ (including white space) to agree with example Element <w:style> has no child <w:priority>.
CO 34 te 3.2.9.2.2 105(107){27} The method for specifying references to cells and external files using the <f> tag is presented, but the complete behavior is not presented in the normative section (Part 4 Section 3.3.1.37) for this tag. It is presented later in Part 4, Section 3.17.2.3, but even here there is no mention of references to external spreadsheets. Define the behavior in the normative clauses.
CO 35 te 3.16.9 226(238) In the 1900 date base system, the lower limit is January 1, 1900. Remove this unnecessary restriction and allow better date support. Allow negative values in the serial number or define a system counting from an earlier date (e.g. 0 A.D.)
CO 36 ed 5.8.3.24 325(337){24} Code formatting differs from the rest of the standard. It is a graphic and has no line numbers Fix
CO 37 ed 5.8.4.1 327(339){16} Code formatting differs from the rest of the standard. It is a graphic and has no line numbers Fix
CO 38 ed 5.8.4.2 328(340){1} Code formatting differs from the rest of the standard. It is a graphic and has no line numbers Fix
CO 39 ed 5.8.4.3 329(341){1} Code formatting differs from the rest of the standard. It is a graphic and has no line numbers Fix
CO 40 ed 5.8.4.5 332(344){1} Code formatting differs from the rest of the standard. It is a graphic and has no line numbers Fix
CO 41 ed 5.8.5.3 333(345){19} Code formatting differs from the rest of the standard. It is a graphic and has no line numbers Fix
CO 42 ed 5.8.5.4 334(346){6} Code formatting differs from the rest of the standard. It is a graphic and has no line numbers Fix
CO 43 ed 5.9.2.1 339(351){10} The definition for the unit EMU should be stated as 91440 EMU = 1 U.S. Inch and 36000 EMU = 1 cm. Fix
CO 44 ed 5.9.4.3 344(356){33} Use straight quotes instead of curly ones Fix
CO 45 ed 5.9.4.3.1 345(357){29} Use straight quotes instead of curly ones Fix
CO 46 ed 5.12.3 356(368){3} The example presents invalid XML Fix
CO 47 ed 5.12.3.1.1 356(368){22} The example presents invalid XML Fix
CO 48 ed 5.12.3.1.2 357(369){10} The example presents invalid XML Fix
CO 49 ed 5.12.3.1.3 358(369){36} The example presents invalid XML Fix
CO 50 ed 5.13.2.2 369(381){1} Example is inconsistent. Change for valid XML, o present as a tree graphic.
CO 51 ed 5.14.3 373(385){21} The example presents invalid XML Fix
CO 52 ed 5.14.3.1.1 373(385){36} Code formatting differs from the rest of the standard. It is a graphic and has no line numbers Fix
CO 53 ed 5.14.3.1.1 374(386){5} The example presents invalid XML Fix
CO 54 ed 5.14.3.1.2 374(386){24} The example presents invalid XML Fix
CO 55 ed 5.15.3.1.3 379(391){20} Missing closing quotes for attribute “maxOccurs” Fix
CO 56 ed 5.15.3.1.4 380(392){5} Missing closing quotes for attribute "name" Fix
CO 57 ed 5.15.4.1 382(394){26} Missing closing quotes for attribute "name" Fix
CO 58 ed 5.15.4.1.3 384(396){15} Missing closing quotes for attribute "name" Fix
CO 59 ed 5.15.4.1.6 386(398){9} Missing closing quotes for attribute "name" Fix
CO 60 ed 5.15.4.1.6 386(398){10} Invalid text “odoc” Remove
CO 61 ed 5.15.5.1.3 389(401){33} Invalid character at end of line Remove
CO 62 ed 5.15.6.3.1 403(415){25-26} Attributes are given without quotes Add quotes
CO 63 ed 5.15.6.3.16 407(419){11} Attribute “animLvl” is not closed with quotes and has no white space to separate it from next attribute “type” Fix
CO 64 ed 5.15.6.3.39 415(427){16} Missing closing quotes for attribute “maxOccurs” Fix
CO 65 ed 7.1 431(443) The description for OMath in this informative section is not detailed enough for the purpose of this section, especially when compared to the rest of the sections in this part. It has no code examples like the rest of the sections. Make the text more detailed and consisten with the other sections
CO 66 ed 7.1 431(443) The term "mathematical equation" typically imples an equal sign. Use of the term "mathematical expression" is recommended throughout the section
CO 67 ed 7.1 431(443){18} Duplicate expressions Remove duplicates
CO 68 ed 7.1 431(443){19-20} Duplicate expressions Remove duplicates
CO 69 ed 7.1.10 435(447){5} Expression "x+x+x" is used, and below it appears as "x+x+..." Fix
CO 70 ed 7.1.12 436(448){11} The property refers to the upper index, no the lower one Fix
CO 71 ed 7.2.1 440(452){6} Invalid XMl in example Fix
CO 72 ed 7.4.3 445(457){8,15,22} Invalid XML in example. Closing element </b:nameList> missing three times Fix
CO 73 ed 8.1 447(459){11-13} Code formatting is not consistent with the rest of the standard because it is in italics. For consistency use of double quotes instead of apostrophe is preferred. Fix
CO 74 ed 8.2.5 452(464){29} El formato del código es diferente al resto del estándar. Además no es necesario usar una ruta de archivo tan larga para el ejemplo Fix
CO 75 ed 8.3.4.1.1 456(468){1} The image is practically unreadable because of resolution and background color Fix
Part 4
CO 76 te 2.2.1 27(33){4} Background elements are defined as using VML. However, 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 applications that need a file format for drawings are strongly encouraged to use preferentially DrawingML”. In this case, even new documents must use VML to specify backgorunds. Remove references to VML and substitue for DrawingML.
CO 77 te 2.2.1 27(33){8&21} Contradicting use of accent3 and accent5 – the text says one thing, but the example says another. Fix the contradiction.
CO 78 te 2.2.1 28(34){1} The sentence 'or auto to allow a consumer to automatically determine the background color as appropriate.' does not define the appropriate behavior of the consumer, whereas the definition of the corresponding simple type, found in Part 4, page 1737, explicitly states that 'This value shall be used to specify an automatically determined color value, the meaning of which is interpreted based on the context of the parent XML element.' Define the characteristics of the auto value for the color attribute of the background element properly.
CO 79 te 2.2.1 29(35){0} There are several instances of the word 'border' that are meaningless in this context (the text is supposed to describe the 'background' element at that location and no “border” has been defined). Clarify which border the text refers to (if any notion of border must be introduced here) or else rewrite the text so that it makes sense.
CO 80 te 2.3.1.8 59 (66) The element “cnfStyle” uses a bitmask to specify various paragraph conditional formatting properties.. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. Rewrite this subclause to express the feature using XML constructs rather than bitmasks.
CO 81 te 2.3.2.8 175(182) It is desired to have improved interoperability between ODF and OOXML. However, OOXML's "vert" attribute only allows text to be rotated 270 degrees, whereas ODF's equivalent allows text rotation by 90 or 270 degrees. Include ability to specify 90 degree text rotation in addition to existing 270 degree rotation.
CO 82 te 2.3.2.1 160(167) It is desired to have improved interoperability between ODF and OOXML. However, OOXML text runs only support two font weights, bold or normal, where ODF supports the fuller range of font weights from XSL-FO Include support for additional font weights, 100, 200, 300, 400, 500,600. 700, 800 and 900.
CO 83 te 2.3.2 159(166) It is not clear why formatting indications (like bold, italic, etc.) is to be done using individual elements, as this complicates parsing. This method presents no clear design benefit. This can be done more naturally using attributes, which will make the document easier to interpret using standard XML tools.
CO 84 te 2.3.3.17 259(266) The type of video element allowed is not specified. Use of propietary codecs will break portability of a document, and may present patent problems for implementation, since they are outside of the scope of this specification. Specify a set of patent free, portable video codecs as base, and whenever other codecs are used, mark the document as “extended” (See comment for Part 1, Section 2.6)
CO 85 te 2.3.3.19 261(268) The object element is used for embedding inline objects. However the text says  “The layout properties of this embedded object are specified using the VML syntax”.  VML is in the specification for legacy reasons only (See comment for 2.2.1). All OOXML consumers would need to support VML, even where legacy documents are not present. Remove this element as there is already an element in section 2.3.3.9 which can embed DrawingML objects.
CO 86 te 2.3.3.21 264(271) The object element is used for embedding inline objects. However the text says  “The layout properties of this embedded object are specified using the VML syntax”.  VML is in the specification for legacy reasons only (See comment for 2.2.1). All OOXML consumers would need to support VML, even where legacy documents are not present. Remove this element as there is already an element in section 2.3.3.9 which can embed DrawingML objects.
CO 87 te 2.4.7 302(309) This element uses a bitmask to specify various table cell formatting properties. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. Rewrite this subclause to express the feature using XML constructs rather than bitmasks.
CO 88 te 2.4.8 303(310) This element uses bitmasks to specify various table row formatting properties. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. Rewrite this subclause to express the feature using XML constructs rather than bitmasks.
CO 89 te 2.4.46 421(428) It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the ability to specify a multi-row header that repeats across pages, where ODF does. Include in this section the ability to specify that the first N rows of a table can be selected as a header.
CO 90 te 2.4.51 428(435) This element uses a bitmask to specify various table style formatting properties.. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. Rewrite this subclause to express the feature using XML constructs rather than bitmasks.
CO 91 te 2.4.52 430(437) This element uses a bitmask to specify various table style formatting exceptions. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. Rewrite this subclause to express the feature using XML constructs rather than bitmasks.
CO 92 te 2.8.2.2 “0xEE”739(746) This value is said to signify “an Eastern European character set”. There is no such thing. First, “Eastern Europe” is not unambiguously delineated. Second, this region uses many character scripts, including Roman, Cyrillic, Arabic, Armenian, etc. Explain what is meant by, “an Eastern European character set”.
CO 93 te 2.8.2.2 739(746) The default character set is said to be “the ANSI character set”. But ANSI has standards for many character sets. Do you mean ANSI 209-1992 “Matrix Character Set for OCR”? Probably not. So a normative reference to a specific standard is required. Provide normative reference for “the ANSI character set”.
CO 94 te 2.8.2.16 758(765) Use of bit masks is not the right way in XML. This element of the specification uses a set of bitmasks to specify which code pages a given font supports. The use of bitmasks rather than an XML Schema derived type makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. One of the advantages of XML is that we don't need to encode data like this any more. Rewrite this subclause to express the feature using XML constructs rather than bitmasks.
CO 95 te 2.15 1104(1111) The settings mechanism is designed to accomodate Microsoft Office's particular settings only. The mechanism is not extensible. Make the settings mechanism extensible.
CO 96 te 2.15.1.28 1158(1165) The algorithm given here is new and has not undergone peer review. Even though this is an application-enforced security feature, a strong known and tested algorithm should be used. Use a recognized standard cryptographic hash algorithm like SHA-256, Whirlpool, etc.
CO 97 te 2.15.1.28 1158(1165) It is stated that document protection “shall be enforced”. “Shall”has been defined previously as required behavior. A few lines later it says that document protection “may be ignored”. Clarify this contradiction.
CO 98 te 2.15.1.28 1158(1165) This algorithm description fails to specify the encoding of the input password. The described algorithms make use of byte-level manipulations which depend on the machine architecture (big endian versus little endian). So it is necessary that all byte ordering assumptions be made explicit. Make the byte ordering assumptions explicit, both for the input password and the processing steps, so as to allow cross-platform interoperability.
CO 99 te 2.15.1.29 1172(1179) This element allows the classification of the document into one of three types: “letter”, “email” or “general”. Although the description says that this feature can be used by, “hosting applications to facilitate customized user interface and/or automatic formatting behaviors based on the 'type' of a given WordprocessingML document”, the taxonomy provided is so weak as to be practically useless. Either provide a reasonable document type taxonomy, or loosen the declared type to an xsd:string to allow applications to provide their own classifications.
CO 100 te 2.15.1.86 1251(1258) This element uses a bitmask to specify a style display filter. Use of bit masks is not the right way in XML. Rewrite this subclause to express the feature using XML constructs rather than bitmasks.
CO 101 te 2.15.1.87 1253(1260) This element uses a bitmask to specify style display sorting parameters. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. Rewrite this subclause to express the feature using XML constructs rather than bitmasks.
CO 102 te 2.15.2.32 1337(1344) The element “optimizeForBrowser” only accomodates Internet Explorer and Netscape Navigator. This section requires that “all settings which are not compatible with the target web browser shall be disabled.” There is no way to specify a standards compliant optimized output with PNG, MathML and SVG. This clause should be rewritten to express this feature in an application and platform neutral way, allowing more versatility.
CO 103 te 2.15.3.6 1378(1385) This is the “autoSpaceLikeWord95” element is defined in terms of a particular application's behavior. The standard contains insufficient detail on how to replicate this behavior. Define the intended behavior.
CO 104 te 2.15.3.26 1416(1423) The “footnoteLayoutLikeWW8” element, is defined in terms of a particular application's behavior. The standard contains insufficient detail on how to replicate this behavior. Define the intended behavior.
CO 105 te 2.15.3.31 1426(1433) The “lineWrapLikeWord6” element,  is defined in terms of a particular application's behavior. The standard contains insufficient detail on how to replicate this behavior. Define the intended behavior.
CO 106 te 2.15.3.32 1427(1434) The “mwSmallCaps” element,  is defined in terms of a particular application's behavior. The standard contains insufficient detail on how to replicate this behavior. Define the intended behavior.
CO 107 te 2.15.3.41 1442(1449) The “shapeLayoutLikeWW8” element,  is defined in terms of a particular application's behavior. The standard contains insufficient detail on how to replicate this behavior. Define the intended behavior.
CO 108 te 2.15.3.51 1462(1469) The “suppressTopSpacingWP” element,  is defined in terms of a particular application's behavior. The standard contains insufficient detail on how to replicate this behavior. Define the intended behavior.
CO 109 te 2.15.3.53 1467(1474) This is the “truncateFontHeightsLikeWP6” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. Define the intended behavior.
CO 110 te 2.15.3.54 1469(1476) The “uiCompat97To2003” element is defined as: “Disable UI functionality that is not compatible with Word97-2003”. The standard must be application neutral. Define this an application neutral way. If it is truly a Word-only feature, then remove it from OOXML and express as an application-defined extension.
CO 111 te 2.15.3.63 1481(1488) The “useWord2002TableStyleRules” element is defined in terms of a particular application's behavior. The standard contains insufficient detail on how to replicate this behavior. Define the intended behavior.
CO 112 te 2.15.3.64 1482(1489) The “useWord97LineBreakRules” element is defined in terms of a particular application's behavior. The standard contains insufficient detail on how to replicate this behavior. Define the intended behavior.
CO 113 te 2.15.3.65 1483(1490) This is the “ wpJustification” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. Define the intended behavior.
CO 114 te 2.15.3.66 1485(1492) The “wpSpaceWidth” element is defined in terms of a particular application's behavior. The standard contains insufficient detail on how to replicate this behavior. Define the intended behavior.
CO 115 te 2.16.4.3 1501(1508) The definition for BATHTEXT references 'the given Thai format', which makes no sense in the context of that definition. What “given Thai format”? Clarify the definition of 'BATHTEXT'.
CO 116 te 2.16.5.33 1537(1544) The field INCLUDEPICTURE says that it merely retrieves the picture contained in the named document. Is nothing else to be done with the picture? For example, should it be displayed? Define what is to be done with the picture once it is retrieved.
CO 117 te 2.16.5.33 1537(1544) 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. Define how pictures are named.
CO 118 te 2.16.5.33 1537(1544) No picture formats are listed as valid. There may be undocumented of patented picture formats, which will break portability of a document. Define a set of documented and patent-free formats for pictures, and mark the document as “extended” when a different one is used. See comment for Part 1, section 2.6)
CO 119 te 2.16.5.34 1537(1544) This does not define how a document to be passed to the INCLUDETEXT field 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. Define how documents are named.
CO 120 te 2.16.5.34 1537(1544) The INCLUDETEXT field “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. There should be specified at least a small set of interoperable formats. Whenever this element is used with a format not mandated by OOXML, an application must mark the document as “extended” (see comment for Part 1, Section 2.6)
CO 121 te 2.16.5.34 1537(1544) 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. Provide a proper external normative reference for the XSLT and Xpath versions which are allowed here.
CO 122 te 2.16.5.5 1512(1519){11-12} According to the text, the AUTONUM field is deprecated. A new standard should not contain deprecated parts. Remove all references to AUTONUM from the OOXML text and make sure LISTITEM includes all functionality necessary. The  transforming application must handle the conversion.
CO 123 te 2.16.5.77 1570(1577) The example that illustrates USERINITIALS section instead shows USERNAME. Correct the example.
CO 124 te 2.17.3 1622(1629) The external content import elements in WordprocessingML put document interoperability at risk, since not even a common ground is defined. Any application can put any content (even the whole document in an application specific way) here and the file can still be considered valid OOXML. It is necessary to set a common ground for external content, or declare that applications using this section are not OOXML comformant, to avoid misleading a user into thinking that a particular OOXML file can be viewed correctly by any application. One of OOXML's goals is interoperablity and application independence. Whenever this element is used, an application must mark the document as “extended” (see comment for Part 1, Section 2.6)
CO 125 te 2.18.106 1837(1844) The length  for the element ”ST_UcharHexNumber” is said to be “exactly 1 character”. This is inconsistent with the earlier language and the schema fragment given which defines it as being 1 octet long or two characters. Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.
CO 126 te 2.18.4 1631(1638) The borders lack proper definition, since no size, corner handling or additional files are given. 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 flavor. Define the borders in detail. Provide an interoperable extensibility mechanism for a document author or application to specify their own art border graphics.
CO 127 te 2.18.45 1737(1744) Length is said to be “exactly 3 characters”. This is inconsistent with the example given which has a length of 6 characters. Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.
CO 128 te 2.18.46 1738(1745) The list of highlight colors closely matches color codes in SVG 1.0 and ISO 15445, however there are innecessary divergences in a few colors like "darkBlue", "darkCyan" and "lightGray". Slight variations from widely used standards create confusion and are a source of errors. Follow previous standards and either reference SVG 1.0 or ISO 15445, or compile a list that follows these standards
CO 129 te 2.18.52 1748(1755) The use of a new set of language codes, apart from ISO 639 and ISO 639-2, adds no value and only increases the work required of any application that would process an OOXML document. 
Applications which use their own values to represent languages can easily convert from the standard language representation system to the codes they use internally, and vice versa.
Drop the use of the redundant ST_LangCode
CO 130 te 2.18.52 1748(1755) The type “ST_LangCode”is defined as containing, a two digit hexadecimal language code”. It is fruther stated that, “This simple type's contents must have a length of exactly 2 characters”. However, two hex digits can count up to 255 and the values enumerated in this clause go far beyond that. Refine the definition of this function, especially with respect to pre-metric measures so as to remove ambiguity.
CO 131 te 2.18.57 1759(1766) Type “ST_LongHexNumber” is defined simultaneously as containing four hexadecimal digits, four hexadecimal octets and exactly four characters. These definitions are not compatible. A hexadecimal octet is two hexadecimal digits. Clarify the definition. In particular note that xsd:hexBinary measures length in octets, not characters.
CO 132 te 2.18.66 1771(1778) The formatting system described here (ST_NumberFormat) is not clear. It lacks 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. Use a more flexible, extensible, generative approach to numeration, such as that used by the W3C's XSLT standard in their xsl:number support
CO 133 te 2.18.66 1771(1778) 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.
CO 134 te 2.18.66 “chicago” 1772(1779) Format is defined in reference to the “Chicago Manual of Style”, but no edition or page reference is provided. Either include the entire definition in the standard, or provide a proper external reference.
CO 135 te 2.18.66 “decimalEnclosedFullstop” 1773(1780) The example given does not show enclosed characters and so contradicts the normative text. Reconcile the text and the example.
CO 136 te 2.18.66 “lowerLetter”, etc.  1776(1783) 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. Clarify the text to explicitly cover this case.
CO 137 te 2.18.66 “numberInDash”, etc. 1776(1783) 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.
CO 138 te 2.18.72 1786 (1793) Length is said to be “exactly 10 characters”. This is inconsistent with the example given which has a length of 20 characters. Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.
CO 139 te 2.18.85 1800 (1807) 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? Provide full normative definitions for these graphical elements.
CO 140 te 2.18.86 1808(1815) The definition of type “ST_ShortHexNumber” says it contains two hexadecimal digits, two hexadecimal octets and exactly two characters. These definitions are not compatible. A hexadecimal octet is two hexadecimal digits. Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.
CO 141 te 3.2.7 1892(1899) There is no description of the usage of the “ext” element. This elementa allows extending the capabilities of SpreadsheetML, but this can break document interoperability. Define and limit the usage of the “ext” element or declare that applications using this element are not OOXML comformant as one of OOXML's goals is interoperablity and application independence. Whenever this element is used, an application must mark the document as “extended” (see comment for Part 1, Section 2.6)
CO 142 te 3.2.29 1917-1922 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.
CO 143 te 3.2.29 1915(1922) 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. Remedy so password hashes can be calculated on any Unicode password.
CO 144 te 3.2.29 1916(1923) This algorithm description fails to specify the encoding of the input password. Presumably it is Unicode, but in what encoding? UTF-16BE? UTF-16LE? UTF-16 with a BOM (Byte Ordering Mark)? The described algorithms make use of byte-level manipulations which depend on the machine architecture (big endian versus little endian). So it is necessary that all byte ordering assumptions be made explicit. Make the byte ordering assumptions explicit, both for the input password and the processing steps, so as to allow cross-platform interoperability. Keep in mind that the hash may be calculated on a different machine architecture than the password was entered with.
CO 145 te 3.2.29 1916(1923) 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? Clarify this processing, especially for passwords that use characters from more than one script.
CO 146 te 3.2.29 1916(1923) A hash algorithm is provided to secure passwords, 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. Use a standard, such ISO/IEC 10118-3:2004, compliant hash algorithm as the default. Other country specific standards could be acceptable such as FIPS-180 from NIST, but additionaly to glbal standards . Legacy hash algorithms should be supported via the described extension mechanism.
CO 147 te 3.3.1.61 1987(1994) “id” OOXML allows the inclusion of binary data for printer settings (DEVMODE), which presents a potential security risk. These configurations should be expressed with proper XML, and since they are platform specific, there should be proper definitions for each platform.
CO 148 te 3.3.1.62 1987(1994) “id” OOXML allows the inclusion of binary data for printer settings (DEVMODE), which presents a potential security risk. These configurations should be expressed with proper XML, and since they are platform specific, there should be proper definitions for each platform.
CO 149 te 3.3.1.69 2003(2010) No normative description of the password hashing algorithm is provided, so interoperability of this feature cannot be assumed. In an informative section, 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.
CO 150 te 3.3.1.69 2003(2010) 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.
CO 151 te 3.17 throughout Many of the financial functions rely on a “date count basis” value that is not defined in this standard. Without this level of definition implementors will not be able to evaluate these functions (e.g. page 2534(2541) “basis”, 2535(2542) “basis”) . Provide a full definition of “day count basis”, in particular with respect to treatment of leap years and leap days.
CO 152 te 3.17 throughout The mathematical formula graphic given in many places borders on unreadable and compares very poorly with the clarify of the rest of the text and most other images (e.g. page 2552(2559) line 1, line 3). Provide better quality mathematical formula graphics.
CO 153 te 3.17.3 “#DIV/0!” 2521(2528) The “note” for this error value appears to define required behavior, not informative remarks Make the contents of the note be part of the main text, not as a note.
CO 154 te 3.17.4.1 2522(2529) In the 1900 date base system, the lower limit is January 1, 1900, which is too recent. Allow negative date serial values to express dates prior to 1900 or define a system which starts at an earlier date (e.g. 1 A.D.).
CO 155 te 3.17.4.1 2522(2529) OOXML mandates wrong data calculations when the 1900 date system is used. For legacy considerations, introduce an compatibility tag such as “doLegacySpreadhseetDateCalculations” instead of forcing applications to perform wrong calculations.
CO 156 te 3.17.4.1 2522(2529) Two base systems are given, and while one is necessary for legacy compatibility, the second one introduces unnecesary restrictions like no dates before 1904. Processing dates before this year are a necessity in many applications. Remove the 1904 date base system and replace with a system that begins at an earlier date, e.g. 0 A.D.
CO 157 te 3.17.4.2, 3.17.4.3, 3.17.6.7    It is insufficient to represent times simply as a numeric value without timezone information. Specify that when stored in OOXML files, dates and times are always expressed in terms of UTC. Add a mechanism for storing in the file information on what timezone should be used to represent the time in human-readable form.
CO 158 te 3.17.6.7 2529(2536) This calls for the date serial number to be stored, “as accurately as possible”. This requirement is not precise and is untestable. State the minimum precision required.
CO 159 te 3.17.7.4 ACOS 2536(2543) It is not indicated whether the returned value shall be in radians or degrees Specify the angular units that should returned
CO 160 te 3.17.7.9 AND 2541(2548) 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 FALSE? Since some functions have side effects, it is necessary to define this in order to ensure interoperability. Specify whether this function allows short-circuit evaluation.
CO 161 te 3.17.7.11 ASC 2542(2549) This function converts a DBCS string to “half-width (single byte)” characters. But the mapping from DBCS to single byte. is undefined. What is intended here? Truncation? Conversion into nearest single byte character set? Provide a fuller definition of this function.
CO 162 te 3.17.7.12 ASIN 2542(2549) It is not indicated whether the returned value shall be in radians or degrees Specify the angular units that should returned
CO 163 te 3.17.7.14 ATAN 2544 (2551) It is not indicated whether the returned value shall be in radians or degrees Specify the angular units that should returned
CO 164 te 3.17.7.15 ATAN2         2544 (2551) It is not indicated whether the returned value shall be in radians or degrees Specify the angular units that should returned
CO 165 te 3.17.7.17 AVEDEV 2545(2552) 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. Provide a correct example.
CO 166 te 3.17.7.17 AVEDEV 2545(2552) The function description has a typo/duplication: “cells with the value 0value 0” Fix the typographical error
CO 167 te 3.17.7.34 CELL        2560 (2567) The list of values supported for the “format” argument is far shorter than the list of possible numeric formats. What happens if CELL(“format”, A1) is called on a cell with a format not on this list? Specify what happens in this case, or define a new type to avoid these cases.
CO 168 te 3.17.7.35 CHAR   2563(2570) This function maps between numbers and characters. But this mapping must be defined by a character set and none is defined here. Specify what character set is used for this mapping (ASCII?).
CO 169 te 3.17.7.37 CHIINV    2564(2571) This function says, “CHIINV uses an iterative search technique”. This is specifying an implementation, not a testable performance criterion. Other approaches should be permitted. Keep the suggestions, but put them in informative Notes or Guidance.
CO 170 te 3.17.7.38 CHITEST     2565 (2572) The definition of this function says the the results are “unspecified” if the two ranges do not have the same number of points. But isn't this a clear argument error where should be returned? Surely we can document what Excel does here? Specify the required results for the case where the two ranges are of unequal size.
CO 171 te 3.17.7.47 CONFIDENCE   2571(2578) This function cannot be calculated without making an assumption about the distribution of the data? Are we assuming normally distributed data? uniformly distributed data? Make the distribution assumptions explicit.
CO 172 te 3.17.7.48 CONVERT  2572(2579) This function is ambiguously defined, especially with regards to the traditional units of measure. For example, a tablespoon is 15ml in the US, but 20ml in Australia. Which is meant here? Similarly, a cup is defined differently in various countries, e.g. 8 oz in US, except the FDA defines it for food labeling purposes as 240ml, while it is 250ml in Australia and 285ml in the UK. Also, the unit Pica is oncorrectly defined as 1/72 inch when it should be 1/72 foot. Refine the definition of this function, especially with respect to pre-metric measures so as to remove ambiguity.
CO 173 te 3.17.7.49 CORREL  2576(2583) 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. Correct the text
CO 174 te 3.17.7.50 COS  2577 (2584) It is not indicated whether the parameter is in radians or degrees Specify the angular units that this parameter is in
CO 175 te 3.17.7.65 CUBEKPIMEMBER    2590(2597) 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
CO 176 te 3.17.7.65 CUBEKPIMEMBER    2590(2597) The definition of this function says that it retrieves an OLAP Cube from a “SQL Server”. Surely this function is not limited to use only against Microsoft database servers? Provide a vendor-neutral definition of this function.
CO 177 te 3.17.7.66 CUBEMEMBER  2591(2598) A multidimensional expression (MDX) that evaluates to a unique member in the cube”. But MDX is undefined. Define the syntax and semantics of an MDX
CO 178 te 3.17.7.74 DATE 2600(2607) The definition of date normalization is rather loose. I think you want to say something like this; month is greater than 12, then month-12 shall be added to the first month in the year specified.”, etc. The problem with how it is stated is that “that” does not refer to anything in “that number of months”. Clarify the definition of date normalization.
CO 179 te 3.17.7.76 DATEVALUE  2603(2610)       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 ommitted, 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”? Do we assume the current date? of the current year? Resolve the ambiguity in the definition when a string with time format is passed in.
CO 180 te 3.17.7.77 DAVERAGE    2603(2610) Normative information regarding the processing of “an entire column in a database” is placed in an informative note. Since it is clearly stating a requirement in the processing this should be in the normative text. Rework the note into the normative description of this function.
CO 181 te 3.17.7.78 DAY         2605(2612) The function does not define what a “Gregorian day” is, nor why it would be different in the 1900 versus 1904 date bases for a date in 1982. Is this just returning the day of the month? Why would this function return two values for that in 1982? Define fully what this function returns.
CO 182 te 3.17.7.91 DISC      2616(2623) 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)
CO 183 te 3.17.7.95 DOLLARDE       2619(2626) This function is ambiguously defined. Specifically we need to know how many decimal digits we need to look at to determine the numerator of the fraction. The example given DOLLARDE(1.02,16) = 1+ 2/16. But what about, after a serious of calculations and in the presence of accumulated floating point error we have DOLLARDE(1.020000001, 16)? Is this now 1 + 20000001/16? or 1,250,001? Also the definition is worded incorrectly. The first parameter is not “a number expressed as a fraction.” It is “a numbered interpreted as a fraction”. Also, the information marked as “Note” seems to be the most critical part of the definition and so should be part of the normative material. Clarify how this function works
CO 184 te 3.17.7.96 DOLLARFR 2620(2627) The information marked as “Note” seems to contain the only definition of what this function actually should do, so it should be made part of the normative material. Rework the note into the normative description of this function.
CO 185 te 3.17.7.101 DURATION    2623(2630) The function is defined in terms of $100 par value, but there is nothing about the bond calculations that is inherently tied to the US Dollar. Recommend the use of the generic currency sign here (U+00A4)
CO 186 te 3.17.7.111 EXACT 2631(2638) String comparisons in an international setting are typically described as either lexical comparisons where the strings are compared character by character for identity, and by collation comparisons where equivalent characters are considered identical. This function does not say  which method it uses. Clarify what defines two strings as having identical content.
CO 187 te 3.17.7.118 FIND 2636(2643) Similar issue to EXACT. Is this a lexical comparison or collation-based? Clarify the basis for finding substrings
CO 188 te 3.17.7.119 FINDB  2637(2644) Similar issue to EXACT. Is this a lexical comparison or collation-based? Clarify the basis for finding substrings
CO 189 te 3.17.7.120 FINV 2638(2645) This function says, “FINV uses an iterative search technique”. This is specifying an implementation, not a testable performance criterion. Other approaches should be permitted. Keep the suggestions, but put them in informative Notes or Guidance.
CO 190 te 3.17.7.123 FIXED  2640(2647) The rounding algorithm is not specified. How for example, do we calculate FIXED(0.5,0)? Round up, round down? State what the rounding conventions are.
CO 191 te 3.17.7.131 GAMMAINV2646(2653) This function says, “GAMMAINV uses an iterative search technique”. This is specifying an implementation, not a testable performance criterion. Other approaches should be permitted. Keep the suggestions, but put them in informative Notes or Guidance.
CO 192 te 3.17.7.144 HYPERLINK  2658(2665) The definition says that an allowed format for the link-location parameter is a “universal naming convention (UNC) path on a server”, though this term is not defined. Provide a normative definition or reference for a UNC path.
CO 193 te 3.17.7.186 KURT 2690(2697) Definition is incomplete. Formulas don't stand for themselves. You need to connect the notation to the function arguments. So, as stated, “where s is the sample standard deviation”, but it should be followed by, “and n is the number of data points in the range, and X-bar is the sample mean” Provide the complete definition.
CO 194 te 3.17.7.201 LOWER  2704(2111) This function is ambiguous. Is it asking for a lexical, character by character conversion to lowercase? Or for a whole-word conversion? For example, Greek capital Sigma has two lower case forms, one reserved for use as the terminal letter in a word. As written, it is not clear whether this function should be implemented to take that into consideration or not. Clarify what it means to convert to lower case.
CO 195 te 3.17.7.206 MDURATION 2708(2715) The function is defined in terms of $100 par value, but there is nothing about the bond calculations that is inherently tied to the US Dollar. Recommend the use of the generic currency sign here (U+00A4)
CO 196 te 3.17.7.207 MEDIAN  2709(2716) The text currently says, “If there is an even number of numbers in the set, MEDIAN calculates the average of the two numbers in the middle”. This is ambiguous. Middle of what? Middle of the range is the most direct interpretation. Probably want something more like, “The values in the range are logically ranked from lowest to highest and the middle number is returned. If there is an even number of numbers in the set...” Clarify the definition.
CO 197 te 3.17.7.227 NORMINV 2724(2731) This text says, “NORMINV uses an iterative search technique”. This is specifying an implementation, not a testable performance criterion. Other approaches should be permitted. Keep the suggestions, but put them in informative Notes or Guidance.
CO 198 te 3.17.7.229 NORMSINV 2726(2733) This text says, “NORMSINV uses an iterative search technique”. This is specifying an implementation, not a testable performance criterion. Other approaches should be permitted. Keep the suggestions, but put them in informative Notes or Guidance.
CO 199 te 3.17.7.243 OR 2741(2748) 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. Specify whether this function allows short-circuit evaluation.
CO 200 te 3.17.7.282 SEARCH/SEARCHB 2774(2781) Is this a lexical comparison or collation-based search? Clarify the basis for string comparisons
CO 201 te 3.17.7.287 SIN 2777(2784) It is not indicated whether the parameter is in radians or degrees Specify the angular units that this parameter is in
CO 202 te 3.17.7.313 TAN 2797(2804) It is not indicated whether the parameter is in radians or degrees Specify the angular units that this parameter is in
CO 203 te 3.17.7.344 WORKDAY  2821(2828) This function is defined to skip over weekends in its calculations, but weekend is not defined and has different definitions in different parts of the world. Define this function unambiguously and preferably in a way which provides for cultural adaptability in the definition of a weekend.
CO 204 te 3.17.7.348 YEARFRAC 2826(2833) 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.
CO 205 te 3.18.86 2929(2936) Length is said to be “exactly 4 characters”. This is inconsistent with the schema fragment given which defines it as being 4 octets long or 8 characters. Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.
CO 206 te 4.3.1.35 2994(3001) The element "smartTags" is insufficiently defined for DrawingML. Is the behavior equivalent to the behavior in WorprocessingML? Define the behavior of smart tags for DrawingML
CO 207 te 4.6.9 3083(3090) The audio codecs allowed for the “audio” element are not specified. There are many propietary and non-portable codecs which would break portability of a document. Define a set of patent-free portable audio codecs as base. Whenever other codecs are used, the document must be marked as “extended” (see comment for Part 1, Section 2.6)
CO 208 te 4.6.68 2994(3001) The audio codecs allowed for the “snd” element are not specified. There are many propietary and non-portable codecs which would break portability of a document. Define a set of patent-free portable audio codecs as base. Whenever other codecs are used, the document must be marked as “extended” (see comment for Part 1, Section 2.6)
CO 209 te 4.6.69 2994(3001) The audio codecs allowed for the “sndAc” element are not specified. There are many propietary and non-portable codecs which would break portability of a document. Define a set of patent-free portable audio codecs as base. Whenever other codecs are used, the document must be marked as “extended” (see comment for Part 1, Section 2.6)
CO 210 te 4.6.70 2994(3001) The audio codecs allowed for the “sndTgt” element are not specified. There are many propietary and non-portable codecs which would break portability of a document. Define a set of patent-free portable audio codecs as base. Whenever other codecs are used, the document must be marked as “extended” (see comment for Part 1, Section 2.6)
CO 211 te 4.6.93 3159(3166) The video codecs allowed for the “video” element are not specified. There are many propietary and non-portable codecs which would break portability of a document. Define a set of patent-free portable video codecs as base. Whenever other codecs are used, the document must be marked as “extended” (see comment for Part 1, Section 2.6)
CO 212 te 5 throughout The new unit EMU (English metric units) is never properly defined and used in several places. e.g. Sections 5.1.12.42, 5.1.5.1.1, 5.1.12.16. Produce a proper definition of EMU, clearly referenced when it is used, or use a standard unit of measure.
CO 213 te 5.1.5.2.3 3388(3395) Smart tags are mentioned but they are not described elsewhere in the VML specification Define the behavior of smart tags for VML
CO 214 te 5.1.5.3.2 3413(3420) Smart tags are mentioned but they are not described elsewhere in the VML specification Define the behavior of smart tags for VML
CO 215 te 5.1.12.28 3700(3707) Length is said to be “exactly 3 characters”. This is inconsistent with the schema fragment given which defines it as being 3 octets long or 6 characters. Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.
CO 216 te 5.1.12.37 3719(3726) The Panose value is said to be used, “so that generating applications using this Office Open XML Standard may determine the closest font type if necessary”. However, no font distance metric or font matching heuristic is described. Describe the intended font matching procedure.
CO 217 ge 5.1.12.37 3719(3726) Why are there several different definitions for a Panose value, both in Word Processing ML as well as Drawing ML? Since they are exactly the same they should be defined once in a shared schema.
CO 218 te 5.1.12.37 3719(3726) Length is said to be “exactly 10 characters”. This is inconsistent with the schema fragment given which defines it as being 10 octets long. Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.
CO 219 te 5.1.3.2 3292(3299) The audio codecs allowed for the “audioFile” element are not specified. There are many propietary and non-portable codecs which would break portability of a document. Define a set of patent-free portable audio codecs as base. Whenever other codecs are used, the document must be marked as “extended” (see comment for Part 1, Section 2.6)
CO 220 te 5.1.3.4 3294(3301) 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. Since Quicktime is a propietary technology not covered within this specification, must cause the docuement to be marked as “extended” (See comment for Part 1, Section 2.6)
CO 221 te 5.1.3.6 3296(3303) The video codecs allowed for the “videoFile” element are not specified. There are many propietary and non-portable codecs which would break portability of a document. Define a set of patent-free, portable video codecs as base. Whenever other codecs are used, the document must be marked as “extended” (see comment for Part 1, Section 2.6)
CO 222 te 5.1.3.7 3297(3304) The attribute “builtIn” specifies whether a sound is builtIn and is to be reference by name only and not included within the file. Since no list of built-in audio files is given, this will break a document's portabilty, as no application but the creator will posses certain audio files. For the sake of portabilty, this attribute should be removed. If this is not desired, provide a list and set of built-in audiofiles. As a last option, documents using this attribute should be marked as “extended” (see comments for Part 1, Section 2.6)
CO 223 te Section 6 4343(4350) OOXML specifies here a markup language called Vector Markup Language (VML) which, in addition to DrawingML, specifies a vocabulary for describing graphical objects. Section 6.1 says, “The DrawingML format is a newer and richer format created with the goal of eventually replacing any uses of VML in the Office Open XML formats. VML should be considered a deprecated format included in Office Open XML for legacy reasons only and new applications that need a file format for drawings are strongly encouraged to use preferentially DrawingML” The need to support VML by OOXML consumers, in addition to DrawingML, would come at great implementation expense (the VML specification is over 600 pages) , would disadvantage all vendors but Microsoft, and would hurt interoperability. Remove VML from OOXML and use DrawingML instead. If needed add special legacy features in DrawingML.
CO 224 te 6.1.2.7 4444(4451), “tableproperties” This element uses a bitmask to specify VML table properties. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. Rewrite this subclause to express the feature using XML constructs rather than bitmasks.
CO 225 te 6.1.2.19 4643 (4650) The "equationxml" attribute of the "shape" element is "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". This makes interoperability impossible when this element is present. It is suggested that this element, for the sake of interoperability, not be made extensible. If it is considered absolutely necessary it would be preferable to create a separate element, e.g. "alternateequationxml", and mark the document as “extended” (see comment for Part 1, Section 2.6)
CO 226 te 6.1.2.19 4653 (4660) The "gfxdata" is defined as an encoded package whose contents are application defined. This lack of definition breaks interoperability as content placed here by an application may not be understood by another one. It is suggested that this element, for the sake of interoperability be limited to a particular package type. If extensibilty is desired in this case mark the document as “extended” (see comment for Part 1, Section 2.6)
CO 227 te 6.4.2.10 4653 (4660) 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.
CO 228 te 6.4.3.1 4955(4962) 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. Make standard neutral by adding options for other relevant platforms. The desire is to allow cross platform interoperability and efficiency.
CO 229 te 7.1 4961(4968) 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. It is recommended that this section be removed from OOXML and that the proposers of OOXML work within the W3C's MathML activity, where MathML 3.0 is currently being drafted, to produce a single standard for equations that can be used later referenced by a future version of OOXML.
CO 230 te 7.1 4961(4968) OOXML is not compatible with the industry standard language for displaying mathematical equations — MathML — used by the research community and the most important publications as Science, Nature, etc... . No interoperability with MathML is in the OOXML specifications. Add the pertinent interoperability with MathML
CO 231 te 7.4.2.4 5122(5129) 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.
CO 232 te 7.4.2.4 5122(5129) 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 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.” Remove the bstr type from OOXML
CO 233 te 7.4.2.5 5122(5129) It doesn't make sense to specify strings as null-terminated C-style strings and then to base-64 encode that. That is avoiding XML and will cause the markup to interoperate poorly with XML-based tools. The entire Clipboard Data representation needs thought. It looks very much like it is mapping directly to the arbitrary internals of a single application. This clause should be rewritten to express this feature in an application and platform neutral way.
CO 234 te 7.4.2.5 5122(5129) This element defines usage on Windows and Macintosh platforms only, but it doesn't specify whether OS 9 or OS X, and leaves out other important operating systems like Linux. Make standard neutral, defining values for other prominent systems.
CO 235 te 7.4.2.5 5122(5129) There is not enough information about the contents and their usage to provide interoperability. If these are binary blobs, they may present a security risk. Expand section to provide interoperability, and consider using XML syntax.
CO 236 de 7.5.2.1 5140(5220) The address at www.contoso.com points to the Microsoft Office product page. Use a neutral example.
CO 237 te throughout throughout The naming of elements is very inconsistent. Even though the choice of one letter for common elements seems appropriate, there seems to be no common technique for naming. The capitalization and vowel removal is inconsistent, as there are elements with names like: (from, but not limited to, Part 4 Section  2.15.1): ActiveWritingStyle, attachedSchema, documentType, docVars, endnotePr, hdrShapeDefaults)  . This is not a problem with the clarity of the specification, but it complicates the implementation of it unnecessarily, as developers will need to refer more often than necessary to the document to check for a certain element's particular spelling. Use a common element naming system
             
Some of the wording for the comments is taken from the comments by AENOR and BSI.  
Top