Comments of Brazil
MB Clause Parag Type Justification Proposed change
BR01 Part 4 [1] 2.15.3.31 [2] 2.15.3.32 [3] 2.15.3.41 [4] 2.15.3.51 [5] 2.15.3.53 [6] 2.15.3.63 [7] 2.15.3.64 [8] 2.15.3.65 [9] 2.15.3.66 [10]2.15.3.6 [11]2.15.3.26 te The elements : “lineWrapLikeWord6”[1], “mwSmallCaps”[2], “shapeLayoutLikeWW8”[3], “suppressTopSpacingWP”[4], “truncateFontHeightsLikeWP6”[5], “useWord2002TableStyleRules”[6], “useWord97LineBreakRules”[7], “wpJustification”[8], “wpSpaceWidth”[9], “autoSpaceLikeWord95”[10], “footnoteLayoutLikeWW8”[11] whose are defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. This group of elements should be more explained, describing details about how to implement it including one example for each case, and all references to mimic actions should be replaced by reproduce actions defined in publicly available external documents by authoritative entities for each element. By authoritative entities we mean the holder of the technical specification and/or the IPR.
BR02 Part 4 Section 2 te It is desired to have improved interoperability among other ISO document standards. Identified ( but not limited to) ISO 26300 attributes are : Text blinking; Table cell protection; An option to specify Numbers of lines for window or orphans lines; 'Manual' and 'From left' alignment in tables; Last line alignment in justified paragraph (provision that we can change the last line of the paragraph as Left, Center and Justify); 'Leading' line spacing in a paragraph; Tabs fill character of a paragraph; 'Title' and 'lowercase' style options; Table can have 'keep with next paragraph' set; A 'May Break Between Rows' attribute so as not to split a table; Allow entire sections to be marked as hidden; Background Image in Tables; Contents in a multi-column section can be evenly distributed resulting in balanced columns; An option to rotate the text by 90 or 270 degrees; Any number of rows can be selected for repeating Heading; Copy Heading while splitting Table; Table Shadowing Style; Vertical numbering in list items; Image can be positioned absolutely within a frame; Ability to set arbitrary Text background color Before/after text around foot notes references, Keep ratio feature for frames, columns for frames/text-boxes, Ability to assign to assign different page colors throught the document, Note embedded in text-boxes, ability to set each imageborder with different properties, background opacity, 'Auto' option when application decide if a page break should be, Font weights beyond just 'normal' and 'bold', Table of content protection against annual changes, Shadow distance, and a color of shadow other than black, Column separator attributes : width, color, height, vertical-align Text-box can define the vertical alignment of text(top, center, bottom)
BR03 Part 4, Section 2.2.1 background (Document Background) page 28, line 1 te 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.' Change the text to: ‘… or auto to allow a consumer to automatically determine the background color according to section 2.18.44’.
BR04 Part 4, Section 2.2.1 background (Document Background) page 27, lines 8 and 21 te Contradicting use of accent3 and accent5 Make the appropriate corrections.
BR05 Section 2.15.1.28 DocumentProtection Pg. 1158 te The described algorithms make use of byte-level manipulations which depend on the machine architecture (big endian versus little endian). Make the byte ordering assumptions explicit, both for the input password and the processing steps, in order to allow cross-platform interoperability.
BR06 Section 2.15.1.28 DocumentProtection Pg. 1158 te The algorithm description does not specify the Unicode encoding of the input password. Specify the Unicode encoding (e.g UTF-16BE, UTF-16LE, etc.)
BR07 Part 4, Section 2.15.2.32 te This feature has been defined in a way which ignores the existence of current browsers other than Internet Explorer. This section requires that “all settings which are not compatible with the target web browser shall be disabled.” This item should be reviewed concerning the use of other browsers than IE.
BR08 Part 4 Section 2.15.3 te These compatibility settings are only for versions of Microsoft Word. No allowance has been made for legacy settings from other applications. This section should make clear that all the settings are specific for Microsoft Office and that all other settings should use the extensibility mechanisms described in Part 5 of this specification.
BR09 Part 4 Section 2.15.3.16 te Ecma 376 section 2.15.3.16 doNotLeaveBackslashAlone (page 2180). This element specifies whether applications should automatically convert the backslash character into the yen character when it is added through user keyboard input. This makes reference to dynamic behaviors that are out of the scope of the OOXML standard proposal. No application behaviour should be defined
BR10 Part 4, Section 2.16.5.33 te This subclause defines an INCLUDEPICTURE field which “Retrieves the picture contained in the document named”. This does not define how a picture is named. Use the Open Packaging Convention (Part 2 of this specification) nomenclature to define the relationships.
BR11 Part 4, Section 2.16 Page 1487 te All field definitions from section 2.16.5 give no formal definition for what a ‘field value’ might be. Include in lines 17-21 a clear definition for ‘field value’.
BR12 Part 4, Section 2.16.1 Syntax page 1487, line 23 te The general syntax does not mention that some fields (described in section 2.16.5) have specific syntax Explain in the beginning of line 23 that some fields can have specific syntaxes
BR13 Part 4, Section 2.16.1 Syntax page 1489, line 2 te The field argument syntax does not denote that quotes should be used in pairs between text The field argument syntax should be written as: “text” | text
BR14 Part 4, Section 2.16.1 Syntax Page 1489, line 17 te The ‘one or two Latin letters’ sentence does not define clearly define what characters to use The sentence should be written as ‘one or two letters of the Latin alphabet in upper or lower cases.
BR15 Part 4, Section 2.16.4.3 General formatting Page 1501 te The ALPHABETIC switch argument has no documented ST_NumberFormat equivalent. Include the text: “Corresponds to an ST_NumberFormat enumeration value of upperLetter.”
BR16 Part 4, Section 2.16.4.3 General formatting Page 1501 te The alphabetic switch argument has no documented ST_NumberFormat equivalent. Include the text: “Corresponds to an ST_NumberFormat enumeration value of lowerLetter.”
BR17 Part 4, Section 2.16.5.2 ADVANCE page 1509, line 14 te The definition of 'switches' given here contradicts the one given page 1489 lines 3-5. (Zero or more versus one or more.) Make the appropriate corrections
BR18 Part 4, Section 2.16.5.2 ADVANCE page 1510, line 3 te The example is not given in XML Adjust the example, showing it in XML syntax.
BR19 Part 4, Section 2.16.5.12 BIDIOUTLINE page 1518, line 22 te The text ‘A paragraph number’ is dubious. The text should be written as: ‘Numeric value representing the paragraph number’.
BR20 Part 4, Section 2.16.5.24 FILESIZE page 1531, line 27 te The sentence “It needs to be obtained from the file system” denotes an specific application behavior The sentence should be removed
BR21 Part 4, Section 2.16.5.40 LISTNUM page 1544, line 2 te The values given in the table make no sense. Most probably, 'iii' instances stand for 'i' instances. Make the appropriate corrections to the table.
BR22 Part 4, Section 2.16.5.40 LISTNUM page 1543, line 12 and 13 te The definition for 'LISTNUM' is built upon the concepts of 'current' or 'specific' or 'next series', which are not defined in this context. Those concepts should be defined in the text, and their definition should either be copied or referenced in the context of the definition for 'LISTNUM'.
BR23 Part 4, 2.16.5.65 SKIPIF page 1560, line 8 te The field name written in syntax definition is wrong The field name in syntax definition should be written as “SKIPIF”
BR24 Part 4, Section 2.16.5.71 TEMPLATE page 1565, line 4 te The Retrieves verb explicitly references a runtime behavior. The text should be written as: ‘The file name of the template used by the current document.’
BR25 Part 4, Section 2.16.5.71 TEMPLATE page 1565, line 5 te The sentence ‘The disk file name of the template used by the current document’’ explicitly references a runtime behavior. The text should be written as: ‘The file name of the template used by the current document.’
BR26 Part 4, Section 2.18.4 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. The artworks presented should be more precise in terms of definitions (scale, spacing, color, depth)
BR27 Part 4, Section 2.18.45 te Length is said to be “exactly 3 characters”. This is inconsistent with the example given which has a length of 6 characters. This item should be reviewed.
BR28 Part 4 Section 2.18.52 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. The size of this element should be reviewed.
BR29 Part 4, Section 2.18.57 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. This item should be reviewed.
BR30 Part 4 Section 2.18.66 Pg. 1771 te This section lacks normative definitions of the enumeration values mentioned (eg. Korean Chosung Numbering). Make the proper references to the normative definitions of the enumeration values.
BR31 Section 2.18.66 Pg. 1771 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 (e.g. lowerLetter and upperLetter). Define in the specification the method to be used when the letter of the alphabet are exhausted.
BR32 Section 2.18.66 te Format requires use of “dash” to surround the number, but no indication of which Unicode dash is intended. (e.g. en-dash, em-dash, hyphen-minus, figure- dash, quotation-dash, etc). Define the Unicode dash symbol to be used.
BR33 Section 2.18.66 Pg. 1771 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. Change to use a more flexible, extensible, generative approach to numeration, such as that used by the W3C's XSLT specification (RFC's or STD's) in their xsl:number support
BR34 Section 2.18.66 Pg. 1772 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.
BR35 Section 2.18.66 Pg. 1772 te The example given does not show enclosed alphanumeric glyph characters and so contradicts the normative text. Correct the example given, showing the enclosed alphanumeric glyph characters.
BR36 Section 2.18.66 Pg. 1773 te There are several mentions of double-byte and single-byte Arabic numbering schemes. Since the conformance clause for DIS 29500 requires the use of Unicode either UTF8 or UTF16 encodings, there should be no mention of other encodings. Make references according to the conformance clause.
BR37 Part 4, Section 2.18.72 te No definition is provided for a “Panose-1 classification” of a font. Length is said to be “exactly 10 characters”. This is inconsistent with the example given which has a length of 20 characters. This item should be reviewed.
BR38 Part 4, Section 2.18.85 te The fill patterns lack definitions. The illustrations given are insufficient. An application needs to know what in these illustrations are required behaviors and what are not. This element should have more details in order to explain how to implement it.
BR39 Part 4, Section 2.18.86 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. This item should be reviewed.
BR40 Part 4, Section 2.18.106 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. This item should be reviewed.
BR41 Part 4 Section 3.2.29 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. 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. This item should define the encoding, and has to describe how to deal with scripts from different languages such as (but not limited to) Korean or Armenian. This description should be more well explained, and the example should be done in a different way – with independence of machine or OS.
BR42 Section 3.3.1.69 protectedRange Pg. 2003 te No normative description of the password hashing algorithm is provided, only an example is given. The interoperability of this feature cannot be assumed. Provide a normative, cross-platform definition of the hashing algorithm.
BR43 Section 3.3.1.69 protectedRange Pg. 2004 te The securityDescriptor attribute, “defines user accounts who may edit this range without providing a password to access the range”, but no information is given as to what user accounts are referred to here, or what the delimiter is. Substitute “user accounts” with a more generic account (e.g. security account), and define this account, in order to provide cross platform implementation.
BR44 Section 3.13.12 textPr Pg. 2471 te The values for the codePage attribute are presented only as an example list. There is not a normative reference for the valid code pages. Make the proper normative reference to the code pages standard.
BR45 Part 4, Section 3.17.4 Dates and Times page 2522, lines 7 and 8 te The sentence ‘As dates and times are numeric 8 values, they can take part in arithmetic operations.’ might be misleading since arithmetics on dates and times can result ill-formed values The sentence should be removed or be written as: ‘As dates and times are numeric 8 values, they can take part in arithmetic operations. Arithmetic operations on dates and times can result ill-formed values.’
BR46 Section 3.17.4.1 Pg. 2522 te The restriction to only two date bases limits the range of serial dates starting from 01-01-1900, limiting the representation of historical dates. Allow a range of other declared date bases or allow explicitly negative date serial values to express dates prior to 1900.
BR47 Section 3.18.30 ST_FileType pg. 2859 te This element defines values for use on Windows and Macintosh platforms, but not for any other operating systems. Define values to allow cross platform interoperability.
BR48 Part 4, Section 3.18.86 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. This item should be reviewed.
BR49 Part 4, Section 3.18.87 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. This item should be reviewed.
BR50 Part 4, Section 5.1.12.28 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. 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 should be used. This item should be reviewed.
BR51 Part 4, Section 5.1.12.37 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. No font distance metric or font matching heuristic is described. This item should be reviewed.
BR52 Part 4, Section 5.1.3.2 te No mention is made of what audio formats or codecs are permitted. This item should be reviewed considering interoperability and flexibility.
BR53 Part 4, Section 5.1.3.4 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. This item should describe the supported codecs and version of the Quicktime.
BR54 Part 4, 6.1.2.1 arc page 4352 te The description of the 'dgmlayout' attribute states that 'The possible values for this attribute are defined by the XML Schema integer datatype', while the preceding description only assigns meanings to the 0, 1, 2 and 3 values. Make the proper change
BR55 Part 4 Section 6.1.2.19 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. This element attribute should be clearly defined or removed from this document.
BR56 Part 4 Section 6.1.2.19 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. This element attribute should be clearly defined or removed from this document.
BR57 Part 4 Section 6.2.2.14 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. This element attribute should be clearly defined or removed from this document.
BR58 Part 4 Section 6.4.3.1 and 6.4.2.10 Pg. 4955 Pg. 4927 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. Allow full cross platform interoperability to formats that are used by other operating systems (e.g. PNG, OGG, etc.).
BR59 Part 4 Section 7.4.2.4 Pg. 5122 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 states “Control codes should be replaced with appropriate markup.”. The bstr type should be revised and the control codes that demands this data type should be properly converted to XML, based on the OPC-Open Package Convention specification.
BR60 Part 4 Section 7.4.2.5 Pg. 5122 te This element defines values for use on Windows and Macintosh platforms, but not for any other operating systems. Define values to allow cross platform interoperability.
BR61 Section 7.4.2.5 Pg. 5122 te There is not enough information given to achieve interoperability (e.g. the allowed values and meanings for a “built-in Windows clipboard format value” are not presented). Clarify the meanings and values of the terms used.
BR62 Section 7.4.2.5 Pg. 5122 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 GUID and FMTID.
BR63 Section 7.4.2.5 stringsAsNull Pg. 5122 te The usage of null-terminated C- style strings is avoiding XML and will cause the markup to interoperate poorly with XML-based tools. Rewrite the clause to express this feature in an application and platform independent way.
BR64 Section 2.15.3 Pg. 1368 te The “Compatibility Settings” are not available to understand how the document is rendered. The references in the “Compatibility Settings” section should be made to full publicly available information.