Template for comments and secretariat observations | Date: 2007-08-31 | Document: ISO/IEC 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 |
UY | Section 2.15.3 | te | Several sections require the
developer to reproduce the behaviour of a propietary product, where the
behaviour to be reproduced is not specified.
Examples: * 2.15.3.6 section page 2161, autoSpaceLikeWord95. * 2.15.3.26 section page 2199, footnoteLayoutLikeWW8. * 2.15.3.31 section page 2209, lineWrapLikeWord6. * 2.15.3.32 section page 2210, mwSmallCaps. * 2.15.3.41 section page 2225, shapeLayoutLikeWW8. * 2.15.3.51 section page 2245, suppressTopSpacingWP. * 2.15.3.53 section page 2250, truncateFontHeightsLikeWP6. * 2.15.3.54 section page 2252, uiCompat97To2003. * 2.15.3.63 section page 2264, useWord2002TableStyleRules. * 2.15.3.64 section page 2265, useWord97LineBreakRules. * 2.15.3.65 section page 2266, wpJustification. * 2.15.3.66 section page 2268, wpSpaceWidth. Indicating in an international standard that you should copy a certain behaviour is not acceptable. The suitable way to do this is to explain clearly the behaviour. For example: autoSpaceLikeWord95 should be replaced by an attribute that takes a numerical value or a serial of numerical numbers. |
The document must specify the behaviour for each one of these tags | ||
UY | Section 8.6.2
page 24 |
te | ISO/IEC DIS 29500, uses “VML”, another XML format of vectorial drawing that come into conflict with standard W3C SVG. Of all ways it is clear that the use of VML in the specification Open XML will provide backward compatibility. In the document it is correctly expressed that DrawingML is more powerful than VML, and to use DrawingML is the implementation recommended by the standard. | In the following revision of the document it should be specified the option to migrate from VML to DrawingML | ||
UY | Section 3.17.4.1
page 3305 |
te | The dates in the document can be represented in two formats; one of them specifically maintains the anomaly of year 1900 for backward compatibility. The anomaly described about year 1900 is in fact an inherited anomaly for backward compatibility with other applications, so existing calculations in million documents that exists nowadays would be affected if that behaviour changes. The fact that year 1900 is considered a leap year is a contradiction to set in the ISO Standard 8601:2004 “Representation of Dates and Times” | In next revisions the treatment of dates within the standard would have to be reconsidered, including the extension of the representable range. | ||
UY | section 2.18.52
page 2531 |
te | The standard indicates that it should be used
a fixed list of hexadecimal codes of language instead of ISO 639. The
section at issue ST_LangCode (section 2.18.52) lists approximately 225
values for different languages, and it is not used directly in the
structure, but referenced by compatibility with the ST_Lang type, defined
in 2.18.51.
St_Lang is defined by string ISO 639-1 and if the application does not understand the ISO language code, it can make a fallback to one of the 225 codes of language mappings with the ISO codes. |
It is requested to give an example of how implement fallback to one of the 225 codes of language established in the document, has backwards compatibility | ||
UY | Section 6.2.3.17, page 5679 and Section 6.4.3.1, page 5738 | te | There are references to Windows Metafiles or
Enhanced Metafiles, being both propietary formats with technical
dependence of the Windows systems. The natural alternative for these
sections would be ISO/IEC 8632 Standard: “Computer Graphics Metafile”, an
independent ISO format of the platform.
It is clear that OpenXML does not have requirements of implementation for EMF or WMF. The referred section (6.2.3.17) allows the use of any type of graphical formats. The potential values are “Bitmap”, “Pict”, “PictOld”, “PictPrint”, and “PictScreen” which can be mapped to any format of image, particularly to Computer Graphics Metafile. WMF and EMF are presented like possible values in an enumeration. |
It is requested to add an example of configuration of a file that includes an image in format ISO 8632. | ||
UY | Sections 2.15.1.28, page 1941, 3.3.1.69, page 2786 y 3.2.29, page 2698 | te | OpenXML proposes its own cryptographic algorithms, ignoring some safe encryption algorithms approved after an extensive public scrutiny. Within the list of pre-well-known algorithms are listed, MD2, MD3. MD5, which are included by backwards compatibility. | It is requested to indicate which algorithms are recommended and which ones should be used only for bequeathed document conversion, within the list of algorithms. It is also requested to attach an example of the configuration to be used with algorithm ISO 10118-3. | ||
UY | Part 4, Section 7.1 | te | OOXML is not compatible with the industry
standard language to visualize mathematical equations — MathML —
used by the research community and the most important publications as
Science, Nature, etc... .
There is no interoperability with MathML is in the OOXML specifications. |
In the following revision reference to MathML should be included | ||
UY | section 2.18.85 page 2583
section 2.15.1.95 page 2053 section 2.18.97 page 2608 section 5.1.12.41 page 4505 |
te | ISO/IEC DIS 29500 uses “four” inconsistent notations for the percentage units. | In next revisions unify XSD type for the percentage representation. | ||
UY | Part 4, sections: 3.17.7.287, 3.17.7.50, 3.17.7.313, 3.17.7.12, 3.17.7.4, 3.17.7.14, 3.17.7.15 | te | The unit of the arguments of the following functions are not established, SIN, COS, TAN, ASIN, ACOS, ATAN and ATAN2. | It is requested to specify that the arguments of the trigonometric functions are in radians. | ||
UY | Part 4, Section 3.17.7.17 | te | The AVEDEV function should return the average deviation of a list of values. However, the formula given for this function is actually for the calculation of the number of combinations of n things taken k at a time. | It is requested to place the correct formula for standard deviation | ||
UY | Part 4,Section 3.17.7.47 | te | The CONFIDENCE function. as stipulated in OOXML, returns the confidence interval around a population sample being given an alpha value, a standard deviation and a sample size. The problem is that this function is under-defined. One must make an assumption, not stated here, as to the shape of the data distribution. | It is requested to clarify that the distribution used is a normal distribution. | ||
UY | Part 4, Section 3.17.7.48 | te | The CONVERT function converts one unit to another. Some allowed conversions specifically include liquid measure conversions such as from liters to cups or tablespoons. But the references are not specified. Traditional liquid measures vary depending on the country. | It is requested to include the reference to the NIST (from where the references have been taken) or its equivalent in ISO and the list of valid measures with its equivalences at the time of reviewing the standard. | ||
UY | Part 4, Section 3.17.7.352 | te | In the ZTEST function, the key error is found by following the formula where it says, "where x is the sample mean." The problem is that x-bar is the sample mean, not x. | Modify in this section the references to X by X-bar | ||
UY | Section 2.3.1.18, page 842.
Section 2.4.7, page 1085. Section 2.4.8, page 1087. Section 2.4.51, page 1211. Section 2.4.52, page 1213 Section 2.15.1.86, page 2034 Section 2.15.1.87, page 2036 Section 6.1.2.7, page 5227 |
te | Many attributes are defined as bitmasks. For
example:
* Section 2.3.1.18, Paragraph conditional formatting (page 842). * Section 2.4.7, Table cell conditional formatting (page 1085). * Section 2.4.8, Table row conditional formatting (page 1087). * Section 2.4.51, Table style conditional formatting settings (page 1211). * Section 2.4.52, Table style conditional formatting settings exceptions (page 1213) * Section 2.15.1.86, Suggested filtering for list of document styles (page 2034) * Section 2.15.1.87, Suggested sorting for list of document styles (page 2036) * Section 6.1.2.7, tableproperties attribute of shape group (page 5227) Bitmasks defined by ISO/IEC DIS 29500 are in major part, of a fixed length (a fixed number of bits). For example, bitmasks used in sections 2.4.51, 2.4.52, 2.15.1.86, and 2.15.1.87 are all of ST_ShortHexNumber type (2.18.86, p. 2591). Due to the impossibility of adding new bits to a bitmask with a fixed length, the extensibility is limited. But the most important issue is that XML does not need bitmasks, XML provides a much richer structure. Using bitmasks creates a new data modeling, separated from the data modeling of the XML. On the other hand, bitmasks are not validated by any standard scheme of XML validation. |
Modify the standard to use basic XSD data types instead of bitmasks | ||
UY | Part 4, Section 2.15.2.32 | te | This feature has been defined in a way that ignores the existence of current browsers other than Internet Explorer. | It is requested to clearly specify in each combination of these four settings () the application should assume a certain web browser like Firefox, Safari or Opera, in the versions available at the time of the revision of the standard. | ||
UY | Part 1 Introduction
Page XII |
ed | An international standard should avoid specific references to a single product in its introduction. | Remove from the second paragraph ”, all in a way that is fully compatible with the large existing investments in Microsoft Office documents. “ | ||
UY | Part 4,
Section 2.15.1.28 |
te | This algorithm description fails to specify the encoding of the input password. Presumably it is Unicode, but in what encoding? UTF-16BE? UTF-16LE? UTF-16 with a BOM (Byte Ordering Mark)? The described algorithms make use of byte-level manipulations which depend on the machine architecture. So it is necessary that all byte ordering assumptions be made explicit. | Make the byte ordering assumptions explicit, both for the input password and the processing steps, so as to allow cross-platform interoperability. Keep in mind that the hash may be calculated on a different machine architecture than the password was entered with. | ||
UY | Part 4 | ge | The length of structures are defined in an inconsistent way in several examples confusing characters and octets | Review and correct the examples |
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 7
ISO electronic balloting commenting template/version 2001-10
|
![]() |
|