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

BR 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.  
BR 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)

 
BR 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’.  
BR 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.  
BR 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.  
BR 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.)  
BR 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.  
BR 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.  
BR 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  
BR 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.  
BR 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’.  
BR 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  
BR 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  
BR 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.  
BR 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.”  
BR 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.”  
BR 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  
BR 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.  
BR 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’.  
BR 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  
BR 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.  
BR 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'.  
BR 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”  
BR 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.’  
BR 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.’  
BR 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)  
BR 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.  
BR 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.  
BR 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.  
BR 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.  
BR 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.  
BR 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.  
BR 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  
BR 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.      
BR 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.  
BR 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.  
BR 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.  
BR 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.  
BR 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.  
BR 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.  
BR 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.

 
BR 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.   
BR 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.  
BR 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.  
BR 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.’  
BR 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.  
BR 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.  
BR 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.  
BR 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.  
BR 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.  
BR 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.  
BR 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.  
BR 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.  
BR 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  
BR 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.  
BR 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.  
BR 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.  
BR 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.).  
BR 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.  
BR 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.  
BR 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.  
BR 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.  
BR 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.   
BR 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.  
 

Note: Under the statement of ISO/IEC JTC 1 Rules, Clause 9, item 9.8, Brazil is submitting its vote of disapproval under the conditional criteria that, in case of acceptance of the proposed, the vote automatically changes to approval. 

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

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

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

page of 11

ISO electronic balloting commenting template/version 2001-10


Top