Template for comments and secretariat observations | Date: 28-08-2007 | Document: DIS 29500 |
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 |
IR | Part 4, 3.17.4.1 | te | The date system specified does not support dates earlier than 1900. | Allow negative “serial values” for dates and provide mechanisms to support dates, either based on the historical Gregorian/Julian calendar or the ISO date system that extends the present Gregorian leap year calculation into the past. | ||
IR | Part 4, 3.17.4.1 | te | The date system handles the leap year status of the year 1900 incorrectly, requiring both vendor applications (like an office suite) and user applications (like a single spreadsheet) having difficulty in several date calculations. | Either remove the legacy feature, or only allow it as an extension, called “consider1900leap” for example, which is turned off be default. | ||
IR | Part 4, 3.17.7.341 | te | The described function (WEEKDAY) does not support weeks starting with Saturday, common in various Muslim countries including Iran. | Extend the function so that it includes a value for “weekday-start-flag” that relates to a weekday numbering convention that starts with Saturday. | ||
IR | Part 4, 3.17.7.342 | te | The described function (WEEKNUM) does not support weeks starting with Saturday, common in various Muslim countries including Iran. | Extend the function so that it includes a value for “weekday-start-flag” that counts weeks that start with Saturday. | ||
IR | Part 4, 3.17.7.342 | te | The described function (WEEKNUM) does not support the Persian calendar, which is main official calendar in Iran and Afghanistan. | Extend the function so that it supports the Persian calendar. | ||
IR | Part 1, 15.2.14 |
te | This section refers to DEVMODE structure which is specific to the Microsoft Windows operating system. Saving and restoring of printer settings on non-Microsoft operating systems is made hard this way. Also, there is the security concerns regarding the memory dump written to disk which is proposed by this specification. | There is another specification by Microsoft which is for expressing printer setting in XML:PrintTicket mark-up. It can be used in place of binary storage of the printer setting in an XML-based open format. | ||
IR | Part 4, Introduction |
Page vii, line 7 |
te | OOXML being "fully compatible" with any existing application is undeniably unreachable. | The phrase about the compatibility issues should be rephrased to be realistic. | |
IR | Part 4, Section 2 |
te | Improving the interoperability between OOXML and ODF is desired, but ODF has the following feature which is lacking in OOXML: positioning the image absolutely within a frame. | In order to improve the interoperability between OOXML and ODF, support for this feature should be included in WordProccessingML. | ||
IR | Part 4, Section 2 |
te | Improving the interoperability between OOXML and ODF is desired, but ODF has the following feature which is lacking in OOXML: any number of rows can be selected for repeating Heading | In order to improve the interoperability between OOXML and ODF, support for this feature should be included in WordProccessingML. | ||
IR | Part 4, Section 2 |
te | Improving the interoperability between OOXML and ODF is desired, but ODF has the following feature which is lacking in OOXML: evenly distribution of contents in multi-column section which results in balanced columns | In order to improve the interoperability between OOXML and ODF, support for this feature should be included in WordProccessingML. | ||
IR | Part 4, Section 2 |
te | Improving the interoperability between OOXML and ODF is desired, but ODF has the following feature which is lacking in OOXML: setting 'keep with next paragraph' for tables is possible | In order to improve the interoperability between OOXML and ODF, support for this feature should be included in WordProccessingML. | ||
IR | Part 4, Section 2.15.1.28 |
te | The has algorithm specified in this section is known to be weak for usage in OOXML documents. A stronger algorithm - like SHA2 - can be used. | A standard hash algorithm (for example a FIPS-180 compliant algorithm) can be used as the default. | ||
IR | Part 4, Section 2.15.1.28 |
te | There is not information about the encoding of passwords in the specification in this section. Although, it is most likely supposed to be Unicode encoding, but no details are available about this so for example the byte ordering is not defined. | The exact encoding detail and byte ordering should be available for entering the password and calculating the hash. | ||
IR | Part 4, Section 2.15.1.28 |
te | The hashing algorithm operation is depending on byte order of the machine and the way values are treated as signed or unsigned. | Expand the description of the algorithm to cover byte order and signedness so the description can be platform independent. | ||
IR | Part 4, Section 2.15.1.86 |
te | The configuration of this style display filter is done using bit masks rather than a set boolean types. According to this, XSLT processing is impossible. | Change the sub clause to use boolean XML declaration. | ||
IR | Part 4, Section 2.15.1.87 |
te | The configuration of this style display sorting is done using bit masks rather than a set boolean types. According to this, XSLT processing is impossible. | Change the sub clause to use boolean XML declaration. | ||
IR | Part 4, Section 2.15.2.32 |
te | The definition for this feature is only supported by the Internet Explorer and other browsers are ignored. Because the specification requests that all the browser incompatible settings be disabled, use of open formats (such as PNG, SVG, MathML, etc) would be impossible. | It is unsuitable in this form, to optimize only for a single browser as it force the end user about his/her choice of browser. This concept should be redraft in a way that it can be platform neutral. | ||
IR | Part 4, Section 2.15.3.26 |
te | No description of the specific behaviour is given for "footnoteLayoutLikeWW8" element, although it is supposed to reproduce behaviour of a prior version of Microsoft Word. | The definition of the behaviour should be given. | ||
IR | Part 4, Section 2.15.3.31 |
No description of the specific behaviour is given for "lineWrapLikeWord6" element, although it is supposed to reproduce behaviour of a prior version of Microsoft Word. | The definition of the behaviour should be given. | |||
IR | Part 4, Section 2.15.3.32 |
te | No description of the specific behaviour is given for "mwSmallCaps" element, although it is supposed to reproduce behaviour of a prior version of Microsoft Word. | The definition of the behaviour should be given. | ||
IR | Part 4, Section 2.15.3.41 |
te | No description of the specific behaviour is given for "shapeLayoutLikeWW8" element, although it is supposed to reproduce behaviour of a prior version of Microsoft Word. | The definition of the behaviour should be given. | ||
IR | Part 4, Section 2.15.3.51 |
te | No description of the specific behaviour is given for "supressTopSpacingWP" element, although it is supposed to reproduce behaviour of a prior version of Microsoft Word. | The definition of the behaviour should be given. | ||
IR | Part 4, Section 2.15.3.54 |
te | No description of the specific behaviour is given for "uiCompat97To2003" element, although it is supposed to "Disable UI functionalities that is not compatible with Word 97-2003" | The definition of the element should be application neutral. Removal from the standard may be needed in case this element is exclusively specific to Microsoft Word. | ||
IR | Part 4, Section 2.15.3.54 |
te | No description of the specific behaviour is given for "truncateFontHeightsLikeWP6" element, although it is supposed to reproduce behaviour of a prior version of Microsoft Word. | The definition of the behaviour should be given. | ||
IR | Part 4, Section 2.15.3.6 |
te | No description of the specific behaviour is given for "autospaceLikeWord95" element, although it is supposed to reproduce behaviour of a prior version of Microsoft Word. | The definition of the behaviour should be given. | ||
IR | Part 4, Section 2.15.3.63 |
te | No description of the specific behaviour is given for "useWord2002TableStyleRules" element, although it is supposed to reproduce behaviour of a prior version of Microsoft Word. | The definition of the behaviour should be given. | ||
IR | Part 4, Section 2.15.3.64 |
te | No description of the specific behaviour is given for "useWord97LineBreakRules" element, although it is supposed to reproduce behaviour of a prior version of Microsoft Word. | The definition of the behaviour should be given. | ||
IR | Part 4, Section 2.15.3.65 |
te | No description of the specific behaviour is given for "wpJustification" element, although it is supposed to reproduce behaviour of a prior version of Microsoft Word. | The definition of the behaviour should be given. | ||
IR | Part 4, Section 2.15.3.66 |
te | No description of the specific behaviour is given for "wpSpaceWidth" element, although it is supposed to reproduce behaviour of a prior version of Microsoft Word. | The definition of the behaviour should be given. | ||
IR | Part 4, Section 2.16.5.33 |
te | The naming rules for an image file is not described clearly in this section. Using a MS-DOS file path in the example contributes to inexactness of this section. | The naming schemes for pictures should be defined clearly. | ||
IR | Part 4, Section 2.16.5.34 |
te | The naming rules for a document file is not described clearly in this section. Using a MS-DOS file path in the example contributes to inexactness of this section. | The naming schemes for documents should be defined clearly. | ||
IR | Part 4, Section 2.18.4 |
te | This section shows an example diagram in a very poor image quality instead of defining the diagram that can be produced. | Full normative definitions should be provided for the diagram formats. The example diagrams should be in a scalable graphic format such as SVG. | ||
IR | Part 4, Section 2.18.45 |
te | The mechanism for extending the set of art borders is not defined. | An interface or extension mechanism should be provided for authors and application developers to specify their own art borders. | ||
IR | Part 4, Section 2.18.45 |
ge | The majority of presented art borders have very western oriented patterns. | Include art borders with patterns obtained from a reasonable variety of cultures. | ||
IR | Part 4, Section 2.18.66 |
te | The numeration format described in this section is a closed solution so it excludes support for other numerations which are in used today, such as a sequence consisted of Persian alphabet, etc. | A more flexible approach should be used. For example xsl:number in the W3C XSLT standard can be used instead. | ||
IR | Part 4, Section 2.18.72 |
te | A reference to a "Panose-1 classification" is mentioned in this section but such classification is not provided. Also, there is are no references given. | |||
IR | Part 4, Section 2.3.1.8 |
te | In this section, bit masks are used in the conditional formatting of this paragraph. According to this, XSLT processing is impossible. | Change the sub clause to use boolean XML declaration. | ||
IR | Part 4, Section 2.4.51 |
te | In this section, bit masks are used in the formatting properties of table styles. According to this, XSLT processing is impossible. | Change the sub clause to use boolean XML declaration. | ||
IR | Part 4, Section 2.4.52 |
te | In this section, bit masks are used in the formatting exceptions of table styles. According to this, XSLT processing is impossible. | Change the sub clause to use boolean XML declaration. | ||
IR | Part 4, Section 2.4.7 |
te | In this section, bit masks are used in the configuration of table cell formatting rules. According to this, XSLT processing is impossible. | Change the sub clause to use boolean XML declaration. | ||
IR | Part 4. Section 2.4.8 |
te | In this section, bit masks are used in the configuration of table row formatting rules. According to this, XSLT processing is impossible. | Change the sub clause to use boolean XML declaration. | ||
IR | Part 4, Section 2.8.2.16 |
te | In this section, bit masks are used in the configuration of code page support flags. According to this, XSLT processing is impossible. | Change the sub clause to use boolean XML declaration. | ||
IR | Part 4, Section 3.17.4.1 |
te | The upper limit for serial date is described as 9999-12-31 00:00:00, while the excepted limit is 9999-12-31 23:59:59 | The upper limit should be clarified. | ||
IR | Part 4, Section 3.17.4.2 |
te | The time stamp format proposed here does not include time zone and daylight saving time. So it can be ambiguous and may cause interoperability problems between different time zones. | A notion of time zone and daylight saving can be added or the current time can be calculated from UTC internally and stored as UTC time stamps in the serialized form. | ||
IR | Part 4, Section 3.17.4.3 |
te | The “combined date and time representation” proposed here does not include time zone and daylight saving time. So it can be ambiguous and may cause interoperability problems between different time zones. | A notion of time zone and daylight saving can be added or the “combined date and time representation” can be calculated from UTC internally and stored as UTC time stamps in the serialized form. | ||
IR | Part 4, Section 3.2.29 |
te | No exact definition is provided for the password hashing algorithm. Because of this reason, interoperability is not possible on this feature. The definition is not normative as the example algorithm is machine-dependant. | A normative hashing algorithm or a normative reference to one should be provided. | ||
IR | Part 4, Section 3.2.29 |
te | When a script does not consist of western characters and a password is entered to it, the password will be replaced by a single byte containing 0x3F. In this case, the password protection would be useless. | The algorithm should be refactored so it supports Unicode passwords. | ||
IR | Part 4, Section 3.2.29 |
te | There is not information about the encoding of passwords in the specification in this section. Although, it is most likely supposed to be Unicode encoding, but no details are available about this so for example the byte ordering is not defined. | The exact encoding detail and byte ordering should be available for entering the password and calculating the hash. | ||
IR | Part 4, Section 5.1.12.37 |
ge | Two definition for Panose value - one according to Word Processing ML module and the other according to Drawing ML module - are provided. Both of them are actually identical. | One single definition should be provided. | ||
IR | Part 4, Section 6.1 |
ge | The phrase "millions of documents" in this section is an unsupported assertion and also irrelevant in the context of a standard proposal. | Remove the assertion. | ||
IR | Part 4, Section 6.4.2.10 |
te | Though the element is defined as "general-use element for objects that use an image representation, such as OLE objects, embedded controls, cameras and signature lines", none of the referred formats (EMF, WMF, etc.) are defined or referred to in this specification. | A proper external normative references for the allowed formats containable within this element should be provided. | ||
IR | Part 4, Section 6.4.3.1 |
te | Windows specific formats are used in the permitted values of this enumeration. The use of this enumeration is restricted to Windows operating system users. | The free PNG format is used to interchange between applications and the clipboard in the Free Desktop Specification implemented by the majority of Open Source based operating systems. Use of freely available formats should be available for use as values in this enumeration. | ||
IR | Part 4, Section 7.4.2.5 |
te | While strings are represented as a NULL terminated character sequence with base-64 encoding, documents consisted of such strings can not be easily convertible using XSLT style sheets. This representation is designed around the specific implementation of one ECMA member. | XML offers some kind of interoperability. The representation of data in the clipboard should be redesigned with that approach to interoperability in mind. | ||
IR | Part 4, Section 7.4.2.5 |
te | The values defined for elements is for use on Windows or Mac OS platforms and they are not usable for Linux or any other operating system. | The cross-platform interoperability should be allowed. | ||
IR | Throughout |
te | The name for the standard – "Office Open XML" – is often confused with with "Open Office" and results to user confusion. | The ECMA should consider a different name which is less easily confused with the name another product. | ||
IR | Throughout | ge | As it is expected for standards to be as such, the specification was not the result of a consensus achieving process of the knowledge and experiences of producers, consumers, and regulators. It is based on the single idea of one entity which is Microsoft. | The standard should be redrafted as a public hearing model. | ||
IR | Throughout | ge | Although Microsoft has promised not to sue those who implement the specification over patents, but still a large fraction of it is covered by patents owned by Microsoft and this corporation has not done anything to make them legally invalid for Open Source use. So according to law, the trustworthiness of the promise is unclear. | Microsoft should be required to gives Open Source and others who implement the specification the irrevocable right to implement the OOXML specification. Also, Microsoft can publish an implementation of code with patents, or even their entire OOXML implementation, under a free reusable license such as Lesser GPL (LGPL). | ||
IR | Throughout | ge | Because a large fraction of the specification is covered with patents owned by Microsoft, implementation of that by the independent Iranian software vendors may be impossible. This is because of unilateral trade sanctions against Iranian persons and companies by the United States makes such agreements very hard to achieve, even if Microsoft is interested in such patent grants. | Microsoft should be required to gives Open Source and others who implement the specification the irrevocable right to implement the OOXML specification. Also, Microsoft can publish an implementation of code with patents, or even their entire OOXML implementation, under a free reusable license such as Lesser GPL (LGPL). |
1 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
|
![]() |
|