Page 3 (14), Line 29 - 31 |
“All background information in a WordprocessingML document is stored using the Vector Markup Language (VML) syntax.” We are advised that VML is deprecated and a legacy spec. This is confusing technically (Part 1, 8.6.3 Page 15 (27), Line 8) |
Remove reference to VML syntax and use DrawingML to specify Background information |
Section 3.17.4.1 Page 2522 (2528) |
Calculation for 1900 as a leap year with this date system is an unnecessarily burden to implementers of this proposed standard |
Adopt ISO 8601 for date encoding to avoid legacy application level issues |
Page 2522 (2528) |
The definition of the 2 date ranges (1900-9999 and 1904-1999) is unnecessarily restrictive. Dates prior to 1900 (or 1904) will be considered “ill-formed” and therefore not valid. Historical dates should not be disregarded. |
Adopt ISO 8601 which sufficiently caters for a wider historical range of dates |
|
Ecma 376 has two different methods of representing dates in the system (eg in Part 4, Section 3.17.4.1). Ecma 376 should be reviewed to standardize on a method for date representation. |
Ecma 376 should be reviewed to standardize on a method for date representation. |
Ecma Response Page 11 (15) Line 1-3 |
“OpenXML provides a file format that allows numbers to be formatted as dates, including ISO 8601 date formats, as well as allowing those numbers to be used in both date and other numeric formulas as is normal for spreadsheets.” Although MS Office 2003 XML formats uses ISO 8601 to represent dates, OOXML reverts to the numerics. |
Adopt ISO 8601 to remove any ambiguity |
Ecma Response Page 13 (17) Line 26-29 |
“the percentage values allowed have been limited to integers to permit efficient parsing and processing. (Use of the % symbol and allowing non-integer decimal values would introduce parsing complexity.)” The complexity in parsing has been overstated. Parsing 1 million non-integers with % symbols only takes less than 1 second of processing time |
Use well known units and symbols for human readability for Percentages. e.g. tableWidth=”80%” zoomFactor=”250.5%” coverage=”63.5%” |
Page 1540 (1546) |
This Section has a direct reference to ST_LangCode (2.18.52) with no alternate usage of ST_Lang (2.18.51) as advised by the Ecma Response (2.5.2) on ISO 639 language name codes: “The use of the ISO 639-1 letter code style is the primary use, and the ST_LangCode model is a fallback alternative if the producer would rather use the hexadecimal values as defined in 2.18.52.” This limits the utility of this draft standard as only a limited number of language IDs are codified for INDEXes. |
Incorporate ISO 639 Language codes in encoding Indexes instead of the limited ST_LangCode |
Page 1755 (1761) |
The stated Reference to this section is only 2.18.51 “ST_Lang”. However Section 2.16.5.35 “INDEX” also refers to this section |
Add “INDEX (§2.16.5.35)” In the Reference box |
Page 1748 (1754) |
The Section is titled “ST_LangCode (Two Digit Hexadecimal Language Code)” The codes however, are neither “Two Digits” nor are they Hexadecimal. They are enumerated in plain decimal and range between 4 digits to 5 digits. If they are enumerated in hexadecimal, it will be Four hexadecimal characters: “Two digit” Hex = “E40C” Decimal = “58389” which maps to “French – North Africa” |
Either rename the Section or change the codes to hex. “ST_LangCode (Four digit Hexadecimal Language Code)” or “ST_LangCode (Decimal Language Code)” Preferably we suggest to remove the restrictive and obscure enumeration types with proper ISO 639 Language codes. |
Page 1008 (1014) |
“nfc value – The value of the numbering style at the specific numbering level” are digits which have an enumeration equivalent map to ST_NumberFormat (2.18.66). |
Instead of declaring yet another form of Numbering Formats, the specification should re-use the ST_NumberFormat definition |
Page 1771 (1777) |
ST_NumberFormat is an enumeration of the different numbering types the single vendor supports worldwide. Only major languages are supported specifically English, Arabic, Chinese, Japanese, Thai, Hebrew, Russian, Hindi, Korean and Vietnamese. Other cultures are ignored, e.g. Malayalam, Gujerati, Gaelic and thousands of other minority cultures. |
Use an XML friendly method of encoding the numbering formats like XSLT. |
Page 1739 (1744) |
This section has definition of 16 colours for highlighting colours between a string enumeration with hexadecimal RGB values. These colours are platform specific colours, from the legacy of Windows 3.0 (or earlier) where 4bit colours (16 available colours) were defined. The colour names and colour values are not standard with HTML colours. The 16 colour enumeration limits the number of editors working on one document. New online applications may have to support hundreds of concurrent editors, and this 20 year old definition of colours will limit this specifications utility. |
Change the definition of colours to HTML colour name and values, or SVG colour name and values, or allow direct hexadecimal colour values for full 24bit colour palette (over 16 million colours). |
Page 3748 (3754) |
The Definition of 140 colours are remarkably close to the W3C definition of colours, which include the names and the colour values. http://www.w3.org/TR/ SVG/types.html#ColorKeywords However there are a handful of discrepancies, in that “dark” is renamed as “dk” and certain values of the colours are different. This is probably to avoid conflicts with colours from ST_HighlightColor (2.18.46). Redefinition of an already mature standard is unnecessary |
ST_PresetColorVal should leverage on existing and mature colour palettes as defined by W3C SVG colours. |
Page 1988 (1994) |
Paper size is defined as an enumerated number which is limited to the current definition of 68 paper types. Malaysia which commonly uses “Foolscap” or F4 or (210mm x 330mm) or (8” x 13”) is ignored as this paper type is not included in this list. |
Use a XML namespace <w:pageSetup w:paperSize=”ISO:A4” /> or directly use page dimensions with units <w:pageSetup w:paperWidth=”210mm” w:paperHeight=”270mm” /> |
Page 2559 (2565) |
Ceiling is defined as: “Computes a value that is x rounded-up, away from zero,” This is not mathematically accurate when it involves negative numbers. The mathematical definition specifies that negative values of x is rounded towards zero. This error should not be propagated to our future spreadsheets. |
The CEILING function should default to the mathematically correct version with a compatibility flag as an optional parameter. e.g. =CEILING( -2.3, 1 ) should evaluate to -2 (the mathematically correct result) while =CEILING( -2.3, 1, 1) should evaluate to -3 ( the incorrect but legacy result) |
|
A general comment on the XML Element and Attribute names. There appears a lack of naming convention for consistency as well as readability. The purpose of using XML is for human legibility and terseness in XML markup is of minimal importance. This will benefit non-English speaking developers who will have difficulty understanding the schema if name truncations occurs |
Edit and rename all the inconsistent and unnecessarily truncated XML Element, Attributes and Property names of the schema. e.g. in Section 5.1.10.45 outerShdw. “scrgbClr, algn, blurRad, dir, dist, rotWithShape” These should be renamed to something more readable like: “ScreenRGBColor, ShadowAlignment, BlurRadius, Direction, Distance, RotateWithShape” |
|
Ecma 376 uses a legacy and non-standard hashing algorithm (Part 4, Section 2.15.1.28) which has not been proven to be secure and interoperable. Generally, FIPS hashing algorithms are used and adopted by standards bodies (eg ANSI, ISO etc). |
Ecma 376 should be reviewed to incorporate secure FIPS-180 compliant hashing algorithm be used (eg SHA-256). |
|
Ecma 376 has extensive use of bitmasks (eg in Part 4, Section 2.15.1.86 and Part 4, Section 2.15.1.87). Bitmasks are not suitable in an XML standard as they do not allow existing widely used XML processing tools to manipulate Ecma 376 documents. |
Ecma 376 should be reviewed to remove all use of bitmasks and replace them with correct and equivalent XML constructs. |
|
Multiple sections in Ecma 376 (eg in Part 4, Section 2.15.3.26, Part 4, Section 2.15.3.31, Part 4, Section 2.15.3.32) specify implementation which is never defined. This makes it impossible for external implementators to implement the standard because there is no definition to follow. |
Ecma 376 should be thoroughly reviewed to remove any vague and non-defined references. |
|
Ecma 376 does not specify a method of storing equations in the document(eg in Part 4, Section 6.1.12.19). This ensures that any document containing an equation cannot be shared with other applications, and thus is not interoperable. This situation is not acceptable as it will lead to undefined document behaviour. |
Ecma 376 should be reviewed to specify a standard for storing equations. |
|
Ecma 376 does not specify password encoding values (Part 4, Section 2.15.1.28). All documents today must be able to support multiple languages through the use of proper Unicode encoding. However, Ecma 376 does not specify the Unicode encoding to be used and therefore is confusing to implementators as the algorithms specified indicate the manipulation of bytes which strictly depends on the encoding. |
Ecma 376 should be reviewed to correctly specify Unicode encoding. |
|
Ecma 376 does not specify a method of referencing documents (eg in Part 4, Section 2.16.5.34). This makes it impossible to have an interoperable multiplatform standard as document reference will be platform specific and nonportable. For example, an Ecma 376 document created on MS-Windows will have MS-Windows style document referencing (ie C:\documents\part001.xml) whereas the same document created on a UNIX system may follow URI semantics (ie file:///home/user/Desktop/.homedocs/part001.xml). This leads to unportability implementation issues. |
Ecma 376 should be reviewed to include specifications on the method of referencing documents. |
|
Ecma 376 has inconsistency in the definition of character types and character lengths (eg in Part 4, Section 2.18.106, Part 4, Section 2.18.45, Part 4, Section 2.18.57, etc). Hexadecimal lengths in XML are measured in octets and not characters, yet Ecma 376 specifies length in characters which makes no sense in a document that has Unicode characters. |
Ecma 376 should be reviewed to correct all such definitions. |