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

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.

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.

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.

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.