COMMENTS FROM KENYA BUREAU OF STANDARDS (KEBS) 
 

Project Number: DIS 29500: Information technology — Office Open XML file formats 

Date Document
2007-08-28 DIS 29500
 
National Committee Clause Paragraph/ Figure/Table Type of comment (General/Technical /Editorial) COMMENTS Proposed Change OBSERVATIONS OF THE SECRETARIAT
Office Open XML Overview   ge The document does not indicate whether the zip files are normative or informative Either have an index of zip files that will describe the contents and whether the zip file is informative or normative or each zip file should contain a comment line indicating whether it is normative or informative  
Part 1, Annex A   te The reference given for the Zip format does not provide a date or version, though this specification is frequently revised. Reference should be made to a particular dated and/or labelled version.  
Part 1, Foreword   ed DIS 29500 is a multi-part document, not a multi-part Standard, i.e., the individual parts of this Standard are not themselves standards. Correct the terminology to correctly reflect the status of DIS 29500.  
Part 1, Section 11.3.1 lines 15-17 ed This is requiring that a conforming OOXML consumer also be able to understand a specified list of other document formats, including proprietary ones such as MHTML and RTF, and for conforming producers to understand how to convert these formats to OOXML. Make it clear that the consumer does not need to know these formats  
Part 1, Section 15.2.15   ed For there to be interoperability of this feature, it must either specify what size the thumbnail should be or state that the application will scale the image as needed. Clarify what size the thumbnails should be, or that the images are scaled.  
Part 1, Section 15.2.6   ed What is meant by “This part shall have no contents”?  Does this mean that there shall be nothing in the Zip file with the declared name?  Or does it mean that a zero-byte file shall be created with the declared name?  Or something else? The phrase "This part shall have no contents" means that a part shall be created, but it shall have no contents (meaning it would be a zero byte file).  
Part 1, Section 15.2.8   ed The examples given are rendered useless by the predominance of the VML in the markup. Make a more succinct and clear example by concentrating on the control persistence.  
Part 1, Section 2.1 “Goal”   ge There are no normative statements in this clause, though Section 2 is indicated to be normative Mark clause as informative using one of the mechanisms of Section 7  
Part 1, Section 2.2 “Issues”   ge There are no normative statements in this clause, though Section 2 is indicated to be normative Mark clause as informative using one of the mechanisms of Section 7  
Part 1, Section 2.3 Line 14 ed Are additional syntactic constraints only normative when the cannot be feasibly expressed in the schema language? Who judges this?  The use of the word “whenever” is ambiguous.  Is this a condition under which such statements are normative or an explanation of why such statements exist? The section 2.3: "What this standard specifies", line 14 specifies that if the schema language used in this standard cannot feasibly express all the syntactic constraints, then those constraints are provided in written form. Such expressions are normative. The application that implements this standard will judge if the additional syntactic constraints are normative or not. The editorial comment which explains why this statement is appropriate is useful to the reader and does not detract from the value of this statement.  
Part 1, Section 2.3 Line 16 ed The use of the word “element” is ambiguous.  Is this to mean XML elements (but not attributes, character content, etc.)?  Or does this mean an element of the Standard, in the usage of ISO Directives, Part 2? Clarify the use of the word “element” perhaps by saying “XML element” if  that is what is meant.  
Part 1, Section 2.4 Line 22 ed This line require conformance with “Unicode Standard” without specifying a version.  XML 1.0 referred to Unicode 2.0, though the informative Appendix A of OOXML Part 1 lists Unicode 4.0.  Which is it? Unicode should be referenced consistently throughout the document  
Part 1, Section 2.6   ed The use of the word “element” is ambiguous.  Is this to mean XML elements (but not attributes, character content, etc.)?  Or does this mean an element of the Standard, in the usage of ISO Directives, Part 2? Clarify the use of the word “element” perhaps by saying “XML element” if  that is what is meant.  
Part 1, Section 2.6 Line 15 ed Obviously the Standard anticipates such behavior since it explicitly contains the present example describing this behavior and calls it conforming. Perhaps it is meant to say, “...this Standard does not recommend this behavior”.  
Part 1, Section 2.6 Lines 33-34 ed Is this recommending that a non-public, internal-only, work-for-hire application author create “publicly available documentation” on what subset of the standard it supports? The business relationship between the software author and his customer should not be a concern of this standard. Change to read, “a software application should be accompanied by  documentation...”  
Part 1, Section 9.1.1   ed ASCII requires a normative reference since there are several national variations. Suggest reference be made to a standard e.g. ISO/IEC 646:1983 to avoid ambiguity  
Part 1, Section 9.1.5   ed This sub-clause, buried in introductory material, negates a provision of the more detailed OPC specification in Part 2.  This will likely be missed by implementors. If interleaving is not permitted then it should not be described in Part 2.  
Part 2, Section 3 Page 4, line 20 ed This definition of 'package model' is not compatible with the prior definition given in Part 2, Section 1. Scope, page 1, line 5. Define 'package model' in unambiguous terms and use the resulting definition consistently throughout the OOXML text.  
Part 4, Introduction Page vii, line 8 ed An XML markup cannot be “fully compatible” with an “investment” Remove the word “investment”  
Part 4, Section 2.15.1.28   ed This says that document protection “shall be enforced”.  “Shall” indicates required behavior.  But then a few sentences later it says that document protection “may be ignored”.  This protection is not intended as a security feature and may be ignored.”   From the above paragraph, we understand that the context in which the phrase “shall be enforced” is used, then it means that if the attribute is turned on, then the restrictions will be imposed.   The context in which the phrase “may be ignored” is used, then it means that the protection does not encrypt the document, malicious applications may circumvent its use and so this can be ignored as a security feature.    The two phrases mentioned are used in two different contexts and are appropriated in their respective context.

This information should be marked as informative

 
Part 4, Section 2.15.1.28 Line 16 ed What if the entered password is shorter than 15 characters?  Do we truncate to the actual length?  Or fill with 0's? Or something else? Clarify this processing step.  
Part 4, Section 2.15.1.28 pg 1159, lines 6-9 ed The described processing steps are not ambiguous.  In particular SHR and SHL give different results on different machines and with signed and unsigned values Describe the hash algorithm in a platform independent manner.  
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.  What about Firefox?  What about Safari?  What about Opera? None of these can be set as target browsers.  This section requires that “all settings which are not compatible with the target web browser shall be disabled.”  But what if I want my application to produce standards-compliant output?  So yes to PNG, no to VML, yes to MathML and SVG?   I can't seem to specify this. Provide definitions of each of the elements, make the current table an example (not part of the definition). Give examples of other current browsers.  
Part 4, Section 2.15.3 Entire clause te These “compatibility” settings solve no general problem.  They are merely a museum of settings from previous versions of Microsoft Word.  No allowance has been made for legacy settings from other applications.  Better to have these be application-specific settings using the existing extensibility mechanisms of OOXML. It is proposed to move the whole of this clause to an informative annex. Each feature should either be documented or referenced for proper implementation. Other manufacturers should be allowed to add their own compatibility issues to this proposed annex.  
Part 4, Section 2.16.4.3 page 1501, line 0 te The definition for BATHTEXT references 'the given Thai format', which makes no sense in the context of that definition.  What “given Thai format”? The switch argument is used for number formatting.The definition completely makes sense,which means that the switch argument formats the number in 'Thai' format.Hence 'thaiCounting' is its ST_NumberFormat equivalent,as in the section 2.18.66,Page Number 1777.Since the fields require both text and numeric formatting ,a switch argument is provided in context of the fields so that data formatting becomes more developer friendly.  
Part 4, Section 2.16.5.33   te This does not define how a picture is named.  Is it by a URI?  By a local file system path?  Either?    The example given has a DOS file path, a construct which is not portable. Define the syntax for the field value  
Part 4, Section 2.16.5.34   te This does not define how a document  is named. Is it by a URI?  By a local file system path?  Either?  The example given has a DOS file path, a construct which is not portable. Define how documents are named.  
Part 4, Section 2.16.5.34   ed The \t flag will apply a named XSLT transform to the input XML file and insert the resulting output.  However, no proper reference is given to XSLT, so we do not know what version XSLT transform is permitted here. Text to be clarified  
Part 4, Section 2.16.5.40   ed The definition for 'LISTNUM' is built upon the concepts of 'current' or 'specific' or 'next series', which are not defined in this context (a backward search on 'series' shades no light on this). 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'. Expand or reference the definition for 'series', and/or clarify the definition for 'LISTNUM' by any appropriate means.  
Part 4, Section 2.16.5.5 page 1512, lines 11-12 te According to the text, the AUTONUM field is deprecated. A new standard should not contain deprecated parts. More information supporting the use of AUTONUM is required  
Part 4, Section 2.16.5.77   ed The example that illustrates USERINITIALS section instead shoes  USERNAME. Correct the example..  
Part 4, Section 2.18.106   ed 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. Look through the document and make sure the reference is consistent  
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.  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 graphic elements as a separate collection e.g. zipped  
Part 4, Section 2.18.4   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.  
Part 4, Section 2.18.45   ed Length is said to be “exactly 3 characters”.  This is inconsistent with the example given which has a length of 6 characters. Look through the document and make sure the use is consistent  
Part 4, Section 2.18.51   te The use of 255 enumerated language codes, in addition to ISO 639-1 codes, adds no expressive value and only increases the work required of any application that would process an OOXML document. Drop the use of the redundant ST_LangCode  
Part 4, Section 2.18.52   ed This type is defined as containing, “a two digit hexadecimal language code”.  It is fruther stated that, “This simple type's contents must have a length of exactly 2 characters”.  However, two hex digits can count up to 255 and the values enumerated in this clause go far beyond that. Look through the document and make sure the use is consistent  
Part 4, Section 2.18.57   ed 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. Look through the document and make sure the use is consistent  
Part 4, Section 2.18.66   ed 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? More clarification required  
Part 4, Section 2.18.66 “chicago” ed 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.  
Part 4, Section 2.18.66 “decimalEnclosedFullstop” ed The example given does not show enclosed characters and so contradicts the normative text. Reconcile the text and the example.  
Part 4, Section 2.18.66 “lowerLetter”, etc. ed 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.  
Part 4, Section 2.18.66 “numberInDash”, etc. ed 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.  
Part 4, Section 2.18.72   ed Length is said to be “exactly 10 characters”.  This is inconsistent with the example given which has a length of 20 characters. Look through the document and make sure the use is consistent  
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.  For example, is the exact dithering pattern used in the illustration required?  Graphics to be included in a separate collection e.g. zipped  
Part 4, Section 2.18.86   ed 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. Look through the document and make sure the use is consistent  
Part 4, Section 2.2.1 page 28, line 0 te The reference to the urn:schemas-microsoft-com:vml namespace references VML, which is considered as deprecated (Part 4, page 4343, lines 11&12). A new standard should not contain deprecated parts. Move all references to VML to an informative annex. We strongly advise that DrawingML replaces all functionalities of VML and VML be eliminated from the specification.  
Part 4, Section 2.2.1 page 28, line 0 te Child elements of background are described using deprecated features only. Accordingly, the background element should either be described in terms of current OOXML elements or deprecated. If the element of background is to be part of the spec. then it should be defined in terms other than VML. Otherwise it should appear as a deprecated element in the informative annex and the above comment applies.  
Part 4, Section 2.2.1 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.' The attribute value 'auto' is to distinguish one entity from another in situation where both cannot be distinguished, which is mentioned in the Section 2.1.3.4,page 39,line 6,7,8 definition for the attribute 'color' . Hence "appropriate" here means that the entity ,whose value is set as auto, immediately uses the default color, distinguishing it from other entity. This should be made clear in the standard.  
Part 4, Section 2.2.1 page 29, line 0 te There are several instances of the word 'border' that are meaningless in this context (the text is supposed to describe the 'background' element at that location and no “border” has been defined). There are a few typos where the word "border" is used instead of "background". This needs to be addressed.  
Part 4, Section 2.2.1 background (Document Background) page 27, lines 1&2 te Assuming that background be referring to the background of the document defined by one of its enclosing elements, assuming that the notion of document page and the notion of displaying be properly defined and that their definitions match commonly accepted ones, then the 'This background shall be displayed on all pages of the document, behind all other document content.' sentence makes unclear whether the total surface of a page must be filled with the background, or else how the subpart of the said surface can be determined. Clarify the meaning of background in this case. Does it refer to the document or the frame as referenced in other parts of this sections  
Part 4, Section 2.2.1 background (Document Background) page 27, lines 8&21 ed Contradicting use of accent3 and accent5 – the text says one thing, but the example says another. Fix the typing error  
Part 4, Section 2.3.3.19   te This says that “The layout properties of this embedded object are specified using the VML syntax”.  However, in Part 1, Section 8.2.6 says, “VML should be considered a deprecated format included in Office Open XML for legacy reasons only and new

9 applications that need a file format for drawings are strongly encouraged to use preferentially DrawingML”   Certainly a new document creating an OLE embedding should not be using VML.  Otherwise, all OOXML consumers will need to support VML, even where legacy documents are not present.

If the element of background is to be part of the spec. then it should be defined int terms other than VML. Otherwise it should appear as a deprecated element in the informative annex and the previous comment applies.  
Part 4, Section 3.17.4.1   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. Explicitly allow negative date serial values to express dates prior to 1900  
Part 4, Section 3.17.4.1   te The mandated incorrect date calculations for 1900 in the 1900-based date basis is unacceptable.  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. In the specification there should be only one date base (1904). A tag for backward compatibility could be added as part of the compatibility settings annex to treat dates where 1900 was wrongly considered to be a leap year. The standard could include a reference to this compatibility setting.  
Part 4, Section 3.18.86   ed 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. Look through the document and make sure the reference is consistent  
Part 4, Section 3.18.87   ed 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. Look through the document and make sure the reference is consistent  
Part 4, Section 3.3.1.61   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. Provide for a user defined paper size  
Part 4, Section 3.3.1.69   ed 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. The normative description of the hashing algorithm used by OOXML, along with the flowchart is defined in section 2.15.1.28 and therefore section 3.3.1.69 should cross-reference section 2.15.1.28.  
Part 4, Section 3.3.1.69   te The securityDescriptor attribute, “defines user accounts who may edit this range without providing a password to access the range”.  It is a string.  But no information is given as to what user accounts are referred to here, or what the delimiter is.  Are these comma-delimited local machine user accounts?  Or semi-colon delimited LDAP DN's?  There will be no interoperability if this is not defined. Fully define this attribute.  
Part 4, Section 5.1.12.28   ed 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. Look through the document and make sure the reference is consistent  
Part 4, Section 5.1.12.37   ed Length is said to be “exactly 10 characters”.  This is inconsistent with the schema fragment given which defines it as being 10 octets long. Look through the document and make sure the reference is consistent  
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. Provide an external reference for the version(s) of QuickTime format intended here as well as an interoperable codec.  
Part 4, Section 6. Entire clause (pages 4343-4960) te All subsections of Section 6 describe deprecated only material, making Section 6 deprecated as a whole. A new standard should not contain deprecated parts. Move whole section to an informative annex. We strongly advise that DrawingML replaces all functionalities of VML and VML be eliminated from the specification.  
Part 4, Section 7.4.2.4   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.  
Part 4, Section 7.4.2.5   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. Eliminate the requirement for null-termination of strings.  
Part 4, Section 7.4.2.5   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. Reference the GUID specification  
Part 4, Section 7.4.2.5   te This element defines values for use on Windows and Macintosh platforms, but not for Linux or any other operating system. Include other values for known formats that will allow cross platform interoperability  
Part 4, Section 7.4.2.5   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”? Windows and Macintosh clipboard formats should be made publicly available. The std should include a reference to these documents. This comment would also extend to other formats included as a result of the previous comment.  
Throughout   ge The name "Office Open XML" is often mistakenly  called 'Open Office XML” implying a connection to the OpenOffice project which does not exist.  This naming confusion has been documented and has occurred numerous times, including by analysts and even in Microsoft press releases and blogs.  Since “Open Office” is the pre-existing name, by 6 years, Ecma should choose a new name, less apt to continue this confusion. We suggest that the name Office Open XML be changed  
Part 1 Page xii Lines 5 - 8 ge The statement reads: The goal is to enable the implementation of the Office Open XML formats by the widest set of tools and platforms, fostering interoperability across office productivity applications and line-of-business systems, as well as to support and strengthen document archival and preservation, all in a way that is fully compatible with the large existing investments in Microsoft Office documents. The goal should not be to protect only Microsoft Documents but also other legacy documents that we have in existent e.g WordPerfect documents.  
2.4.46   te OOXML lacks the ability to specify a multi-row header that repeats across pages Include in this section the ability to select the first N rows as a header.  
11.6   ge It is not clear how the styles and formatting will be handled in the case of master documents and subdocuments. If the master document has been formatted bold, and the subdocuments have not, which will have precedence over the other? The document should outline clearly which takes precedence over the other  
    ge Microsoft has given an “Open Specification Promise”,4 promising not to sue third parties that use the Ecma specification for patent infringement. However, there are several issues with this promise: 

The promise only relates to “Microsoft Necessary Claims”, which are “[t]hose claims of Microsoft- owned or Microsoft-controlled patents that are necessary to implement only the required portions of the Covered Specification that are described in detail and not merely referenced in such Specification.”

The Open Specification Promise should extend not only to the required parts in the std but also to allow a complete implementation of the std including non-mandatory specifications and backward compatibility tags.  
      The promise does not relate to copyrights but only to patents and leaves significant scope for legal uncertainty for third party developers. The Open Specification Promise should be extended to cover copyrights.  
Part 1, Section 4 behavior, unspecified ed This definition doesn't work, since the Standard, in defining compliance in Section 2, says that “compliance is purely syntactic”.  So no behaviors are required.  Therefore, by this definition, all behaviors are unspecified?  Surely this is not what is meant. Clarify this definition.  Perhaps it is meant to say, “Behavior for which this Standard does not make a recommendation”?  
Part 1, Section 4 Office Open XML Document ed This definition doesn't hold together.  Are these two different definitions? Or two clause of which either will define the term?  Or both together define the term? Clarify the definition  
Part 1, Section 9.1.7 line 10 ed The naming convention giving is incorrect.  H is a hexadecimal digit, not a hexadecimal value. Follow correct usage pattern as established earlier in 9.1.1.  
Part 1, Section 9.1.9 line 25 ed Incorrect subject.  A producer qua producer does not round trip. Should say, “Conforming producers that are also consumers should...”  
Part 1, Section 9.2 page 18, line 8 ed Extra period following “explicit.” Remove extraneous punctuation  
Part 2   ge Part 2 defines Open Packaging Conventions (OPC) in terms that, according to Part 1, Section 9.1 Constraints on Office Open XML's Use of OPC, are more general than needed for the purpose of OOXML. This is due to bring confusion, and should be resolved. Part 2 should be amended either by tightening Part 2 contents so as to keep it focused on OOXML related matters  
Top