Fr2
F4275 Part 4, Section 2.16.5.53 PRINT page 1552, line 4 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'PRINT' must be considered as broken. Define 'PRINT' properly or else remove all references to it from the OOXML text.
F4276 Part 4, Section 2.16.5.54 PRINTDATE page 1552, line 13 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'PRINTDATE' must be considered as broken. Define 'PRINTDATE' properly or else remove all references to it from the OOXML text.
F4277 Part 4, Section 2.16.5.55 PRIVATE page 1553, line 14 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'PRIVATE' must be considered as broken. Define 'PRIVATE' properly or else remove all references to it from the OOXML text.
F4278 Part 4, Section 2.16.5.56 QUOTE page 1553, line 21 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'QUOTE' must be considered as broken. Define 'QUOTE' properly or else remove all references to it from the OOXML text.
F4279 Part 4, Section 2.16.5.57 RD page 1554, line 10 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'RD' must be considered as broken. Define 'RD' properly or else remove all references to it from the OOXML text.
F4280 Part 4, Section 2.16.5.58 REF page 1554, line 21 te The syntax for 'REF' is not compatible with the syntax of fields as provided on pages 14881489. Resolve the contradiction.
F4281 Part 4, Section 2.16.5.58 REF page 1554, line 26 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'REF' must be considered as broken. Define 'REF' properly or else remove all references to it from the OOXML text.
F4282 Part 4, Section 2.16.5.59 REVNUM page 1555, line 11 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'REVNUM' must be considered as broken. Define 'REVNUM' properly or else remove all references to it from the OOXML text.
F4283 Part 4, Section 2.16.5.60 SAVEDATE page 1556, line 13 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'SAVEDATE' must be considered as broken. Define 'SAVEDATE' properly or else remove all references to it from the OOXML text.
F4284 Part 4, Section 2.16.5.61 SECTION page 1557, line 5 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'SECTION' must be considered as broken. Define 'SECTION' properly or else remove all references to it from the OOXML text.
F4285 Part 4, Section 2.16.5.62 SECTIONPAGES page 1557, line 22 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'SECTIONPAGES' must be considered as broken. Define 'SECTIONPAGES' properly or else remove all references to it from the OOXML text.
F4286 Part 4, Section 2.16.5.63 SEQ page 1558, line 21 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'SEQ' must be considered as broken. Define 'SEQ' properly or else remove all references to it from the OOXML text.
F4287 Part 4, Section 2.16.5.63 SEQ page 1558, line 8 te The syntax for 'SEQ' is not compatible with the syntax of fields as provided on pages 14881489 ('identifier' is neither a terminal nor a non-terminal of the fields syntax). Resolve the contradiction.
F4288 Part 4, Section 2.16.5.64 SET page 1559, line 22 te The syntax for 'SET' is not compatible with the syntax of fields as provided on pages 14881489. Resolve the contradiction.
F4289 Part 4, Section 2.16.5.64 SET page 1559, line 29 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'SET' must be considered as broken. Define 'SET' properly or else remove all references to it from the OOXML text.
F4290 Part 4, Section 2.16.5.65 SKIPIF page 1560, line 18 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'SKIPIF' must be considered as broken. Define 'SKIPIF' properly or else remove all references to it from the OOXML text.
F4291 Part 4, Section 2.16.5.65 SKIPIF page 1560, line 8 te The syntax for 'SKIPIF' is not compatible with the syntax of fields as provided on pages 14881489. Resolve the contradiction.
F4292 Part 4, Section 2.16.5.65 SKIPIF page 1560, lines 68 te The description of 'SKIPIF' is inconsistent with itself ('SKIPIF' vs 'SKIP'). Resolve the contradiction.
F4293 Part 4, Section 2.16.5.66 STYLEREF page 1561, line 13 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'STYLEREF' must be considered as broken. Define 'STYLEREF' properly or else remove all references to it from the OOXML text.
F4294 Part 4, Section 2.16.5.67 SUBJECT page 1562, line 7 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'SUBJECT' must be considered as broken. Define 'SUBJECT' properly or else remove all references to it from the OOXML text.
F4295 Part 4, Section 2.16.5.68 SYMBOL page 1562, line 26 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'SYMBOL' must be considered as broken. Define 'SYMBOL' properly or else remove all references to it from the OOXML text.
F4296 Part 4, Section 2.16.5.69 TA page 1563, line 24 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'TA' must be considered as broken. Define 'TA' properly or else remove all references to it from the OOXML text.
F4297 Part 4, Section 2.16.5.70 TC page 1564, line 17 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'TC' must be considered as broken. Define 'TC' properly or else remove all references to it from the OOXML text.
F4298 Part 4, Section 2.16.5.71 TEMPLATE page 1565, line 4 te The 'Retrieves' verb explicitly references a runtime behavior, which is out of the documented scope of the OOXML proposition, and not operable as far as a document storage format is concerned. The resulting definition for 'TEMPLATE' is broken. Define 'TEMPLATE' properly or else remove all references to it from the OOXML text.
F4299 Part 4, Section 2.16.5.71 TEMPLATE page 1565, line 4 te The 'the disk file name of the template used by the current document' sentence makes no sense in the context of the OOXML text. The resulting definition for 'TEMPLATE' is broken. Define 'TEMPLATE' properly or else remove all references to it from the OOXML text.
F4300 Part 4, Section 2.16.5.71 TEMPLATE page 1565, line 5 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'TEMPLATE' must be considered as broken. Define 'TEMPLATE' properly or else remove all references to it from the OOXML text.
F4301 Part 4, Section 2.16.5.72 TIME page 1565, line 18 te The 'Retrieves' verb explicitly references a runtime behavior, which is out of the documented scope of the OOXML proposition, and not operable as far as a document storage format is concerned. The resulting definition for 'TIME' is broken. Define 'TIME' properly or else remove all references to it from the OOXML text.
F4302 Part 4, Section 2.16.5.72 TIME page 1565, line 18 te The 'The Gregorian calendar is always used' sentence is too vague. Provide a proper reference to the calendar standard used.
F4303 Part 4, Section 2.16.5.72 TIME page 1565, line 1819 te The 'By default, the date-and-time-formatting-switch used is implementation-defined.' makes no sense in English. Define 'TIME' properly or else remove all references to it from the OOXML text.
F4304 Part 4, Section 2.16.5.72 TIME page 1565, line 20 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'TIME' must be considered as broken. Define 'TIME' properly or else remove all references to it from the OOXML text.
F4305 Part 4, Section 2.16.5.73 TITLE page 1566, line 17 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'TITLE' must be considered as broken. Define 'TITLE' properly or else remove all references to it from the OOXML text.
F4306 Part 4, Section 2.16.5.74 TOA page 1567, line 9 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'TOA' must be considered as broken. Define 'TOA' properly or else remove all references to it from the OOXML text.
F4307 Part 4, Section 2.16.5.75 TOC page 1568, line 8 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'TOC' must be considered as broken. Define 'TOC' properly or else remove all references to it from the OOXML text.
F4308 Part 4, Section 2.16.5.76 USERADDRESS page 1570, line 6 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'USERADDRESS' must be considered as broken. Define 'USERADDRESS' properly or else remove all references to it from the OOXML text.
F4309 Part 4, Section 2.16.5.77 USERINITIALS - ed The example that illustrates USERINITIALS section instead shows USERNAME. Correct the example.
F4310 Part 4, Section 2.16.5.77 USERINITIALS page 1570, line 24 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'USERINITIALS' must be considered as broken. Define 'USERINITIALS' properly or else remove all references to it from the OOXML text.
F4311 Part 4, Section 2.16.5.78 USERNAME page 1571, line 10 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'USERNAME' must be considered as broken. Define 'USERNAME' properly or else remove all references to it from the OOXML text.
F4312 Part 4, Section 2.16.5.79 XE page 1571, line 28 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'XE' must be considered as broken. Define 'XE' properly or else remove all references to it from the OOXML text.
F4313 Part 4, Section 2.18.4 ST_Border (Border Styles) - te 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. Provide an interoperable extensibility mechanism for a document author or application to specify their own art border graphics.
F4314 Part 4, Section 2.18.4 ST_Border (Border Styles) - 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? Also, some of the images, such as 'apples' or 'balloons3Colors' show copying artifacts, where extraneous lines or blotches appear. Provide full normative definitions for these graphical elements. Also, for informative purposes, these graphics may be provided in standalone file form, preferably in a scalable graphics format like SVG.
F4315 Part 4, Section 2.18.45 ST_HexColorRGB (Hexadecimal Color Value) - te 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.
F4316 Part 4, Section 2.18.51 line 22 ed double quotes used incorrectly, with two sets of close quotes. XML examples should be given using straight quotes
F4317 Part 4, Section 2.18.52 ST_LangCode (Two Digit Hexadecimal Language Code) - te This type is defined as containing, "a two digit hexadecimal language code". It is further 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. Reconcile the description of the type with the enumerated values.
F4318 Part 4, Section 2.18.57 ST_LongHexNumber (Four Digit Hexadecimal Number Value) - te The description of this type says it contains 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 measure length in octets, not characters.
F4319 Part 4, Section 2.18.66 ST_NumberFormat (Numbering Format) - 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.
F4320 Part 4, Section 2.18.66 ST_NumberFormat (Numbering Format) - te 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. Use a more flexible, extensible, generative approach to numeration, such as that used by the W3C's XSLT standard in their xsl:number support
F4321 Part 4, Section 2.18.66 ST_NumberFormat (Numbering Format) "chicago" te 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.
F4322 Part 4, Section 2.18.66 ST_NumberFormat (Numbering Format) "decimalEnclosedFullstop" te The example given does not show enclosed characters and so contradicts the normative text. Reconcile the text and the example.
F4323 Part 4, Section 2.18.66 ST_NumberFormat (Numbering Format) "lowerLetter", etc. te 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.
F4324 Part 4, Section 2.18.66 ST_NumberFormat (Numbering Format) "numberInDash", etc. 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.
F4325 Part 4, Section 2.18.72 ST_Panose (Panose-1 Number) - te No definition is provided for a "Panose-1 classification" of a font. Provide a proper external normative reference for this term.
F4326 Part 4, Section 2.18.72 ST_Panose (Panose-1 Number) - te 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.
F4327 Part 4, Section 2.18.72 ST_Panose (Panose-1 Number) page 1786, line 10 te The 'the Panose-1 classificationnumber a font' clause does not make sense in English. Rephrase.
F4328 Part 4, Section 2.18.85 ST_Shd (Shading Patterns) - 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? Provide full normative definitions for these graphical elements.
F4329 Part 4, Section 2.18.86 ST_ShortHexNumber (Two Digit Hexadecimal Number Value) - te The description of this type 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.
F4330 Part 4, Section 2.18.106 ST_UcharHexNumber (Two Digit Hexadecimal Number Value) - te Length 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.
F4331 Part 4, Section 3.2.29 workbookProtection (Workbook Protection) - 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. Use a standard, FIPS-180 compliant hash algorithm as the default. Legacy hash algorithms should be supported via the described extension mechanism.
F4332 Part 4, Section 3.2.29 workbookProtection (Workbook Protection) p. 1917-1922 te 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.
F4333 Part 4, Section 3.2.29 workbookProtection (Workbook Protection) pg. 1916 te 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.
F4334 Part 4, Section 3.2.29 workbookProtection (Workbook Protection) 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. Remedy so password hashes can be calculated on any Unicode password.
F4335 Part 4, Section 3.2.29 workbookProtection (Workbook Protection) pg. 1916 te 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.
F4336 Part 4, Section 3.3.1.61 pageSetup (Page Setup Settings) - 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.
F4337 Part 4, Section 3.3.1.69 protectedRange (Protected Range) - te 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.
F4338 Part 4, Section 3.3.1.69 protectedRange (Protected Range) - 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. Use a standard, FIPS-180 compliant hash algorithm as the default. Legacy hash algorithms should be supported via the described extension mechanism.
F4339 Part 4, Section 3.3.1.69 protectedRange (Protected Range) - te The securityDescriptor attribute, "definesuser 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.
F4340 Part 4, Section 3.10 Pivot Tables page 2236, line 1 ed The provided diagram is blurred. Replace with a clean diagram or remove it.
F4341 Part 4, Section 2.16.5.2 ADVANCE page 1509, line 13 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'ADVANCE' must be considered as broken. Define 'ADVANCE' properly or else remove all references to it from the OOXML text.
F4342 Part 4, Section 2.16.5.15 COMPARE page 1521, line 9 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'COMPARE' must be considered as broken. Define 'COMPARE' properly or else remove all references to it from the OOXML text.
F4343 Part 4, Section 2.16.5.22 EQ page 1527, line 27 te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'EQ' must be considered as broken. Define 'EQ' properly or else remove all references to it from the OOXML text.
F4344 Part 4, Section 3.17.4.1 Date Representation - te The restriction to only two date bases is arbitrary and based only on one vendor's applications. There are other reasonable values for date bases, including earlier ones for historical dates. Allow a range of vendor-declared date bases, or explicitly allow negative date serial values to express dates prior to 1900
F4345 Part 4, Section 3.17.7.341 WEEKDAY - 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. Remove the text that defines behavior that results in incorrect date calculations.
F4346 Part 4, Section 3.17.7.343 WEIBULL page 2820, line 15, and page 2821, lines 13 ed The provided equations are blurred, to the point of being almost unreadable. Provide clean equations.
F4347 Part 4, Section 3.18.86 ST_UnsignedIntHex (Hex Unsigned Integer) - te 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.
F4348 Part 4, Section 3.18.87 ST_UnsignedShortHex (Unsigned Short Hex) - te Length is said to be "exactly 2 characters". This is inconsistent with the schema fragment given which defines it as being 2 octets long or 4 characters. Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.
F4349 Part 4, Section 4.6.3 animEffect (Animate Effect) page 3075, line 6 ed The description of 'transition' makes an inconsistent use of double-quotes for values ('in' vs '"in"', 'out' vs '"out"'). Elect and apply a consistent rule for the use of double-quotes for values.
F4350 Part 4, Section 5.1.3.2 audioFile (Audio from File) - te No mention is made of what audio formats or codecs are permitted. An interoperable set of formats should be specified.
F4351 Part 4, Section 5.1.3.4 quickTimeFile (QuickTime from File) - te 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.
F4352 Part 4, Section 5.1.12.28 ST_HexBinary3 (Hex Binary of Length 3) - te 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. Since you already have defined a ST_HexColorRGB type, that latter type should be used instead. Use the ST_HexColorRGB type and remove ST_HexBinary3
F4353 Part 4, Section 5.1.12.28 ST_HexBinary3 (Hex Binary of Length 3) - te 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.
F4354 Part 4, Section 5.1.12.37 ST_Panose (Panose Type) - te No definition is provided for a "Panose setting of a font". Provide a proper external normative reference for this term.
F4355 Part 4, Section 5.1.12.37 ST_Panose (Panose Type) - te 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.
F4356 Part 4, Section 5.1.12.37 ST_Panose (Panose Type) - te 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.
F4357 Part 4, Section 5.1.12.37 ST_Panose (Panose Type) - ge 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.
F4358 Part 4, Section 6.1.2.1 arc (Arc Segment) page 4352, line 0 te According to the text itself, 'dgmlayout' attributes are not meaningful for 'arc' elements. If this is the case (which is common sense), then the 'dgmlayout' attribute should never be used for 'arc' elements. Forbid the use of 'dgmlayout' attributes for 'arc' elements.
F4359 Part 4, Section 6.1.2.1 arc (Arc Segment) page 4352, line 0 ed According to the text itself, 'dgmlayout' attributes are not meaningful for 'arc' elements, but it is still described by heavyweight drawings and text. Suppress unneeded clutter from the example.
F4360 Part 4, Section 6.1.2.1 arc (Arc Segment) page 4353, line 0 te The description of the 'dgmlayout' attribute contradict itself, stating that 'The possible values for this attribute are defined by the XML Schema integer datatype', while the preceeding description only assigns meanings to the 0, 1, 2 and 3 values. Resolve the contradiction.
F4361 Part 4, Section 6.1.2.1 arc (Arc Segment) page 4353, line 0 te The description of the 'dgmlayout' attribute leverages a small set of integer coded values, whereas an enumeration would better reflect the functionality. Use an enumeration to define the values of the 'dgmlayout' attribute.
F4362 Part 4, Section 6.1.2.1 arc (Arc Segment) page 4362, line 0 te The description of the 'style' attribute merely states that it 'uses the syntax described in [an external document]'. Either the syntax is defined by the said external document, or else the OOXML text must define it by itself. Define properly, in extenso or by reference to a standard, the 'style' attribute.
F4363 Part 4, Section 6.1.2.7 group (Shape Group) page 4444, "tableproperties" te 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.
F4364 Part 4, Section 6.1.2.19 shape (Shape Definition) pg. 4653 "equationxml" te This 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 we're going to have a new math markup language in XML, and ignore the existing MathML, let's 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. Define equations in an interoperable way.
F4365 Part 4, Section 6.1.2.19 shape (Shape Definition) pg. 4655, "gfxdata" te Describes a ""gfxdata"" attribute for the ""shape"" elements, which ""contains DrawingML content"" that is ""base-64 encoded"". However, the ""contents of this package are application-defined"", so even though they ""shall use the Parts defined by this Standard whenever possible"" there is not sufficient information for an independent implementation to read this data or display the ""DrawingML content"" contained therein. If we're going to have a new graphics markup language in XML, and ignore the existing SVG, let's 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. Define this in an interoperable way.
F4366 Part 4, Section 6.2.2.14 ink (Ink) - te This describes an ""ink"" element which stores ""ink annotations in an application-defined format."" This is apparently intended to store annotations, used with tablet input devices to add hand-written annotations to documents. These annotations are often a vital part of documents and their specification is undefined in OOXML. We are opposed to standardizing placeholder elements for entirely application-dependent proprietary formats without also specifying an interoperable format for those who with to create interoperable formats. Specify the "ink" format or remove the element from OOXML and make this an application extension using the extensibility mechanisms of OOXML.
F4367 Part 4, Section 6.4.2.10 CF (Clipboard Format) - te 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. Such reference should be part of the future OOXML Extention part
F4368 Part 4, Section 6.4.3.1 ST_CF (Clipboard Format Type) - 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. Several options here, but the desire is to allow cross platform interoperability. Such refernce should be part of the future OOXML Extention part
F4369 Part 4, Section 7.1 Math - 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. 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. To be taken into consideration during the convergence process proposed.
F4370 Part 4, Section 7.4.2.4 bstr (Basic String) - 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.
F4371 Part 4, Section 7.4.2.4 bstr (Basic String) - te 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
F4372 Part 4, Section 7.4.2.5 cf (Clipboard Data) - 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. Specify this so interoperability may be achieved.
F4373 Part 4, Section 7.4.2.5 cf (Clipboard Data) - te This element defines values for use on Windows and Macintosh platforms, but not for Linux or any other operating system. Several options here, but the desire is to allow cross platform interoperability.
F4374 Part 4, Section 7.4.2.5 cf (Clipboard Data) - 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"? Specify this so interoperability may be achieved.
F4375 Part 4, Section 7.4.2.5 cf (Clipboard Data) - te It doesn't make sense for us to be specifying 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. Ecma should rethink the entire Clipboard Data representation. 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.
F4376 Part 4, Annex C. Additional Syntax Constraints page 5205, line 3 te The 'the set of XML Schemas included in Annex A' sentence is abusive. Annex A merely references material, it includes none. The verbiage of this section touts that the constraints that bear upon what the OOXML text would consider as valid XML documents are defined by the OOXML text, which they are not. Define properly, in extenso or by reference to a standard, the constraints that must be applied to an XML document to determine whether or not it is compliant with the proposed OOXML standard.
F4377 Part 4, Annex C. Additional Syntax Constraints page 5205, line 56 te The 'These additional constraints can be deduced from the normative content of this Part' proposition falls short of what is expected from a standard. Either the OOXML text defines the constraints and they can be read from it, or else the OOXML text does not define the constraints (and the reader has to 'deduce' them from the text, which would be unacceptable). The verbiage of this section touts that the constraints that bear upon what the OOXML text would consider as valid XML documents are defined by the OOXML text, which they are not. Define properly, in extenso or by reference to a standard, the constraints that must be applied to an XML document to determine whether or not it is compliant with the proposed OOXML standard.
F4378 Part 4, Section 2.18.67 ST_OnOff (On/Off Value) page 1779, line 13 te The ST_OnOff simple types brings no clear value over the boolean type and has significant drawbacks: clutter in the text, awkward leverage in XSLT applications, lack of canonical literal values. Use the boolean type instead (with needed changes at calling places).
F4379 Part 4, Section 3 SpreadsheetML Reference Material - te According to XML Schema Part 2: Datatypes Second EditionW3C Recommendation 28 October 2004, section 3.2.2.1, the boolean data type can hold the literal values 0, 1, false or true. This excludes the on and off values. Many attributes definitions in Section 3 (more than 100) stipulate that they can take literal values 0, 1, false, true, off or on, and that they are of XML Schema boolean type. We contend that those definitions are broken and should be fixed.A concrete example of those is the autoLayout attribute of the customWorkbookView element, Section 3.2.3. It could be that the XML Schema used for those definitions referred to another specification, in which case the text should tell which. As far a our search could clarify the situation, Part 1 refers the specification above in the bibliography (while marking this as informative) and Part 4 gives no explicit reference to what could constitute the specification for XML Schema.Last but not least, it may be that other parts of the OOXML than Part 4 Section 3 suffer the same deficiency and must be fixed as well. Provide a proper definition of the attributes that wrongly pretend to be of boolean type while accepting literal values that are not of boolean type.
F4380 Part 4, Section 3.2 Workbook page 1874, line 22 te What is the meaning of 'This subclause describes the elements and simple types that comprise the workbook main definition'? Clarify the sentence or remove it.
F4381 Part 4, Section 3.2 Workbook page 1874, line 23 te 'The sheets are the central working surface for a spreadsheet application' cannot work as a definition for sheet, for several reasons: a) it refers to a specific kind of application, whereas the definition of the OOXML storage format should be completed in the context of XML files; b) it further refers to the presentation of specific renderings of documents, whereas the OOXML text explicitly declines to address behavioral aspects of the use of OOXML artifacts (Part 1 Sections 2.4 and 2.5); c) it cannot be a part of an XML file. While we understand that making clear what 'sheet' and 'sheets' are in the context of OOXML may call for a behavioral model and explanations that leverage the said behavioral model, we contend that this behavioral model is not appropriately described in the OOXML text, and that the relationships of the OOXML artifacts being defined by the text to the artifacts that pertain to the said behavioral model are not elicited in appropriate levels of clarity and details. Clarify the definition of sheet provided here.
F4382 Part 4, Section 3.2 Workbook page 1874, lines 23-39 te The terminology is inconsistent across that definition. Amongst other issues, 'book-level' vs 'workbook-level', 'sheet' vs 'worksheet', etc. The relationship of the concepts exposed to XML elements being unclear, this needs clarification beyond editorial work. Clarify the definition of workbooks provided here.
F4383 Part 4, Section 3.2 Workbook page 1874, line 26 te Does 'child objects' refer to anything but XML elements? If not, the text should use 'child elements' instead. If yes, this would call for clarification of what 'workbook' stands for in the sentence (since it could not be an XML element, and could hardly be an OOXML defined concept). Clarify the definition of workbooks.
F4384 Part 4, Section 3.2 Workbook page 1874, lines 29-32 ed The explanation here uses imprecise terms ('workbook properties', 'data points') where unambiguous terms could be used to express clear constraints on conformant documents. Use XML wording to express the constraints, i.e. 'A workbook element comprises one or more…'.
F4385 Part 4, Section 3.2 Workbook page 1874, line 38 ed 'Sheet1 itself' would refer to the peculiar instance of sheet within a peculiar instance of workbook. We'd expect the desired meaning to be more along 'The sheet element specification is given in…' Rephase.
F4386 Part 4, Section 3.2 Workbook page 1874, line 39 te The 'will be discussed in a separate section' lacks a proper reference. Provide a proper reference to the section that defines the sheet element (or else to the explanation that is specifically introduced by that sentence). Use the present time ('is' instead of 'will').
F4387 Part 4, Section 3.2.1 bookViews (Workbook Views) page 1875, line 2 ed 'Each view can specifies a window position' is not proper English. Replace with 'Each view specifies' or 'Each view can specify' depending on the considered sub-features being compulsory or not.
F4388 Part 4, Section 3.2.1 bookViews (Workbook Views) page 1875, line 2 te 'the collection of workbook views' in meaningless in the current context. Must be related to a workbook, hence 'the collection of workbook views of the enclosing workbook' might do. Better, use XML terms to define the element, even if this could/should be completed by an explanation of what workbook views mean in various rendering contexts. Clarify.
F4389 Part 4, Section 3.2.3 customWorkbookView (Custom Workbook View) - te The definition of customWorkbookView, both at the semantic level and for many of its attributes, has problems. A sample of those is provided in extenso here, but there are others to be found that are not detailed (more specifically, we did not contribute comments beyond the guid attribute, and we refrained from contributing all the problems found with the definition of the element in the text). We consequently contend that the proposed definition for the customWorkbookView element is broken and should be rewritten. Provide a proper definition of the customWorkbookView element.
F4390 Part 4, Section 3.2.3 customWorkbookView (Custom Workbook View) page 1879, line 19 ed The 'You can create more than one view of the same workbook without saving separate copies of the workbook' sentence brings no value at all to the text. Given the multiplicity of customWorkbookView into customWorkbookView, it is an euphemism. Moreover, it makes reference to a dynamic behavioral model ('save') that is not defined by the OOXML text. Remove that sentence.
F4391 Part 4, Section 3.2.3 customWorkbookView (Custom Workbook View) page 1879, line 20 te The 'Custom workbook views are created by the end-user via tools in the application user interface.' is plain wrong. What would prevent a user to create a custom workbook view by means of editing an OOXML document's customWorkbookView elements contents with a simple, non OOXML aware editor, to generate such contents with a conformant batch OOXML producer, etc.? This attempts to define customWorkbookView by use of an unspecified behavioral model, arbitrarily and implicitly singled out from the set of potential conformant applications' behaviors, and falls short of a proper definition by far. Provide a proper definition of custom workbook view.
F4392 Part 4, Section 3.2.3 customWorkbookView (Custom Workbook View) page 1880, line 2 te The 'shared workbook' concept is not defined here, and non trivial. Unless a definition is given for it, the definition of the 'autoUpdate' attribute is broken. Provide a definition of what a shared workbook is, either in extenso or by reference, or else provide a proper definition of the autoUpdate attribute by other means, or else remove the autoUpdate attribute from the OOXML text.
F4393 Part 4, Section 3.2.3 customWorkbookView (Custom Workbook View) page 1880, line 2 te According to XML Schema Part 2: Datatypes Second EditionW3C Recommendation 28 October 2004, section 3.2.2.1, the boolean data type can hold the literal values 0, 1, false or true. This excludes the on and off values. Consequently, either the definition of the autoUpdate uses another reference specification for XML Schemas, in which case that other reference specification should be properly identified in the definition, and the said specification authorizes the on and off values for the boolean type, or else the definition of autoUpdate is simply broken.Note: it seems that the use of on and off as boolean values for attributes is specified in many places throughout the OOXML text. A separate comment will be made to take this into account. Provide a proper definition of the autoUpdate attribute or else remove it from the OOXML text altogether.
F4394 Part 4, Section 3.2.3 customWorkbookView (Custom Workbook View) page 1880, line 2 te The 'when conflicts are found, the changes beingsaved always take precedence.' proposition in the definition for the changesSavedWin attribute makes no sense in the context of an XML document storage format. It draws upon a behavioral model that is not properly defined in the text. Accordingly, that definition is broken. Provide a proper definition for the changesSavedWin attribute or else remove it from the OOXML text.
F4395 Part 4, Section 3.2.3 customWorkbookView (Custom Workbook View) page 1880, line 2 te The definition for the 'guid' attribute obviously makes reference to mechanisms that are not defined by the OOXML text (especially the Globally word - is that a universal concept of some sort? how the is the uniqueness of the instances ensured?) Reading the definition of the associated ST_Guid simple type does not help. This must be clarified. Provide a proper definition for the guid attribute or else remove it from the OOXML text.
F4396 Part 4, Section 3.2.3 customWorkbookView (Custom Workbook View) page 1880, line 2 ed 'Correpsonds' is not English. Replace with 'Corresponds'.
F4397 Part 4, Section 3.2.3 customWorkbookView (Custom Workbook View) page 1880, line 2 te The 'activeSheetId [:]Specifies the sheetId of a sheet in the workbook that is the active sheet in this book view.' proposed definition is a tautology. Moreover, the 'active' word suggests a time related context that cannot be accepted without further elaboration in the context of the OOXML text which focuses on a storage format, hence something static. Provide a proper definition of the activeSheetId attribute or else remove it from the OOXML text altogether.
F4398 Part 4, Section 3.2.3 customWorkbookView (Custom Workbook View) page 1880, line 2 te The 'Specifies a boolean value that indicates that this application will automatically updatechanges at the interval specified by the mergeInterval attribute.' is meaningless in the context of an XML storage format specification. What does 'this application' stand for? Provide a proper definition of the autoUpdate attribute or else remove it from the OOXML text altogether.
F4399 Part 4, Section 3.2.4 customWorkbookViews (Custom Workbook Views) page 1885, lines 32-35 te The contrast between customWorkbookViews and bookViews (Section 3.2.1) is insufficiently explained. Moreover, the 'Users create custom views when there is more than one way of viewing the workbook.' seems to assign a secondary role to bookViews, which may not be the text authors intent. Clarify the relative positioning of bookViews and workbookCustomViews, either in extenso or by reference to an explanation provided elsewhere in the text.
F4400 Part 4, Section 3.2.4 customWorkbookViews (Custom Workbook Views) page 1885, lines 33-35 te The 'Users create custom views when there is more thanone way of viewing the workbook.' and 'enables the user to switch between the views easily' proposition define custom views in the context of a behavioral model that the OOXML does not define. Provide a proper definition of customWorkbookViews.
F4401 Part 4, Section 3.2.27 workbook (Workbook) page 1908, line 11 te 'This element is the root part of the workbook in SpreadsheetML' mixes XML and non-XML concepts into something that does not sum up to a proper definition of the workbook element. Should define the workbook element properly, and complete this as needed with an explanation of semantics relating to selected rendering contexts or to a proper behavioral model of conformant applications. Use XML proper terms and concepts to define the workbook element.
F4402 Part 4, Section 3.2.27 workbook (Workbook) page 1908, lines 11-20 te The definition proposed for the workbook structure does not match at all the detailed contents specified by the schema extract provided page 1910 lines 2-25. If the provided definition is only an explanation meant to illustrate some aspects of the workbook element, this should be made explicit in the text. At face value, this constitutes a self-contradicting definition for the workbook element. Resolve the contradiction and provide a proper definition for the workbook element.
F4403 Part 4, Section 3.2.27 workbook (Workbook) page 1908, line 12 te 'document' in 'The worksheet is the primary document that you use to store and work with data' does not match the definition for an OOXML document. Since OOXML explicitely precludes the association of other meanings to terms it defines than the definition it gives for them, the definition for worksheet provided here is broken. Provide a proper definition of worksheet.
F4404 Part 4, Section 3.2.27 workbook (Workbook) page 1910, lines 8 15 te The 'bookViews' and 'customWorkbookViews' are used as sibling elements into the 'workbook' element, with the same cardinalities. This reinforces the view that, for nomenclature consistency, except if there is specific meanings in OOXML that would drive a need for singling out 'bookViews', this one should be called 'workbookViews' instead. The same stand for the associated types. This is reinforced by the fact that the included element is called 'workbookView' (as opposed to 'bookView'). Rename 'bookViews', 'CT_BookViews', etc. to resp. 'workbookViews', 'CT_WorkbookViews', etc.
F4405 Part 4, Section 3.17.7.295 STANDARDIZE page 2782, line 26 ed The provided mathematical formula is blurred. Provide a clean mathematical formula.
F4406 Part 4, Section 3.17.7.295 STANDARDIZE page 2782, line 26 te The provided mathematical formula uses arguments that are not specified, breaking the definition for the STANDARDIZE function. Document the match between the mathematical formula arguments and the function arguments. The same for the results.
F4407 Part 4, Section 3.18.95 ST_XmlDataType (XML Data Types) page 2939, line 0 ed All referenced links lack the ':' character after 'http'. Replace all instances of 'http' by 'http:'.
F4408 Part 4 - ge This part includes many tables, especially to describe elements (parent elements, attributes). A very high proportion of these tables lack the upper border. A sampling done between page 430 and page 530 gave us a total of 135 tables, of which 49 (36%) exhibited that defect. Worryingly enough, there seems to be no consistent pattern that would easily sort of the reason why some tables lack the upper border while others do not, which suggests that a manual change will be needed for each faulty table.We suspect that this symptom extends to the whole of Part 4, and even maybe to the full documents set, resulting into hundreds of needed changes.While each of these changes is a small editorial change in nature, we contend that the scale of the issue promotes this comment to a general one. Pursue a thorough review of the whole OOXML text and apply a consistent style to tables, especially regarding the upper border.
F4409 Part 4 - ge This part includes many pictures. A very high proportion of these pictures are blurred, with various degrees of fuzzyness. A sampling done between page 1 and page 1500 gave us a total of 268 pictures, of which 245 (91%) exhibited that defect. We suspect that this symptom extends to the whole of Part 4, and even maybe to the full documents set, resulting into hundreds of needed changes.While each of these changes is a small editorial change in nature, we contend that the scale of the issue promotes this comment to a general one. It would simply not be acceptable that a published standard had more than 90 % of its pictures blurred, and we do not see the fixing of the current OOXML text as easy.A further analysis of the problem suggests that:- the tools used to edit the OOXML text where not appropriate for the task at hand;- many pictures resulted from the copy as a picture of a result that could (and hence should) have been obtained by the use of textual features of the tooling (e.g. numerous examples of text layout);- many pictures that had a true picture nature were copied with insufficient care;- most cases will have to be addressed separately, which will generate a considerable workload. Pursue a thorough review of the whole OOXML text and fix the pictures. Use text instead wherever appropriate.
F4410 Part 4, Section 2.8.2.2 charset (Character Set Supported By Font) page 740, line 0 te The '0xEE' 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".
F4411 Part 4, Section 2.8.2.2 charset (Character Set Supported By Font) page 740, line 2 te 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".
F4412 Part 4, Section 2.15.3.7 balanceSingleByteDoubleByteWidth (Balance Single Byte and Double Byte Characters) page 1380, line 22 ed The table header is repeated. We did not investigate to see whether this is a frequent issue with the text. Fix the table. Review the full text for such issues.
F4413 Part 4, Section 3 SpreadsheetML Reference Material - ge A single concept should bear the same name across the text, and the OOXML text should choose between 'array formula', 'array-entered formula' and 'array entered formula' to designate f elements which t attribute is valued to array. There are many instances of use of each of these terms across section 3, and a thourough review is needed.While editorial at first sight, this comment was promoted to general because of the number of occurrences of the different terms, and because of the inherent complexity of the underlying concept. Would the concept have been simpler, the risk of confusion would have been lower (and the acceptability of a lax use of similar but different terms for a single concept slightly higher). Choose one term for 'array formulas' and apply it consistently throughout the OOXML text.
F4414 Part 4, Section 3.3.1.37 f (Formula) page 1967, lines 6-25 te The definition of the t attribute of the f element is tautological. The definition of its type (ST_CellFormulaType) does not help. While an (inconsistent) attempt is made to describe its dataTable value, nothing tangible is said for the array, normal and shared values. Provide a proper definition for the t attribute, either in extenso or by reference.
F4415 Part 4, Section 3.3.1.37 f (Formula) page 1967, line 18 te The 'Data tables shall be recalculated whenever a worksheet is recalculated.' sentence defines the f element in the context of a dynamic behavioral model, whereas the OOXML text refuses to define any. Consequently, the definition of the f element is broken. Provide a proper definition for the f element.
F4416 Part 4, Section 3.3.1.37 f (Formula) page 1967, line 27 te The definition for the aca attribute states that 'true indicates that this formula is an array formula and…' which indicates a dependency between the aca and the t attributes, dependency that is not further clarified. What would be the semantics of an element which opening tag would be 'f aca="true" t="normal"'? Would it be conformant or not? What about 'f aca="false" t="normal"'? Clarify the definition of the f element.
F4417 Part 4, Section 3.6.1 c (Cell) page 2086, line 5 te The definition for the the a attribute is self-inconsistent (does the property denote an array formula or else an array entered formula?). Fix the contradiction.
F4418 Part 4, Section 3.6.1 c (Cell) page 2086, line 5 te The definition for the a attribute fails to specify what happens if the formula of the cell referenced by the c element is not of type array. The possible choices are c/a overrides f/whatever, f/whatever overrides c/a, or a conflict occurs and the document is not conformant. Moreover, the other combinations should be described as well. Unless this is specified, the definition of the a attribute of the c element is broken. It may turn out that the a attribute is not needed. Provide a proper definition for the a attribute or else remove it from the OOXML text.
F4419 Part 4, Section 3.17 Formulas - ge Many of the financial functions rely on a "day count basis" value that is not defined in this standard. Without this level of definition implementors will not be able to evaluate these functions. Provide a full definition of "day count basis", in particular with respect to treatment of leap years and leap days.
F4420 Part 4, Section 3.17 Formulas page 2508, line 28 ge The 'All arithmetic terms in an expression are real numbers.' must be untrue. It is at least inconsistent with the definition given for PI() (page 2745 line 15), which allows conformant implementations to truncate the value of the pi number to 15 significant digits, hence suggesting that the arithmetics are not performed according to the rules of pure real mathematics. It is also contradicting section 3.17.5.2 Precision, page 2524, which describes how applications are expected to cope with finite binary representations of real numbers, while failing though to fully explicit the impact of the said representation on computations (it limits itself to the projection of lexically valid number representations onto the value space).Operating according to the rules of pure real mathematics is an interesting topic in applied computer science, but can hardly be seen as a requirement for current applications. If it is, then we would contend that the OOXML text is placing exaggerated demands upon compliant applications. If it is not (which section 3.17.5.2 seems to indicate), then we must emphasize that most if not all definitions of OOXML functions are broken, since they rely upon real arithmetics for their semantics. Clarify the relationship of the OOXML text understanding of arithmetics to mathematical real arithmetics (in other words, state which of section 3.17.2 or section 3.17.5.2 wins, and rewrite the other).Depending on the conclusions on this topic, review all functions and provide a proper definition for each of them.
F4421 Part 4, Section 3.17.1 Introduction page 2507, line 12 te The 'equation that performs a calculation' proposition is non-sense. (Equations do not perform calculations.) The resulting definition for formulas is broken. Fix the definition of formulas.
F4422 Part 4, Section 3.17.1 Introduction page 2507, lines 12 14 te The definition for formulas is self-contradicting. Line 12 says they are equations, whereas line 14 says they are expressions. These terms refer to markedly different mathematical concepts, and the text should be clear about which of those applies. Fix the definition of formulas.
F4423 Part 4, Section 3.17.1 Introduction page 2507, line 17 te The provided example contradicts the definition given for PI() (page 2745 line 15). Fix the contradiction.
F4424 Part 4, Section 3.17.2 Syntax page 2508, line 16 te The reference to the definition of operators is broken ('§0'). Fix the reference.
F4425 Part 4, Section 3.17.2 Syntax page 2508, line 27 te The reference to the definition of the space operator is broken ('§0'). Fix the reference.