Template for comments and secretariat observations | Date: 16 July, 2007 | Document: Canadian Responses to 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 |
CA-01 | GE | Canada Disapproves 29500 for the
reasons contained in the comments given below and will consider changing
its position if the Canadian comments are addressed.
Further, Canada makes the following recommendations: 1.Convert this standard to a multi part standard, which would mean the reversion of DIS 29500 to an acceptable level of review within the ISO/IEC JTC 1 development process, 2.If a revision is undertaken, address harmonization, insofar as possible, with other ISO/IEC standards, or where ISO/IEC standards do not exist other referencable specifications. |
||||
CA-02 | Part 0 | Office Open XML Overview | Major Editorial | This document is not listed as part of the
ECMA 376 standard in the Forward to Part I “Fundamentals” and its status
whether informative or normative is not explicitly stated.
If this paper is merely a promotional whitepaper about Ecma 376, then it cannot be included in the published standard. . |
If this is meant to be an introduction as per ISO directives, it should so incorporated so as to provide a seamless integration with the main document. | |
CA-03 | Part 0 | Throughout | ED | 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. | Change the name of Office Open XML to a name which is not easily confused with OpenOffice. | |
CA-04 | Part 1, Appendix | ED | 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 labelled version. | ||
CA-05 | Part 1, Section 02.04 | Line 22 | ED | This line requires 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. Specify which is it? |
The second bullet of the document conformance
clause should read:
"The document character set shall conform to the XML 1.0 standard, with either the UTF-8 or UTF-16 encoding form." |
|
CA-06 | Part 1, Section 09.01.01 | ED | ASCII requires a normative reference since there are several national variations. | It is greatly beneficial to all concerned to specify precisely the reference and version, which is standard procedure in ISO | ||
CA-07 | Part 1, Section 09.01.05 | ED | This sub-clause, buried in introductory
material, negates a provision of the more detailed OPC specification in
Part 2.
It is not reasonable to expect that someone reading the packing conventions in Part 2 of a 6,000 page standard will know or remember that hundreds of pages earlier, in Part 1, they were told not to implement that feature. |
Consider adding a reference to the
restrictions described in Part 1 in either of the following
locations:
|
||
CA-08 | Part 1, Section 10.01.02 | ED | Incorrect Part number was given. The comment should read: "Reference is made to material in Part 5, Clause 12. Although a clause of that number does exist, it does not contain the material 10.1.2 references it for." | The reference should be made to Part 5, Clause 11 " Application-defined Extensions Elements". | ||
CA-09 | Part 1, Section 12.03.05 | TE | This binary part is said to be used for the storage of “arbitrary user-defined data”. No further detail is given as to what user action would trigger the use of this “user-defined” data. Without further definition, no interoperability of this feature is possible. | Fully define the use of Custom Property Part | ||
CA-10 | Part 1, Section 15.02.06 | N/A | 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? | Change: "This part shall have no contents" to read "This part shall be a zero-byte file." | |
CA-11 | Part 1, Section 15.02.12
|
ED TE TE |
There is no reference made to a particular
dated version of TrueType or OpenType
specifications. If TrueType and OpenType differ, then there
should be different ways to refer to them, rather than calling them both
“application/x-font-ttf” There is no reference made to a particular dated version of TrueType or OpenType specifications. |
Canada recommends that the references for
OpenType and TrueType might be drawn from the
following: http://www.microsoft.com/typography/specs/default.htm Or http://www.adobe.com/type/opentype/ Perhaps a note that will draw attention to it may be sufficient. |
||
CA-12 | Part 3, Section 08.03.04.01.01 | ED | The graphic provided in the example is almost impossible to read. | Make an easy to read example (perhaps lighter background color). | ||
CA-13 | Part 4 | Throughout | TE | There are 263 uses of invalid xsd:boolean
attribute values: For example, take part 4, 3.10.1.90 "sharedItems. In the
definition of the attributes containsBlank, containsDate, it
says: "Specifies a boolean value that indicates whether this field contains a blank value. A value of on, 1, or true indicates this field contains one or more blank values. A value of off, 0, or false indicates this field does not contain blank values. The possible values for this attribute are defined by the XML Schema boolean datatype." However, XML Schema 3.2.2.1 (http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#boolean) defines allowed lexical value space for xsd:boolean as: "An instance of a datatype that is defined as boolean can have the following legal literals {true, false, 1, 0} ""On" and "Off" are not allowed values. A search of Part 4 indicates 262 other instances of this problem, all in SpreadsheetML and DrawingML. |
This could be fixed by amending the text to
remove the "on" and "off" options or by changing the schema to refer to
the ST_OnOff type defined in 2.18.67, which does allow this set of
values. Caution may be warranted for a cascading effect to a change. |
|
CA-14 | Part 4
Section 03.04 |
lines 12-17 | TE | Lines 12-13 appear to contradict lines 14-16.
The former indicates that formatting is (always) stored in the shared
string table, while the latter indicates that when a cell has a single
format, only the string itself is stored in the shared string
table. Furthermore, if this contradiction is resolved such that the formatting is sometimes in the shared string table and other times in the styles part of a cell, then this becomes an accessibility issue: developers of assistive technology that must change formatting will have a difficult time dealing with this. |
Add the following text:
“The shared string table can contain all the necessary information for displaying the string: the text, formatting properties, and phonetic properties (for East Asian languages). For exceptions to this rule see below." |
|
CA-15 | Part 4 page vii, line 8 | Introduction | ED | An XML markup cannot be “fully compatible” with an “investment” | Change second paragraph of intro to: "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. | |
CA-16 | Part 4, Section 02.03..03.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. |
Provide full normative definitions for these graphical elements. | ||
CA-17 | Part 4, Section 02.15.01.28 | pg 1159, lines 6-9 | TE | The described processing steps are written with respect to a pseudo-language that performs bit-level operations on the data. If this pseudo-language is to give the same answer on different machine architectures, then the assumptions regarding the runtime interpretation of this pseudo language must be make explicit. | Describe the hash algorithm in a platform independent manner. In particular define the assumptions being made on "word" size and sign and the sign and size of characters. Also, clarify the semantics of SHR and SLR, especially in the presence of negative values. If the algorithm allows them to be applied to negative values, are there further assumptions made about the representation of negative numbers, e.g., two complement representation | |
CA-18 | Part 4, Section 02.15.01.28 | TE | This says that document protection “shall be enforced. “Shall” indicates required behaviour. But then a few sentences later it says that document protection “may be ignored.” | The last 4 word of Line 11 should be deleted to avoid the confusion. | ||
CA-19 | Part 4, Section 02.15.02.32 | TE | This feature has been defined in a way which
ignores the existence of current browsers other than Internet
Explorer. What about Firefox, Safari, or 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. It
does not appear to allow an application to produce standards-compliant
output? Does it mean yes to PNG, but no to VML? Or yes
to MathML and SVG? It does not appear that an application can specify this. |
Remove all text specifying how browser detection should be performed. | ||
CA-20 | Part 4, Section 02.15.03.06
Part 4, Section 02.15.03.26 Part 4, Section 02.15.03.31 Part 4, Section 02.15.03.32 Part 4 Section
02.15.03.41 Part 4, Section
02.15.03.51 Part 4, Section
02.15.03.54 Part 4, Section
02.15.03.63 Part 4, Section
02.15.03.64 Part 4, Section 02.15.03.66 |
TE | Therre are about ten elements that are defined
in terms of mimicking a legacy application's behavior.
There is a lack of sufficient detail as to how replicate this behavior. |
Define the intended behavior. | ||
CA-21 | Part 4, Section 02.16.01 | ED | The production rule for field-switch-character
is defined as: field-switch-character: -one or two Latin
letters” However, “Latin letters” is not defined in this specification. Is this to be taken literally as only allowing the letters used in Latin, i.e., capital letters A-Z excluding J, U and W? Or Is it meant to be the ISO 8859-1, the Latin-1
character set? Or Is it meant to be something quite different? |
Provide a precise definition for this production rule | ||
CA-22 | Part 4, Section 02.16.05.33 | TE | This sub-clause defines an INCLUDEPICTURE field which “Retrieves the picture contained in the document named”. However, no mention is made of what formats are permissible for the picture. | Provide a set of recommended interoperable formats, by pointing to the set defined in Part 1, Section 15.2.3 or by repeating it directly at this juncture of the text. | ||
CA-23 | Part 4, Section 02.16.05.33 | ED | 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. This holds as well with documents. |
Define how pictures are named by field-argument. If URIs are permitted then RFC 3896 should be referenced: | ||
CA-24 | Part 4, Section 02.16.05.34 | TE | This subclause defines an INCLUDETEXT field which “Inserts all or part of the text and graphics contained in the document named”. However, no mention is made of what formats are permissible for the retrieved text. | Provide a recommended set of text formats,
either by referencing the set included in Part 1, Section 11.3.1 or
providing it inline (copied below):
[Note: Some examples of formats which might be supported include: · Text = application/txt · RTF = application/rtf · HTML = application/html · XML = application/xml end note] |
||
CA-25 | Part 4, Section 02.16.05.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. | Canada recommends that this section should
refer to either:
XSLT 1.0: http://www.w3.org/TR/2001/REC-xsl-20011015/ or XSLT 2.0 |
||
CA-26 | Part 4, Section 02.16.05.41 | ED | This describes a “MACROBUTTON” field which can run a designated macro or command. But there is no mention of what programming language or API's are allowed for such a designated macro or command. | If this is to be “implementer defined,” the text should so indicate in a clear and unambiguous way. | ||
CA-27 | Part 4, Section
02.18.04 Part 4, Section
03.07.44 Part 4, Section 03.07.46 |
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? Some of the images, such as 'apples' or
'balloons3Colors' show copying artefacts, where extraneous lines or
blotches appear. Although this observation was raised in only three places mentioned at left, it may exist elsewhere in the document. |
It is strongly suggested that the images be of
better quality clipart. In so doing, it is helpful that normative
definitions for these graphical elements are
provided. In addition, for informative purposes, these graphics may be provided in standalone file form, preferably in a scalable graphics format like SVG images to define the page borders. |
||
CA-28 | Part 4, Section 02.18.04 | ED | 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 flavour. |
Provide an interoperable extensibility mechanism for a document author or application to specify their own art border graphics. | ||
CA-29 | Part 4, Section 02.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. | Please correct or explain the
inconsistency.
In particular note that xsd:hexBinary measure s length in octets, not characters |
||
CA-30 | Part 4, Section 02.18.51 | TE | There does not seem to be any language encoded by ST_LangCode that is not also encoded by ISO 639-1. So no purpose is served by having both. In fact, it burdens implementers with supporting both with no increase in expressivity. | Drop the use of the redundant ST_LangCode | ||
CA-31 | Part 4, Section
02.18.66 |
“Chicago Counting systems |
TE ED ED |
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. Format is defined in reference to the “Chicago
Manual of Style”, but no edition or page reference is
provided 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. |
Use a more flexible, extensible, generative
approach to numeration, such as that used by the W3C's XSLT standard in
their xsl:number support Either include the entire definition in the
standard, or provide a proper external reference including the edition
number as a normative reference. For example: “The Chicago Manual of Style, 15th ed.,
2003.” It would helpful to clarify the text to explicitly cover this case. |
|
CA-32 | Part 4, Section 02.18.66 | TE | 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? | Give explicit definitions of these numbering styles or proper external normative references. | ||
CA-33 | Part 4, Section 02.18.66 | decimalFullwidth | TE | There are several mentions of double-byte and single-byte Arabic numbering schemes. Since the conformance clause for OOXML requires the use of Unicode in UTF8 or ITF16 encodings, there should be no mention of other encodings. | Clarify the use of the terms "single byte" and "double byte" in the context of width specifications. It is unclear the relationship between SBCS, DBCS and single width and double width terminology. | |
CA-34 | Part 4, Section 02.18.66 | numberInDash | TE | 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. | |
CA-35 | Part 4, Section 02.18.72 Part 4, Section 05.01.12.37 |
ED | No definition is provided for a “Panose-1
classification” of a font. What is the rationale for several different definitions for a Panose value, both in Word Processing ML as well as Drawing ML? |
Provide an external normative reference for
this term. Since they are exactly the same they should be defined once in a shared schema |
||
CA-36 | Part 4, Section 02.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? |
Define layout properties of embedded objects using DrawingML rather than VML | ||
CA-37 | Part 4, Section
03.02.29 Part 4, Section 03.03.01.69 |
TE | A hash algorithm is provided, likely based on
a legacy algorithm used in Excel. This legacy algorithm is known to
be a weak algorithm and has effectively been cracked. One could argue
that no hash algorithm would be effective in OOXML, since a user could
simply unzip the document and hand edit the XML to remove the hash or to
set it to some known value. However, some application types such as
online editing via Google Docs, or other similar applications, can secure
physical access to the document via other means. Editing access to
the document does not necessarily presuppose physical access to the
document's XML. So there is a necessity for a secure &
interoperable hash algorithm, such as SHA-256 for document
protection. As described the algorithm is technically flawed. It is not ambiguous. It is not poorly worded. It does not have a spelling or grammatical error. It is simply flawed. |
The use of existing standardized hash
algorithms as found in ISO/IEC 10118 part 3 is recommended if extract
security is required or even desired. The default should be set to SHA-256. |
||
CA-38 | Part 4, Section 03.02.29 | pg. 1916 | TE | This seems to imply that if a password is
entered in a script like Armenian or Ethiopic then the characters will be
replaced all by a single character 0x3F, making the protection feature
useless. This is unacceptable 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. Do we process via multiple DBCS code pages? Or just one and then replace the unmapped characters with 0x3F? If only one DBCS code page is used, how is that determined in this case? |
Canada requests that a statement be inserted within this text area which would explicitly clarify the restriction especially with the use of passwords. | |
CA-39 | Part 4, Section 03.02.29 | pp. 1917-1922 | ED | 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. | Provide a normative, cross-platform definition of the hashing algorithm. Cross-platform source code can be given as an example, but the normative text should be in English, not in a programming language. | |
CA-40 | Part 4, Section 03.03.01.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. | Rather than trying to maintain a paper size
registry, a more flexible approach would be to simply record the
dimensions of the paper size selected. Canada requests that the use of the appropriate
ISO standard (ISO-216) sizes be supported. As an extension there is also a need to allow for specifying user defined paper sizes. |
||
CA-41 | Part 4, Section 03.03.01.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. It would most beneficial if the text would describe how multiple user accounts in a security descriptor are encoded. |
||
CA-42 | Part 4, Section 03.17.02 | ED | This clause has two references to a nonexistent section ('§0'). | Fix the reference and ensure that no cascading
effect takes place
Suggest the reference to be: 3.17.2.2 |
||
CA-43 | Part 4, Section 03.17.02.01 | TE | The syntax of constants is defined using an
unspecified notation, which appears to borrow some characteristics of
Backus-Naur Form for grammar productions, some notations from popular ways
of specifying command line applications options, etc., all without
formally defining the notation used.
Note that other parts of the syntax for formulas similarly lack a proper format definition. The reference to the “constants” section is one example. |
Either adopt a formal lexical-syntactic notation by reference (for example ISO 14977:1996 EBNF), or explicitly define your own. | ||
CA-44 | Part 4, Section 03.17.04.01 | 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. | If needed for legacy reasons with legacy spreadsheet documents, then introduce an additional attribute tag such as “treat1900AsLeapYear” or similar. This is the approach recommended elsewhere in OOXML for legacy features. | ||
CA-45 | Part 4, Section 03.17.04.01 | page 2522, lines 16&18 | ED | The documented upper limits for serial date times match 9999-12-31 00:00:00, which is most probably not what was intended. The expected upper limits would match 9999-12-31 23:59:59. | Validate the upper limits. | |
CA-46 | Part 4, Section 03.17.04.01 | page 2522, lines 14-18 | TE | The text proposes a dual date base system. There is no clear advantage to having two slightly different systems, and this brings significant costs and confusion, as illustrated by the need to specify a default base system, etc. | Allow the use of an ISO date format and
include a flag such that applications would know if date based
calculations are done in a special way.
One could use ISO date format and include a flag such that applications would know if they need to treat date based calculations in a peculiar way. |
|
CA-47 | Part 4, Section 03.17.07 | Throughout | TE | There appears to be a production issue in the
creation of the PDF version of this DIS. Many of the mathematical
formulas that define the spreadsheet functions are illegible, and all of
them are of low quality. For example, 3.17.7.24, 3.17.7.32, 3.17.7.38,
etc. For example: 3.17.7.32 BINOMDIST on page 2558. What
power is (1-p) raised to 3.17.7.38 CHITEST on page 2565, what is the subscript on A 3.17..7.233 NEGBINOMDIST on page 2721, what is p' ? p-rime? a first derivitive of p? or a degenerate p^r? |
Provide higher resolution of the mathematical equations. | |
CA-48 | Part 4, Section 03.17.07.12 | ASIN | ED | It is not indicated whether the argument shall be in radians or degrees. This same omission is evident in the definition of ACOS, ATAN, SIN, COS, TAN and TAN2 functions. | Specify the angular units to be in radians as reflected in the example. | |
CA-49 | Part 4, Section 03.17.07.243 | OR | TE | It is not specified whether this function
short-circuits or not. In other words, must the remaining arguments be
evaluated once one of them is found to be TRUE? Since some functions have
side effects, it is necessary to define this in order to ensure
interoperability. The same ambiguity applies to the AND function. |
Specify if this function allows short-circuit evaluation. | |
CA-50 | Part 4, Section 03.17.07.249 | ED | The provided example contradicts the description, since it displays 10 significant digits in its fractional part instead of the (minimum) 15 significant digits which is stated as a requirement. | Fix the example or the text, so this
contradiction is resolved |
||
CA-51 | Part 4, Section 03.17.07.348 | YEARFRAC | TE | This function is ambiguous. Specifically it does not treat the calculation in the presence of leap years. In the Actual/Actual basis, do we ever divide by 366? Or only by 365? Would we divide by 366 only if the leap day is between start-date and end-date? Of either start-date or end-date are in the leap year? If both start-date and end-date are in a leap year? | Clarify the definition of the function when involving leap years. | |
CA-52 | Part 4, Section 03.17.07.49 | CORREL | TE | The definition of the arguments in the
function is incorrect. It should say that x-bar and y-bar are the sample
means, not x and y. This error also occurs in many of the other statistical functions, including: PEARSON, RSQ, SLOPE,STDEV,STDEVA,STDEVP,STDEVPA,STEYX,VAR,VARA and VARP |
Change the text of each of these clauses so it matches the notation of the equation given. In most cases this will be a change from "where x is the sample mean" to "where x-bar is the sample mean." | |
CA-53 | Part 4, Section 03.17.07.65 | CUBEKPIMEMBER | TE | The “kpi-property” parameter lists a number of values which are undefined such as “temporal context”, “relative importance”, etc. This is made even more cryptic by the fact that this function, unlike almost all the others, has examples that fail to illustrate the returned values. If there is to interoperability in the use of this function, semantics in additional to syntax will need to be specified. | Provide the semantics for this function, as well as, provide some examples. | |
CA-54 | Part 4, Section 03.17.07.76 | DATEVALUE | TE | This function says that it can take a string in any valid date and/or time format. It further says that if the year portion of the input string is omitted, that the current year is used. But what if the date is omitted as well, e.g.,, someone passes in a pure time string like “10:34”? Is it to be assumed as current date? Or assume January 1st of the current year? | Describe the boundary conditions for when only the time format is specified. | |
CA-55 | Part 4, Section 03.17.07.91 | DISC | TE | The function is defined in terms of $100 face value, but there is nothing about the security discounting that is intrinsically tied to the US Dollar | Recommend the use of the generic currency sign here (U+00A4) | |
CA-56 | Part 4, Section 03.18.95 | ED | All of the URL’s provided here are incorrect. They lack the colon following “http”. | Correct the URL’s as provided below. | ||
CA-57 | Part 4, Section 05.01.03.04 | ED | 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. |
||
CA-58 | Part 4, Section 05.01.12.28 | ED | 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. | Recommend the use of the already defined ST_HexColorRGB type, and remove ST_HexBinary3 | ||
CA-59 | Part 4, Section 06.01.02.19 | TE | This section 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 it is the intent to have a new math markup language in XML, and ignore the existing MathML, then 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. |
Change the following text:
"Specifies alternate XML markup which may be used to rehydrate an equation using the Office Open XML Math syntax. The actual format of the contents of this attribute are application-defined, but shall contain Office Open XML Math as well as any applicationspecific content. The XML markup stored in this attribute shall be escaped as needed to contain only those characters legal in an attribute value. The possible values for this attribute are defined by the XML Schema string datatype." to the following: "Specifies optional application-defined XML markup which may be used to store an equation. The XML markup stored in this attribute shall be escaped as needed to contain only those characters legal in an attribute value. The possible values for this attribute are defined by the XML Schema string datatype. Note: The actual format of the contents of this attribute may contain Office Open XML Math as well as any application specific content." |
||
CA-60 | Part 4, Section 06.04.02.04 | AutoFill | TE | The text says, “This element specifies that the object is an AutoFill object. If this element is specified without a value, it is assumed to be true. This is a general-use element.” However, nowhere in the spec is an “AutoFill object” defined. | Define the behaviour of an
“AutoFill object |
|
CA-61 | Part 4, Section 06.04.02.05 | AutoLine | TE | The text states: “This element specifies that the object is an AutoLine object. If this element is specified without a value, it is assumed to be true. This is a general-use element.” However, nowhere in the spec is an “AutoLine object” defined. | Define the behaviour of an “AutoLine” object | |
CA-62 | Part 4, Section 06.04.02.08 | TE | This element specifies that the object is a camera object. A camera object shows a live view of another part of the spreadsheet. If this element is specified without a value, it is assumed to be true. This element is used for cameras." However, a “camera” is not defined in this context, nor its behaviour. | Define a "camera object" in this context. | ||
CA-63 | Part 4, Section 06.04.02.10 | ED | This element is defined as providing a, “general-use element for objects that use an image representation, such as OLE objects, embedded controls, cameras and signature lines.” However, the allowed values, EMF, WMF, etc., refer to formats for which no reference has been given. | Provide a proper external normative reference for the allowed formats containable within this element. | ||
CA-64 | Part 4, Section 07.04.02.04 | ED | 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 Activity confirms this interpretation, saying Control codes should be replaced with CA-appropriate markup. Since XML provides a standard way of encoding structured data, representing control codes other than as markup would undo the actual advantages of using XML. Use of control codes in HTML and XHTML is never appropriate, since these markup languages are for representing text, not data.” | Change the following text:
For all characters that cannot be represented in XML as defined by the XML 1.0 specification, the characters are escaped using the Unicode numerical character representation escape character format _xHHHH_, where H represents a hexadecimal character in the character's value. to the following (adding the word UNICODE near the beginning of the sentence): "For all UNICODE characters that cannot be represented in XML as defined by the XML 1.0 specification, the characters are escaped using the Unicode numerical character representation escape character format _xHHHH_, where H represents a hexadecimal character in the character's value." In addition this Section should make it clear that valid XML 1.0 UNICODE characters are permitted in the bstr value and not just UNICODE characters that cannot be represented. |
||
CA-65 | Part 4, Section 07.04.02.04 | 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 | ||
CA-66 | Part 4, Section 07.04.02.05 | ED | This section should clarify:
a) the string encoding for the null-terminated case b) how long and GUID values are base64-binary encoded including byte ordering considerations c) the use of this data type with one or more examples d) the positive value case since it is unclear reading the text that this actually represents the length of the string and not the string itself e) That the string encoding value can be used for clipboard formats for other platforms. |
The content of this section is hard to understand and too terse. | ||
CA-67 | Part 4, Section 07.04.02.05 | Refers to line 10, row corresponding to Format Value -1 | 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. | Request that GUID to be defined so interoperability may be achieved. | |
CA-68 | Part 4, Section 07.04.02.05 | 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”? | Define Clipboard Format values | ||
CA-69 | Part 4, Section 2.16.17 | page 1585 | TE | The standard does not provide the function of labelling an actionable form element. There is also no explicit relationship between a label and its associated form field (textInput - 2.16.33, checkBox - 2.16.7, and ddList - 2.16.7). Where a label is a human readable text string identifying the choice to be made or the text to be filled into the text field that is accessible to a screen reader. This functionality is different from a name. | Provide the functionality of a label for actionable form elements and provide a way to explicitly link labels to their text fields. | |
CA-70 | Part 4, Section 3.17.7.17 | ED | The example given is incorrect. It is a formula for calculating the number of combinations of n things taken k at a time. This does not concern absolute deviation. | Perhaps the formula below may be beneficial to
be included: |
||
CA-71 | Part 4, Section 3.17.7.341 | TE | As written this function mandates an incorrect calculation for day of week for certain dates in the year 1900. 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. | If needed for legacy reasons with legacy spreadsheet documents, then introduce an additional attribute tag such as treat1900AsLeapYear or similar. This is the approach recommended elsewhere in OOXML for legacy features. | ||
CA-72 | Part 4, Section 4.4.1.35 | Page 3044 | TE | There is no way to explicitly specify the navigation order among elements on a presentation slide. | Provide a specific mechanism for defining the ordering of objects on a slide - for example, considers amending the “id” attribute on the cNvPr element (page 3022) to specifically state that it shall be used for this purpose. | |
CA-73 | Part 4, Section 5.5.2.5 | Page 3909 | TE | It is not clear how DIS 29500 can be used to create an image map. One possible method is to compose a set of separate images each with their own linked region and label/descriptive text. If this technique is used, how is a label/descriptive text applied to the composite set of images? | Provide consistent instructions in how to create an image map. Provide the function of specifying Alternative text descriptions for all linked regions of an image map including the overall image map. | |
CA-74 | Part 4, Section 6.4.3.1 | 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. For example, in Linux images are typically copied on the clipboard in an open standard format like PNG. | There are several approaches here to better
support portability and cross-platform interoperability. For
example: 1) Define the ST_CF type as being a union of xsd:string and the existing enumeration. 2) Augment the existing enumeration with a fuller list of clipboard formats, including those commonly used on non-Windows platforms. 3) Define an additional attribute whose value can contain additional clipboard types. |
||
CA-75 | Throughout | TE | It is recommended that this standard interoperate with accessibility-vetted approaches, such as XLinks, XForms and SMIL | Provide an “Informative” annex which
would provide information on accessibility features and hooks in the
development of assistive technologies. Canada recommends a full review of the standard for Accessibility for future versions of this standard. |
||
CA-76 | Part 4, Section 6. | To go to the end | 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. | Change Section 6 to an “Informative” Annex or separate document. | |
CA-77 | Part 4, Section 7.1 | TE | This is the specification of Office Open Math Markup Language, a specialized XML vocabulary for the describing the layout of mathematical equations. This solves the same problem as MathML, a long-established W3C standard and an ongoing activity in the W3C. Since the equation editing feature of Word was entirely rewritten in Word 2007, there doesn't not seem to be the argument that an additional equation language must be introduced for the sake of legacy documents. | A future version of the standard shall consider permitting the use of W3C MathML 2.0 Recommendation or the W3C MathML 3.0 specification (currently under development) as an alternative to Office Open Math Markup language (see Part 4 Section 7 and the oMathPara element). | ||
CA-78 | Throughout | GE | An accessible standard must make it easy to create a compatible assistive technology (this is referred to as access-system friendliness). This requires a standard that is easy to follow, that is consistent (without a large number of exceptions), that uses other open standards wherever possible, that harmonizes with other standards in the domain, and that makes necessary semantics programmatically available to the assistive technology. It is not clear how this standard meets the above criteria. | Provide an “Informative” annex which
would provide information on accessibility features and hooks in the
development of assistive technologies. Canada recommends a full review of the standard for Accessibility for future versions of this standard. |
||
CA-79 | Part 4, Section 2.15.3. | 1368 | TE | This comment is with respect to the ten
legacy-application-mimicking elements defined in section 2.15.3
(shapeLayoutLikeWW8, autoSpaceLikeWord95, wpSpaceWidth,
footnoteLayoutLikeWW8, mwSmallCaps, suppressTopSpacingWP,
truncateFontHeightsLikeWP6, useWord2002TableStyleRules, wpJustification,
lineWrapLikeWord6).
Not only is there not sufficient detail as to
how to replicate this behaviour, but referring to this proprietary
behaviour makes it difficult for developers to make compatible Assistive
Technologies. By making these part of the standard (as opposed to
application-specific extensions), this increases the necessary complexity
of AT's for |
Explicitly indicate that these functions are generic. |
1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CA for Canada; 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 27
ISO electronic balloting commenting template/version 2001-10
|
![]() |
|