|
|
|
Balloted |
document: |
ISO/IEC
DIS 29500 Information technology -- Office Open XML file
formats |
|
|
|
|
|
Vote: |
Approve
|
|
|
|
1 |
2 |
3 |
4 |
5 |
DIS (ISO
29500) |
No. |
Category |
Clause,
Sub-clause |
Page |
Comment and
rationale |
Proposed
change |
Part 1 |
CO |
1 |
te |
Introduction |
xii(12) |
The second paragraph
states that the format "is fully compatible with the large existing
investments in Microsoft Office documents". Since the format for Microsoft
documents is proprietary no such mapping is available, so this claim
cannot be proven. Also a standard cannot be compatible with an
investment. |
The claim must be proven
or removed. |
CO |
2 |
te |
Section 2.6 |
4(16) |
The requirements
presented as necessary for interoperability only addresses a part of the
problem. Apart of what is mentioned, it is also important to properly
limit and define the use of extensions, as this will inevitably lead to
problems of interoperability and portability, since documents using
undocumented extensions will be valid OOXML documents, but will make the
document unreadable by different applications than the one which created
it. |
Enforce interoperability
throughout the standard. A document-producing application must inform the
user when extensions which will break interoperability and portability are
used, to avoid misleading the user into thinking that particular document
can be consumed by any other OOXML compliant application. The standard
should mandate the use of some mechanism to mark the document as
“extended”, e.g. a warning message or a different document extension.
Sections which include non-portable extensions in Part 4 include:
2.3.3.17, 2.16.5.33, 2.16.5.34, 2.17.3, 3.2.7, 4.6.9, 4.6.68, 4.6.69,
4.6.70, 4.6.93, 5.1.3.2, 5.2.3.4, 5.1.3.6, 5.1.3.7, 6.1.2.19 |
CO |
3 |
te |
Section 4 |
6(18) |
The definition given
here for “behavior, implementation-defined” contradicts its use in the
normative sections of the standard. Although it is defined as "promoting
predictability and reproducibility within any given implementation", the
actual use of this term in the standard always implies undefined and
unreferenced propietary behiour which in fact makes predictability and
reproducibility impossible. |
Adjust this definition
to the actual contents of the standard, or better yet, revise the standard
to make this this statement true by defining each particular "application
specific" behavior (see further comments for section 4) |
CO |
4 |
te |
Section 9.1 |
|
According to this point
(Constraints on Office Open XML's Use of OPC), OPC, Open Packaging
Conventions, are more general than needed for the purpose of OOXML. This
is due to bring confusion, and should be resolved |
Propose OPC as a
separate standard. |
CO |
5 |
te |
Section
15.2.14 |
155(167) |
OOXML allows the
inclusion of binary data for printer settings (DEVMODE), which presents a
potential security risk. |
These configurations
should be expressed with proper XML, and since they are platform specific,
there should be proper definitions for each platform. |
Part 3 |
CO |
6 |
te |
Introduction |
xii(12) |
The second paragraph
states that the format "is fully compatible with the large existing
investments in Microsoft Office documents". Since the format for Microsoft
documents is proprietary no such mapping is available, so this claim
cannot be proven. Also a standard cannot be compatible with an
investment. |
The claim must be proven
or removed. |
CO |
7 |
ed |
2.3.1 |
4(16) |
Closing quotes missing
in example |
Fix |
CO |
8 |
ed |
2.4.1 |
4(16){36} |
The sentence “some
require a designating specifying" makes no sense |
Fix |
CO |
9 |
ed |
2.4.2 |
5(17){30} |
The word
“emphasized” must be in italics to agree with the example |
Fix |
CO |
10 |
ed |
2.4.2 |
6(18){4} |
tag <w:rPr> should
be</w:rPr> |
Fix |
CO |
11 |
ed |
2.4.2 |
6(18){17} |
tag <w:rPr> should
be</w:rPr> |
Fix |
CO |
12 |
ed |
2.4.2 |
6(18){23} |
tag <w:rPr> should
be</w:rPr> |
Fix |
CO |
13 |
ed |
2.4.2 |
6(18){28} |
The sentence “the
properties of only some the text” is not complete |
Fix |
CO |
14 |
ed |
2.5.2 |
10(22){17} |
Closing quotes
missing |
Fix |
CO |
15 |
ed |
2.5.2 |
12(24){5} |
Use straight quotes
instead of curly |
Fix |
CO |
16 |
ed |
2.5.2 |
12(24){26} |
Use straight quotes
instead of curly |
Fix |
CO |
17 |
ed |
2.5.4 |
13(25){31} |
“World” should not be
capitalized to agree with example |
Fix |
CO |
18 |
ed |
2.5.4 |
14(26){13} |
the line is not valid
XML |
Delete the
line |
CO |
19 |
te |
2.6.2 |
22(34){3} |
www.contoso.com points
to the Microsoft Office website |
Use a neutral
example |
CO |
20 |
te |
2.6.2 |
22(34){13} |
www.contoso.com points
to the Microsoft Office website |
Use a neutral
example |
CO |
21 |
te |
2.6.2 |
22(34){26} |
www.contoso.com points
to the Microsoft Office website |
Use a neutral
example |
CO |
22 |
ed |
2.7.1 |
28(40){1} |
This listing appears
identical in the previous page |
Remove the duplicate
text |
CO |
23 |
ed |
2.8.2 |
30(42){2} |
“heading 1” should
“Heading 1” to agree with the text |
Fix |
CO |
24 |
ed |
2.8.2 |
30(42){6} |
Element <w:style>
has no child <w:priority>. |
Fix |
CO |
25 |
ed |
2.8.2 |
30(42){22} |
The example is
repeted |
Remove the duplicate
text |
CO |
26 |
ed |
2.8.5 |
34(46){30} |
The example is repeated
on the same page |
Remove the duplicate
text |
CO |
27 |
ed |
2.8.6 |
36(48){17} |
Element <w:style>
has no child <w:priority>. |
Fix |
CO |
28 |
ed |
2.8.7 |
38(50){15} |
Element <w:style>
has no child <w:priority>. |
Fix |
CO |
29 |
ed |
2.8.11 |
42(54){26} |
Element
<w:latentStyles> has no child <w:defPriority>. |
Fix |
CO |
30 |
ed |
2.8.11 |
43(54){31-32} |
Element <w:style>
has no child <w:priority>. |
Fix |
CO |
31 |
ed |
2.8.11 |
45(54){35-36} |
Element <w:style>
has no child <w:priority>. |
Fix |
CO |
32 |
ed |
2.8.11 |
47(54){1-5} |
Element <w:style>
has no child <w:priority>. |
Fix |
CO |
33 |
ed |
2.14.7 |
78(90){29} |
Code should read “Some “
(including white space) to agree with example |
Element <w:style>
has no child <w:priority>. |
CO |
34 |
te |
3.2.9.2.2 |
105(107){27} |
The method for
specifying references to cells and external files using the <f> tag
is presented, but the complete behavior is not presented in the normative
section (Part 4 Section 3.3.1.37) for this tag. It is presented later in
Part 4, Section 3.17.2.3, but even here there is no mention of references
to external spreadsheets. |
Define the behavior in
the normative clauses. |
CO |
35 |
te |
3.16.9 |
226(238) |
In the 1900 date base
system, the lower limit is January 1, 1900. |
Remove this unnecessary
restriction and allow better date support. Allow negative values in the
serial number or define a system counting from an earlier date (e.g. 0
A.D.) |
CO |
36 |
ed |
5.8.3.24 |
325(337){24} |
Code formatting differs
from the rest of the standard. It is a graphic and has no line
numbers |
Fix |
CO |
37 |
ed |
5.8.4.1 |
327(339){16} |
Code formatting differs
from the rest of the standard. It is a graphic and has no line
numbers |
Fix |
CO |
38 |
ed |
5.8.4.2 |
328(340){1} |
Code formatting differs
from the rest of the standard. It is a graphic and has no line
numbers |
Fix |
CO |
39 |
ed |
5.8.4.3 |
329(341){1} |
Code formatting differs
from the rest of the standard. It is a graphic and has no line
numbers |
Fix |
CO |
40 |
ed |
5.8.4.5 |
332(344){1} |
Code formatting differs
from the rest of the standard. It is a graphic and has no line
numbers |
Fix |
CO |
41 |
ed |
5.8.5.3 |
333(345){19} |
Code formatting differs
from the rest of the standard. It is a graphic and has no line
numbers |
Fix |
CO |
42 |
ed |
5.8.5.4 |
334(346){6} |
Code formatting differs
from the rest of the standard. It is a graphic and has no line
numbers |
Fix |
CO |
43 |
ed |
5.9.2.1 |
339(351){10} |
The definition for the
unit EMU should be stated as 91440 EMU = 1 U.S. Inch and 36000 EMU = 1
cm. |
Fix |
CO |
44 |
ed |
5.9.4.3 |
344(356){33} |
Use straight quotes
instead of curly ones |
Fix |
CO |
45 |
ed |
5.9.4.3.1 |
345(357){29} |
Use straight quotes
instead of curly ones |
Fix |
CO |
46 |
ed |
5.12.3 |
356(368){3} |
The example presents
invalid XML |
Fix |
CO |
47 |
ed |
5.12.3.1.1 |
356(368){22} |
The example presents
invalid XML |
Fix |
CO |
48 |
ed |
5.12.3.1.2 |
357(369){10} |
The example presents
invalid XML |
Fix |
CO |
49 |
ed |
5.12.3.1.3 |
358(369){36} |
The example presents
invalid XML |
Fix |
CO |
50 |
ed |
5.13.2.2 |
369(381){1} |
Example is
inconsistent. |
Change for valid XML, o
present as a tree graphic. |
CO |
51 |
ed |
5.14.3 |
373(385){21} |
The example presents
invalid XML |
Fix |
CO |
52 |
ed |
5.14.3.1.1 |
373(385){36} |
Code formatting differs
from the rest of the standard. It is a graphic and has no line
numbers |
Fix |
CO |
53 |
ed |
5.14.3.1.1 |
374(386){5} |
The example presents
invalid XML |
Fix |
CO |
54 |
ed |
5.14.3.1.2 |
374(386){24} |
The example presents
invalid XML |
Fix |
CO |
55 |
ed |
5.15.3.1.3 |
379(391){20} |
Missing closing quotes
for attribute “maxOccurs” |
Fix |
CO |
56 |
ed |
5.15.3.1.4 |
380(392){5} |
Missing closing quotes
for attribute "name" |
Fix |
CO |
57 |
ed |
5.15.4.1 |
382(394){26} |
Missing closing quotes
for attribute "name" |
Fix |
CO |
58 |
ed |
5.15.4.1.3 |
384(396){15} |
Missing closing quotes
for attribute "name" |
Fix |
CO |
59 |
ed |
5.15.4.1.6 |
386(398){9} |
Missing closing quotes
for attribute "name" |
Fix |
CO |
60 |
ed |
5.15.4.1.6 |
386(398){10} |
Invalid text
“odoc” |
Remove |
CO |
61 |
ed |
5.15.5.1.3 |
389(401){33} |
Invalid character at end
of line |
Remove |
CO |
62 |
ed |
5.15.6.3.1 |
403(415){25-26} |
Attributes are given
without quotes |
Add quotes |
CO |
63 |
ed |
5.15.6.3.16 |
407(419){11} |
Attribute “animLvl” is
not closed with quotes and has no white space to separate it from next
attribute “type” |
Fix |
CO |
64 |
ed |
5.15.6.3.39 |
415(427){16} |
Missing closing quotes
for attribute “maxOccurs” |
Fix |
CO |
65 |
ed |
7.1 |
431(443) |
The description for
OMath in this informative section is not detailed enough for the purpose
of this section, especially when compared to the rest of the sections in
this part. It has no code examples like the rest of the
sections. |
Make the text more
detailed and consisten with the other sections |
CO |
66 |
ed |
7.1 |
431(443) |
The term "mathematical
equation" typically imples an equal sign. |
Use of the term
"mathematical expression" is recommended throughout the
section |
CO |
67 |
ed |
7.1 |
431(443){18} |
Duplicate
expressions |
Remove
duplicates |
CO |
68 |
ed |
7.1 |
431(443){19-20} |
Duplicate
expressions |
Remove
duplicates |
CO |
69 |
ed |
7.1.10 |
435(447){5} |
Expression "x+x+x" is
used, and below it appears as "x+x+..." |
Fix |
CO |
70 |
ed |
7.1.12 |
436(448){11} |
The property refers to
the upper index, no the lower one |
Fix |
CO |
71 |
ed |
7.2.1 |
440(452){6} |
Invalid XMl in
example |
Fix |
CO |
72 |
ed |
7.4.3 |
445(457){8,15,22} |
Invalid XML in example.
Closing element </b:nameList> missing three times |
Fix |
CO |
73 |
ed |
8.1 |
447(459){11-13} |
Code formatting is not
consistent with the rest of the standard because it is in italics. For
consistency use of double quotes instead of apostrophe is
preferred. |
Fix |
CO |
74 |
ed |
8.2.5 |
452(464){29} |
El formato del código es
diferente al resto del estándar. Además no es necesario usar una ruta de
archivo tan larga para el ejemplo |
Fix |
CO |
75 |
ed |
8.3.4.1.1 |
456(468){1} |
The image is practically
unreadable because of resolution and background color |
Fix |
Part 4 |
CO |
76 |
te |
2.2.1 |
27(33){4} |
Background elements are
defined as using VML. However, 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 applications that need a file format for drawings are
strongly encouraged to use preferentially DrawingML”. In this case, even
new documents must use VML to specify backgorunds. |
Remove references to VML
and substitue for DrawingML. |
CO |
77 |
te |
2.2.1 |
27(33){8&21} |
Contradicting use of
accent3 and accent5 – the text says one thing, but the example says
another. |
Fix the
contradiction. |
CO |
78 |
te |
2.2.1 |
28(34){1} |
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.' |
Define the
characteristics of the auto value for the color attribute of the
background element properly. |
CO |
79 |
te |
2.2.1 |
29(35){0} |
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). |
Clarify which border the
text refers to (if any notion of border must be introduced here) or else
rewrite the text so that it makes sense. |
CO |
80 |
te |
2.3.1.8 |
59 (66) |
The element “cnfStyle”
uses a bitmask to specify various paragraph conditional formatting
properties.. The use of bitmasks rather than a set of boolean types makes
this data almost impossible to work with standard XML tools like XSLT
which lack bit-level operations. |
Rewrite this subclause
to express the feature using XML constructs rather than
bitmasks. |
CO |
81 |
te |
2.3.2.8 |
175(182) |
It is desired to have
improved interoperability between ODF and OOXML. However, OOXML's "vert"
attribute only allows text to be rotated 270 degrees, whereas ODF's
equivalent allows text rotation by 90 or 270 degrees. |
Include ability to
specify 90 degree text rotation in addition to existing 270 degree
rotation. |
CO |
82 |
te |
2.3.2.1 |
160(167) |
It is desired to have
improved interoperability between ODF and OOXML. However, OOXML text runs
only support two font weights, bold or normal, where ODF supports the
fuller range of font weights from XSL-FO |
Include support for
additional font weights, 100, 200, 300, 400, 500,600. 700, 800 and
900. |
CO |
83 |
te |
2.3.2 |
159(166) |
It is not clear why
formatting indications (like bold, italic, etc.) is to be done using
individual elements, as this complicates parsing. This method presents no
clear design benefit. |
This can be done more
naturally using attributes, which will make the document easier to
interpret using standard XML tools. |
CO |
84 |
te |
2.3.3.17 |
259(266) |
The type of video
element allowed is not specified. Use of propietary codecs will break
portability of a document, and may present patent problems for
implementation, since they are outside of the scope of this
specification. |
Specify a set of patent
free, portable video codecs as base, and whenever other codecs are used,
mark the document as “extended” (See comment for Part 1, Section
2.6) |
CO |
85 |
te |
2.3.3.19 |
261(268) |
The object element is
used for embedding inline objects. However the text says “The layout
properties of this embedded object are specified using the VML
syntax”. VML is in the specification for legacy reasons only (See
comment for 2.2.1). All OOXML consumers would need to support VML, even
where legacy documents are not present. |
Remove this element as
there is already an element in section 2.3.3.9 which can embed DrawingML
objects. |
CO |
86 |
te |
2.3.3.21 |
264(271) |
The object element is
used for embedding inline objects. However the text says “The layout
properties of this embedded object are specified using the VML
syntax”. VML is in the specification for legacy reasons only (See
comment for 2.2.1). All OOXML consumers would need to support VML, even
where legacy documents are not present. |
Remove this element as
there is already an element in section 2.3.3.9 which can embed DrawingML
objects. |
CO |
87 |
te |
2.4.7 |
302(309) |
This element uses a
bitmask to specify various table cell formatting properties. The use of
bitmasks rather than a set of boolean types makes this data almost
impossible to work with standard XML tools like XSLT which lack bit-level
operations. |
Rewrite this subclause
to express the feature using XML constructs rather than
bitmasks. |
CO |
88 |
te |
2.4.8 |
303(310) |
This element uses
bitmasks to specify various table row formatting properties. The use of
bitmasks rather than a set of boolean types makes this data almost
impossible to work with standard XML tools like XSLT which lack bit-level
operations. |
Rewrite this subclause
to express the feature using XML constructs rather than
bitmasks. |
CO |
89 |
te |
2.4.46 |
421(428) |
It is desired to have
improved interoperability between ODF and OOXML. However, OOXML lacks the
ability to specify a multi-row header that repeats across pages, where ODF
does. |
Include in this section
the ability to specify that the first N rows of a table can be selected as
a header. |
CO |
90 |
te |
2.4.51 |
428(435) |
This element uses a
bitmask to specify various table style formatting properties.. The use of
bitmasks rather than a set of boolean types makes this data almost
impossible to work with standard XML tools like XSLT which lack bit-level
operations. |
Rewrite this subclause
to express the feature using XML constructs rather than
bitmasks. |
CO |
91 |
te |
2.4.52 |
430(437) |
This element uses a
bitmask to specify various table style formatting exceptions. The use of
bitmasks rather than a set of boolean types makes this data almost
impossible to work with standard XML tools like XSLT which lack bit-level
operations. |
Rewrite this subclause
to express the feature using XML constructs rather than
bitmasks. |
CO |
92 |
te |
2.8.2.2 |
“0xEE”739(746) |
This value is said to
signify “an Eastern European character set”. There is no such thing.
First, “Eastern Europe” is not unambiguously delineated. Second, this
region uses many character scripts, including Roman, Cyrillic, Arabic,
Armenian, etc. |
Explain what is meant
by, “an Eastern European character set”. |
CO |
93 |
te |
2.8.2.2 |
739(746) |
The default character
set is said to be “the ANSI character set”. But ANSI has standards for
many character sets. Do you mean ANSI 209-1992 “Matrix Character Set for
OCR”? Probably not. So a normative reference to a specific standard is
required. |
Provide normative
reference for “the ANSI character set”. |
CO |
94 |
te |
2.8.2.16 |
758(765) |
Use of bit masks is not
the right way in XML. This element of the specification uses a set of
bitmasks to specify which code pages a given font supports. The use of
bitmasks rather than an XML Schema derived type makes this data almost
impossible to work with standard XML tools like XSLT which lack bit-level
operations. One of the advantages of XML is that we don't need to encode
data like this any more. |
Rewrite this subclause
to express the feature using XML constructs rather than
bitmasks. |
CO |
95 |
te |
2.15 |
1104(1111) |
The settings mechanism
is designed to accomodate Microsoft Office's particular settings only. The
mechanism is not extensible. |
Make the settings
mechanism extensible. |
CO |
96 |
te |
2.15.1.28 |
1158(1165) |
The algorithm given here
is new and has not undergone peer review. Even though this is an
application-enforced security feature, a strong known and tested algorithm
should be used. |
Use a recognized
standard cryptographic hash algorithm like SHA-256, Whirlpool,
etc. |
CO |
97 |
te |
2.15.1.28 |
1158(1165) |
It is stated that
document protection “shall be enforced”. “Shall”has been defined
previously as required behavior. A few lines later it says that document
protection “may be ignored”. |
Clarify this
contradiction. |
CO |
98 |
te |
2.15.1.28 |
1158(1165) |
This algorithm
description fails to specify the encoding of the input password. The
described algorithms make use of byte-level manipulations which depend on
the machine architecture (big endian versus little endian). 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. |
CO |
99 |
te |
2.15.1.29 |
1172(1179) |
This element allows the
classification of the document into one of three types: “letter”, “email”
or “general”. Although the description says that this feature can be used
by, “hosting applications to facilitate customized user interface and/or
automatic formatting behaviors based on the 'type' of a given
WordprocessingML document”, the taxonomy provided is so weak as to be
practically useless. |
Either provide a
reasonable document type taxonomy, or loosen the declared type to an
xsd:string to allow applications to provide their own
classifications. |
CO |
100 |
te |
2.15.1.86 |
1251(1258) |
This element uses a
bitmask to specify a style display filter. Use of bit masks is not the
right way in XML. |
Rewrite this subclause
to express the feature using XML constructs rather than
bitmasks. |
CO |
101 |
te |
2.15.1.87 |
1253(1260) |
This element uses a
bitmask to specify style display sorting parameters. The use of bitmasks
rather than a set of boolean types makes this data almost impossible to
work with standard XML tools like XSLT which lack bit-level
operations. |
Rewrite this subclause
to express the feature using XML constructs rather than
bitmasks. |
CO |
102 |
te |
2.15.2.32 |
1337(1344) |
The element
“optimizeForBrowser” only accomodates Internet Explorer and Netscape
Navigator. This section requires that “all settings which are not
compatible with the target web browser shall be disabled.” There is no way
to specify a standards compliant optimized output with PNG, MathML and
SVG. |
This clause should be
rewritten to express this feature in an application and platform neutral
way, allowing more versatility. |
CO |
103 |
te |
2.15.3.6 |
1378(1385) |
This is the
“autoSpaceLikeWord95” element is defined in terms of a particular
application's behavior. The standard contains insufficient detail on how
to replicate this behavior. |
Define the intended
behavior. |
CO |
104 |
te |
2.15.3.26 |
1416(1423) |
The
“footnoteLayoutLikeWW8” element, is defined in terms of a particular
application's behavior. The standard contains insufficient detail on how
to replicate this behavior. |
Define the intended
behavior. |
CO |
105 |
te |
2.15.3.31 |
1426(1433) |
The “lineWrapLikeWord6”
element, is defined in terms of a particular application's behavior.
The standard contains insufficient detail on how to replicate this
behavior. |
Define the intended
behavior. |
CO |
106 |
te |
2.15.3.32 |
1427(1434) |
The “mwSmallCaps”
element, is defined in terms of a particular application's behavior.
The standard contains insufficient detail on how to replicate this
behavior. |
Define the intended
behavior. |
CO |
107 |
te |
2.15.3.41 |
1442(1449) |
The “shapeLayoutLikeWW8”
element, is defined in terms of a particular application's behavior.
The standard contains insufficient detail on how to replicate this
behavior. |
Define the intended
behavior. |
CO |
108 |
te |
2.15.3.51 |
1462(1469) |
The
“suppressTopSpacingWP” element, is defined in terms of a particular
application's behavior. The standard contains insufficient detail on how
to replicate this behavior. |
Define the intended
behavior. |
CO |
109 |
te |
2.15.3.53 |
1467(1474) |
This is the
“truncateFontHeightsLikeWP6” element, which is defined in terms of
mimicking a legacy application's behavior. The standard contains
insufficient detail on how to replicate this behavior. |
Define the intended
behavior. |
CO |
110 |
te |
2.15.3.54 |
1469(1476) |
The “uiCompat97To2003”
element is defined as: “Disable UI functionality that is not compatible
with Word97-2003”. The standard must be application neutral. |
Define this an
application neutral way. If it is truly a Word-only feature, then remove
it from OOXML and express as an application-defined
extension. |
CO |
111 |
te |
2.15.3.63 |
1481(1488) |
The
“useWord2002TableStyleRules” element is defined in terms of a particular
application's behavior. The standard contains insufficient detail on how
to replicate this behavior. |
Define the intended
behavior. |
CO |
112 |
te |
2.15.3.64 |
1482(1489) |
The
“useWord97LineBreakRules” element is defined in terms of a particular
application's behavior. The standard contains insufficient detail on how
to replicate this behavior. |
Define the intended
behavior. |
CO |
113 |
te |
2.15.3.65 |
1483(1490) |
This is the “
wpJustification” element, which is defined in terms of mimicking a legacy
application's behavior. The standard contains insufficient detail on how
to replicate this behavior. |
Define the intended
behavior. |
CO |
114 |
te |
2.15.3.66 |
1485(1492) |
The “wpSpaceWidth”
element is defined in terms of a particular application's behavior. The
standard contains insufficient detail on how to replicate this
behavior. |
Define the intended
behavior. |
CO |
115 |
te |
2.16.4.3 |
1501(1508) |
The definition for
BATHTEXT references 'the given Thai format', which makes no sense in the
context of that definition. What “given Thai format”? |
Clarify the definition
of 'BATHTEXT'. |
CO |
116 |
te |
2.16.5.33 |
1537(1544) |
The field INCLUDEPICTURE
says that it merely retrieves the picture contained in the named document.
Is nothing else to be done with the picture? For example, should it be
displayed? |
Define what is to be
done with the picture once it is retrieved. |
CO |
117 |
te |
2.16.5.33 |
1537(1544) |
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 how pictures are
named. |
CO |
118 |
te |
2.16.5.33 |
1537(1544) |
No picture formats are
listed as valid. There may be undocumented of patented picture formats,
which will break portability of a document. |
Define a set of
documented and patent-free formats for pictures, and mark the document as
“extended” when a different one is used. See comment for Part 1, section
2.6) |
CO |
119 |
te |
2.16.5.34 |
1537(1544) |
This does not define how
a document to be passed to the INCLUDETEXT field 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. |
CO |
120 |
te |
2.16.5.34 |
1537(1544) |
The INCLUDETEXT field
“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. |
There should be
specified at least a small set of interoperable formats. Whenever this
element is used with a format not mandated by OOXML, an application must
mark the document as “extended” (see comment for Part 1, Section
2.6) |
CO |
121 |
te |
2.16.5.34 |
1537(1544) |
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. |
Provide a proper
external normative reference for the XSLT and Xpath versions which are
allowed here. |
CO |
122 |
te |
2.16.5.5 |
1512(1519){11-12} |
According to the text,
the AUTONUM field is deprecated. A new standard should not contain
deprecated parts. |
Remove all references to
AUTONUM from the OOXML text and make sure LISTITEM includes all
functionality necessary. The transforming application must handle
the conversion. |
CO |
123 |
te |
2.16.5.77 |
1570(1577) |
The example that
illustrates USERINITIALS section instead shows USERNAME. |
Correct the
example. |
CO |
124 |
te |
2.17.3 |
1622(1629) |
The external content
import elements in WordprocessingML put document interoperability at risk,
since not even a common ground is defined. Any application can put any
content (even the whole document in an application specific way) here and
the file can still be considered valid OOXML. |
It is necessary to set a
common ground for external content, or declare that applications using
this section are not OOXML comformant, to avoid misleading a user into
thinking that a particular OOXML file can be viewed correctly by any
application. One of OOXML's goals is interoperablity and application
independence. Whenever this element is used, an application must mark the
document as “extended” (see comment for Part 1, Section 2.6) |
CO |
125 |
te |
2.18.106 |
1837(1844) |
The length for the
element ”ST_UcharHexNumber” 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. |
Clarify the definition.
In particular note that xsd:hexBinary measure length in octets, not
characters. |
CO |
126 |
te |
2.18.4 |
1631(1638) |
The borders lack proper
definition, since no size, corner handling or additional files are given.
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. |
Define the borders in
detail. Provide an interoperable extensibility mechanism for a document
author or application to specify their own art border
graphics. |
CO |
127 |
te |
2.18.45 |
1737(1744) |
Length is said to be
“exactly 3 characters”. This is inconsistent with the example given which
has a length of 6 characters. |
Clarify the definition.
In particular note that xsd:hexBinary measure length in octets, not
characters. |
CO |
128 |
te |
2.18.46 |
1738(1745) |
The list of highlight
colors closely matches color codes in SVG 1.0 and ISO 15445, however there
are innecessary divergences in a few colors like "darkBlue", "darkCyan"
and "lightGray". Slight variations from widely used standards create
confusion and are a source of errors. |
Follow previous
standards and either reference SVG 1.0 or ISO 15445, or compile a list
that follows these standards |
CO |
129 |
te |
2.18.52 |
1748(1755) |
The use of a new set of
language codes, apart from ISO 639 and ISO 639-2, adds no value and only
increases the work required of any application that would process an OOXML
document. Applications which use their own values to represent
languages can easily convert from the standard language representation
system to the codes they use internally, and vice versa. |
Drop the use of the
redundant ST_LangCode |
CO |
130 |
te |
2.18.52 |
1748(1755) |
The type “ST_LangCode”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. |
Refine the definition of
this function, especially with respect to pre-metric measures so as to
remove ambiguity. |
CO |
131 |
te |
2.18.57 |
1759(1766) |
Type “ST_LongHexNumber”
is defined simultaneously as containing four hexadecimal digits, four
hexadecimal octets and exactly four characters. These definitions are not
compatible. A hexadecimal octet is two hexadecimal digits. |
Clarify the definition.
In particular note that xsd:hexBinary measures length in octets, not
characters. |
CO |
132 |
te |
2.18.66 |
1771(1778) |
The formatting system
described here (ST_NumberFormat) is not clear. It lacks 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. |
Use a more flexible,
extensible, generative approach to numeration, such as that used by the
W3C's XSLT standard in their xsl:number support |
CO |
133 |
te |
2.18.66 |
1771(1778) |
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. |
CO |
134 |
te |
2.18.66 |
“chicago”
1772(1779) |
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. |
CO |
135 |
te |
2.18.66 |
“decimalEnclosedFullstop” 1773(1780) |
The example given does
not show enclosed characters and so contradicts the normative
text. |
Reconcile the text and
the example. |
CO |
136 |
te |
2.18.66 |
“lowerLetter”,
etc. 1776(1783) |
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. |
CO |
137 |
te |
2.18.66 |
“numberInDash”, etc.
1776(1783) |
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. |
CO |
138 |
te |
2.18.72 |
1786 (1793) |
Length is said to be
“exactly 10 characters”. This is inconsistent with the example given which
has a length of 20 characters. |
Clarify the definition.
In particular note that xsd:hexBinary measure length in octets, not
characters. |
CO |
139 |
te |
2.18.85 |
1800 (1807) |
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? |
Provide full normative
definitions for these graphical elements. |
CO |
140 |
te |
2.18.86 |
1808(1815) |
The definition of type
“ST_ShortHexNumber” 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. |
Clarify the definition.
In particular note that xsd:hexBinary measure length in octets, not
characters. |
CO |
141 |
te |
3.2.7 |
1892(1899) |
There is no description
of the usage of the “ext” element. This elementa allows extending the
capabilities of SpreadsheetML, but this can break document
interoperability. |
Define and limit the
usage of the “ext” element or declare that applications using this element
are not OOXML comformant as one of OOXML's goals is interoperablity and
application independence. Whenever this element is used, an application
must mark the document as “extended” (see comment for Part 1, Section
2.6) |
CO |
142 |
te |
3.2.29 |
1917-1922 |
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. |
CO |
143 |
te |
3.2.29 |
1915(1922) |
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. |
Remedy so password
hashes can be calculated on any Unicode password. |
CO |
144 |
te |
3.2.29 |
1916(1923) |
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 (big
endian versus little endian). 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. |
CO |
145 |
te |
3.2.29 |
1916(1923) |
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? |
Clarify this processing,
especially for passwords that use characters from more than one
script. |
CO |
146 |
te |
3.2.29 |
1916(1923) |
A hash algorithm is
provided to secure passwords, 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. |
Use a standard, such
ISO/IEC 10118-3:2004, compliant hash algorithm as the default. Other
country specific standards could be acceptable such as FIPS-180 from NIST,
but additionaly to glbal standards . Legacy hash algorithms should be
supported via the described extension mechanism. |
CO |
147 |
te |
3.3.1.61 |
1987(1994)
“id” |
OOXML allows the
inclusion of binary data for printer settings (DEVMODE), which presents a
potential security risk. |
These configurations
should be expressed with proper XML, and since they are platform specific,
there should be proper definitions for each platform. |
CO |
148 |
te |
3.3.1.62 |
1987(1994)
“id” |
OOXML allows the
inclusion of binary data for printer settings (DEVMODE), which presents a
potential security risk. |
These configurations
should be expressed with proper XML, and since they are platform specific,
there should be proper definitions for each platform. |
CO |
149 |
te |
3.3.1.69 |
2003(2010) |
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. |
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. |
CO |
150 |
te |
3.3.1.69 |
2003(2010) |
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. |
CO |
151 |
te |
3.17 |
throughout |
Many of the financial
functions rely on a “date count basis” value that is not defined in this
standard. Without this level of definition implementors will not be able
to evaluate these functions (e.g. page 2534(2541) “basis”, 2535(2542)
“basis”) . |
Provide a full
definition of “day count basis”, in particular with respect to treatment
of leap years and leap days. |
CO |
152 |
te |
3.17 |
throughout |
The mathematical formula
graphic given in many places borders on unreadable and compares very
poorly with the clarify of the rest of the text and most other images
(e.g. page 2552(2559) line 1, line 3). |
Provide better quality
mathematical formula graphics. |
CO |
153 |
te |
3.17.3 |
“#DIV/0!”
2521(2528) |
The “note” for this
error value appears to define required behavior, not informative
remarks |
Make the contents of the
note be part of the main text, not as a note. |
CO |
154 |
te |
3.17.4.1 |
2522(2529) |
In the 1900 date base
system, the lower limit is January 1, 1900, which is too recent. |
Allow negative date
serial values to express dates prior to 1900 or define a system which
starts at an earlier date (e.g. 1 A.D.). |
CO |
155 |
te |
3.17.4.1 |
2522(2529) |
OOXML mandates wrong
data calculations when the 1900 date system is used. |
For legacy
considerations, introduce an compatibility tag such as
“doLegacySpreadhseetDateCalculations” instead of forcing applications to
perform wrong calculations. |
CO |
156 |
te |
3.17.4.1 |
2522(2529) |
Two base systems are
given, and while one is necessary for legacy compatibility, the second one
introduces unnecesary restrictions like no dates before 1904. Processing
dates before this year are a necessity in many applications. |
Remove the 1904 date
base system and replace with a system that begins at an earlier date, e.g.
0 A.D. |
CO |
157 |
te |
3.17.4.2, 3.17.4.3,
3.17.6.7 |
|
It is insufficient to
represent times simply as a numeric value without timezone
information. |
Specify that when stored
in OOXML files, dates and times are always expressed in terms of UTC. Add
a mechanism for storing in the file information on what timezone should be
used to represent the time in human-readable form. |
CO |
158 |
te |
3.17.6.7 |
2529(2536) |
This calls for the date
serial number to be stored, “as accurately as possible”. This requirement
is not precise and is untestable. |
State the minimum
precision required. |
CO |
159 |
te |
3.17.7.4 |
ACOS
2536(2543) |
It is not indicated
whether the returned value shall be in radians or degrees |
Specify the angular
units that should returned |
CO |
160 |
te |
3.17.7.9 |
AND 2541(2548) |
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 FALSE?
Since some functions have side effects, it is necessary to define this in
order to ensure interoperability. |
Specify whether this
function allows short-circuit evaluation. |
CO |
161 |
te |
3.17.7.11 |
ASC 2542(2549) |
This function converts a
DBCS string to “half-width (single byte)” characters. But the mapping from
DBCS to single byte. is undefined. What is intended here? Truncation?
Conversion into nearest single byte character set? |
Provide a fuller
definition of this function. |
CO |
162 |
te |
3.17.7.12 |
ASIN
2542(2549) |
It is not indicated
whether the returned value shall be in radians or degrees |
Specify the angular
units that should returned |
CO |
163 |
te |
3.17.7.14 |
ATAN 2544
(2551) |
It is not indicated
whether the returned value shall be in radians or degrees |
Specify the angular
units that should returned |
CO |
164 |
te |
3.17.7.15 |
ATAN2 2544
(2551) |
It is not indicated
whether the returned value shall be in radians or degrees |
Specify the angular
units that should returned |
CO |
165 |
te |
3.17.7.17 |
AVEDEV
2545(2552) |
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. |
Provide a correct
example. |
CO |
166 |
te |
3.17.7.17 |
AVEDEV
2545(2552) |
The function description
has a typo/duplication: “cells with the value 0value 0” |
Fix the typographical
error |
CO |
167 |
te |
3.17.7.34 |
CELL 2560
(2567) |
The list of values
supported for the “format” argument is far shorter than the list of
possible numeric formats. What happens if CELL(“format”, A1) is called on
a cell with a format not on this list? |
Specify what happens in
this case, or define a new type to avoid these cases. |
CO |
168 |
te |
3.17.7.35 |
CHAR
2563(2570) |
This function maps
between numbers and characters. But this mapping must be defined by a
character set and none is defined here. |
Specify what character
set is used for this mapping (ASCII?). |
CO |
169 |
te |
3.17.7.37 |
CHIINV
2564(2571) |
This function says,
“CHIINV uses an iterative search technique”. This is specifying an
implementation, not a testable performance criterion. Other approaches
should be permitted. |
Keep the suggestions,
but put them in informative Notes or Guidance. |
CO |
170 |
te |
3.17.7.38 |
CHITEST 2565 (2572) |
The definition of this
function says the the results are “unspecified” if the two ranges do not
have the same number of points. But isn't this a clear argument error
where should be returned? Surely we can document what Excel does
here? |
Specify the required
results for the case where the two ranges are of unequal
size. |
CO |
171 |
te |
3.17.7.47 |
CONFIDENCE
2571(2578) |
This function cannot be
calculated without making an assumption about the distribution of the
data? Are we assuming normally distributed data? uniformly distributed
data? |
Make the distribution
assumptions explicit. |
CO |
172 |
te |
3.17.7.48 |
CONVERT
2572(2579) |
This function is
ambiguously defined, especially with regards to the traditional units of
measure. For example, a tablespoon is 15ml in the US, but 20ml in
Australia. Which is meant here? Similarly, a cup is defined differently in
various countries, e.g. 8 oz in US, except the FDA defines it for food
labeling purposes as 240ml, while it is 250ml in Australia and 285ml in
the UK. Also, the unit Pica is oncorrectly defined as 1/72 inch when it
should be 1/72 foot. |
Refine the definition of
this function, especially with respect to pre-metric measures so as to
remove ambiguity. |
CO |
173 |
te |
3.17.7.49 |
CORREL
2576(2583) |
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. |
Correct the
text |
CO |
174 |
te |
3.17.7.50 |
COS 2577
(2584) |
It is not indicated
whether the parameter is in radians or degrees |
Specify the angular
units that this parameter is in |
CO |
175 |
te |
3.17.7.65 |
CUBEKPIMEMBER 2590(2597) |
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 |
CO |
176 |
te |
3.17.7.65 |
CUBEKPIMEMBER 2590(2597) |
The definition of this
function says that it retrieves an OLAP Cube from a “SQL Server”. Surely
this function is not limited to use only against Microsoft database
servers? |
Provide a vendor-neutral
definition of this function. |
CO |
177 |
te |
3.17.7.66 |
CUBEMEMBER
2591(2598) |
A multidimensional
expression (MDX) that evaluates to a unique member in the cube”. But MDX
is undefined. |
Define the syntax and
semantics of an MDX |
CO |
178 |
te |
3.17.7.74 |
DATE
2600(2607) |
The definition of date
normalization is rather loose. I think you want to say something like
this; month is greater than 12, then month-12 shall be added to the first
month in the year specified.”, etc. The problem with how it is stated is
that “that” does not refer to anything in “that number of
months”. |
Clarify the definition
of date normalization. |
CO |
179 |
te |
3.17.7.76 |
DATEVALUE
2603(2610) |
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 ommitted, 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”? Do we assume the current date? of the
current year? |
Resolve the ambiguity in
the definition when a string with time format is passed in. |
CO |
180 |
te |
3.17.7.77 |
DAVERAGE 2603(2610) |
Normative information
regarding the processing of “an entire column in a database” is placed in
an informative note. Since it is clearly stating a requirement in the
processing this should be in the normative text. |
Rework the note into the
normative description of this function. |
CO |
181 |
te |
3.17.7.78 |
DAY
2605(2612) |
The function does not
define what a “Gregorian day” is, nor why it would be different in the
1900 versus 1904 date bases for a date in 1982. Is this just returning the
day of the month? Why would this function return two values for that in
1982? |
Define fully what this
function returns. |
CO |
182 |
te |
3.17.7.91 |
DISC 2616(2623) |
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) |
CO |
183 |
te |
3.17.7.95 |
DOLLARDE 2619(2626) |
This function is
ambiguously defined. Specifically we need to know how many decimal digits
we need to look at to determine the numerator of the fraction. The example
given DOLLARDE(1.02,16) = 1+ 2/16. But what about, after a serious of
calculations and in the presence of accumulated floating point error we
have DOLLARDE(1.020000001, 16)? Is this now 1 + 20000001/16? or 1,250,001?
Also the definition is worded incorrectly. The first parameter is not “a
number expressed as a fraction.” It is “a numbered interpreted as a
fraction”. Also, the information marked as “Note” seems to be the most
critical part of the definition and so should be part of the normative
material. |
Clarify how this
function works |
CO |
184 |
te |
3.17.7.96 |
DOLLARFR
2620(2627) |
The information marked
as “Note” seems to contain the only definition of what this function
actually should do, so it should be made part of the normative
material. |
Rework the note into the
normative description of this function. |
CO |
185 |
te |
3.17.7.101 |
DURATION 2623(2630) |
The function is defined
in terms of $100 par value, but there is nothing about the bond
calculations that is inherently tied to the US Dollar. |
Recommend the use of the
generic currency sign here (U+00A4) |
CO |
186 |
te |
3.17.7.111 |
EXACT
2631(2638) |
String comparisons in an
international setting are typically described as either lexical
comparisons where the strings are compared character by character for
identity, and by collation comparisons where equivalent characters are
considered identical. This function does not say which method it
uses. |
Clarify what defines two
strings as having identical content. |
CO |
187 |
te |
3.17.7.118 |
FIND
2636(2643) |
Similar issue to EXACT.
Is this a lexical comparison or collation-based? |
Clarify the basis for
finding substrings |
CO |
188 |
te |
3.17.7.119 |
FINDB
2637(2644) |
Similar issue to EXACT.
Is this a lexical comparison or collation-based? |
Clarify the basis for
finding substrings |
CO |
189 |
te |
3.17.7.120 |
FINV
2638(2645) |
This function says,
“FINV uses an iterative search technique”. This is specifying an
implementation, not a testable performance criterion. Other approaches
should be permitted. |
Keep the suggestions,
but put them in informative Notes or Guidance. |
CO |
190 |
te |
3.17.7.123 |
FIXED
2640(2647) |
The rounding algorithm
is not specified. How for example, do we calculate FIXED(0.5,0)? Round up,
round down? |
State what the rounding
conventions are. |
CO |
191 |
te |
3.17.7.131 |
GAMMAINV2646(2653) |
This function says,
“GAMMAINV uses an iterative search technique”. This is specifying an
implementation, not a testable performance criterion. Other approaches
should be permitted. |
Keep the suggestions,
but put them in informative Notes or Guidance. |
CO |
192 |
te |
3.17.7.144 |
HYPERLINK
2658(2665) |
The definition says that
an allowed format for the link-location parameter is a “universal naming
convention (UNC) path on a server”, though this term is not
defined. |
Provide a normative
definition or reference for a UNC path. |
CO |
193 |
te |
3.17.7.186 |
KURT
2690(2697) |
Definition is
incomplete. Formulas don't stand for themselves. You need to connect the
notation to the function arguments. So, as stated, “where s is the sample
standard deviation”, but it should be followed by, “and n is the number of
data points in the range, and X-bar is the sample mean” |
Provide the complete
definition. |
CO |
194 |
te |
3.17.7.201 |
LOWER
2704(2111) |
This function is
ambiguous. Is it asking for a lexical, character by character conversion
to lowercase? Or for a whole-word conversion? For example, Greek capital
Sigma has two lower case forms, one reserved for use as the terminal
letter in a word. As written, it is not clear whether this function should
be implemented to take that into consideration or not. |
Clarify what it means to
convert to lower case. |
CO |
195 |
te |
3.17.7.206 |
MDURATION
2708(2715) |
The function is defined
in terms of $100 par value, but there is nothing about the bond
calculations that is inherently tied to the US Dollar. |
Recommend the use of the
generic currency sign here (U+00A4) |
CO |
196 |
te |
3.17.7.207 |
MEDIAN
2709(2716) |
The text currently says,
“If there is an even number of numbers in the set, MEDIAN calculates the
average of the two numbers in the middle”. This is ambiguous. Middle of
what? Middle of the range is the most direct interpretation. Probably want
something more like, “The values in the range are logically ranked from
lowest to highest and the middle number is returned. If there is an even
number of numbers in the set...” |
Clarify the
definition. |
CO |
197 |
te |
3.17.7.227 |
NORMINV
2724(2731) |
This text says, “NORMINV
uses an iterative search technique”. This is specifying an implementation,
not a testable performance criterion. Other approaches should be
permitted. |
Keep the suggestions,
but put them in informative Notes or Guidance. |
CO |
198 |
te |
3.17.7.229 |
NORMSINV
2726(2733) |
This text says,
“NORMSINV uses an iterative search technique”. This is specifying an
implementation, not a testable performance criterion. Other approaches
should be permitted. |
Keep the suggestions,
but put them in informative Notes or Guidance. |
CO |
199 |
te |
3.17.7.243 |
OR 2741(2748) |
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. |
Specify whether this
function allows short-circuit evaluation. |
CO |
200 |
te |
3.17.7.282 |
SEARCH/SEARCHB
2774(2781) |
Is this a lexical
comparison or collation-based search? |
Clarify the basis for
string comparisons |
CO |
201 |
te |
3.17.7.287 |
SIN 2777(2784) |
It is not indicated
whether the parameter is in radians or degrees |
Specify the angular
units that this parameter is in |
CO |
202 |
te |
3.17.7.313 |
TAN 2797(2804) |
It is not indicated
whether the parameter is in radians or degrees |
Specify the angular
units that this parameter is in |
CO |
203 |
te |
3.17.7.344 |
WORKDAY
2821(2828) |
This function is defined
to skip over weekends in its calculations, but weekend is not defined and
has different definitions in different parts of the world. |
Define this function
unambiguously and preferably in a way which provides for cultural
adaptability in the definition of a weekend. |
CO |
204 |
te |
3.17.7.348 |
YEARFRAC
2826(2833) |
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. |
CO |
205 |
te |
3.18.86 |
2929(2936) |
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. |
Clarify the definition.
In particular note that xsd:hexBinary measure length in octets, not
characters. |
CO |
206 |
te |
4.3.1.35 |
2994(3001) |
The element "smartTags"
is insufficiently defined for DrawingML. Is the behavior equivalent to the
behavior in WorprocessingML? |
Define the behavior of
smart tags for DrawingML |
CO |
207 |
te |
4.6.9 |
3083(3090) |
The audio codecs allowed
for the “audio” element are not specified. There are many propietary and
non-portable codecs which would break portability of a document. |
Define a set of
patent-free portable audio codecs as base. Whenever other codecs are used,
the document must be marked as “extended” (see comment for Part 1, Section
2.6) |
CO |
208 |
te |
4.6.68 |
2994(3001) |
The audio codecs allowed
for the “snd” element are not specified. There are many propietary and
non-portable codecs which would break portability of a document. |
Define a set of
patent-free portable audio codecs as base. Whenever other codecs are used,
the document must be marked as “extended” (see comment for Part 1, Section
2.6) |
CO |
209 |
te |
4.6.69 |
2994(3001) |
The audio codecs allowed
for the “sndAc” element are not specified. There are many propietary and
non-portable codecs which would break portability of a document. |
Define a set of
patent-free portable audio codecs as base. Whenever other codecs are used,
the document must be marked as “extended” (see comment for Part 1, Section
2.6) |
CO |
210 |
te |
4.6.70 |
2994(3001) |
The audio codecs allowed
for the “sndTgt” element are not specified. There are many propietary and
non-portable codecs which would break portability of a document. |
Define a set of
patent-free portable audio codecs as base. Whenever other codecs are used,
the document must be marked as “extended” (see comment for Part 1, Section
2.6) |
CO |
211 |
te |
4.6.93 |
3159(3166) |
The video codecs allowed
for the “video” element are not specified. There are many propietary and
non-portable codecs which would break portability of a document. |
Define a set of
patent-free portable video codecs as base. Whenever other codecs are used,
the document must be marked as “extended” (see comment for Part 1, Section
2.6) |
CO |
212 |
te |
5 |
throughout |
The new unit EMU
(English metric units) is never properly defined and used in several
places. e.g. Sections 5.1.12.42, 5.1.5.1.1, 5.1.12.16. |
Produce a proper
definition of EMU, clearly referenced when it is used, or use a standard
unit of measure. |
CO |
213 |
te |
5.1.5.2.3 |
3388(3395) |
Smart tags are mentioned
but they are not described elsewhere in the VML specification |
Define the behavior of
smart tags for VML |
CO |
214 |
te |
5.1.5.3.2 |
3413(3420) |
Smart tags are mentioned
but they are not described elsewhere in the VML specification |
Define the behavior of
smart tags for VML |
CO |
215 |
te |
5.1.12.28 |
3700(3707) |
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. |
Clarify the definition.
In particular note that xsd:hexBinary measure length in octets, not
characters. |
CO |
216 |
te |
5.1.12.37 |
3719(3726) |
The Panose value is said
to be used, “so that generating applications using this Office Open XML
Standard may determine the closest font type if necessary”. However, no
font distance metric or font matching heuristic is described. |
Describe the intended
font matching procedure. |
CO |
217 |
ge |
5.1.12.37 |
3719(3726) |
Why are there several
different definitions for a Panose value, both in Word Processing ML as
well as Drawing ML? |
Since they are exactly
the same they should be defined once in a shared schema. |
CO |
218 |
te |
5.1.12.37 |
3719(3726) |
Length is said to be
“exactly 10 characters”. This is inconsistent with the schema fragment
given which defines it as being 10 octets long. |
Clarify the definition.
In particular note that xsd:hexBinary measure length in octets, not
characters. |
CO |
219 |
te |
5.1.3.2 |
3292(3299) |
The audio codecs allowed
for the “audioFile” element are not specified. There are many propietary
and non-portable codecs which would break portability of a
document. |
Define a set of
patent-free portable audio codecs as base. Whenever other codecs are used,
the document must be marked as “extended” (see comment for Part 1, Section
2.6) |
CO |
220 |
te |
5.1.3.4 |
3294(3301) |
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. Since Quicktime is a propietary technology not
covered within this specification, must cause the docuement to be marked
as “extended” (See comment for Part 1, Section 2.6) |
CO |
221 |
te |
5.1.3.6 |
3296(3303) |
The video codecs allowed
for the “videoFile” element are not specified. There are many propietary
and non-portable codecs which would break portability of a
document. |
Define a set of
patent-free, portable video codecs as base. Whenever other codecs are
used, the document must be marked as “extended” (see comment for Part 1,
Section 2.6) |
CO |
222 |
te |
5.1.3.7 |
3297(3304) |
The attribute “builtIn”
specifies whether a sound is builtIn and is to be reference by name only
and not included within the file. Since no list of built-in audio files is
given, this will break a document's portabilty, as no application but the
creator will posses certain audio files. |
For the sake of
portabilty, this attribute should be removed. If this is not desired,
provide a list and set of built-in audiofiles. As a last option, documents
using this attribute should be marked as “extended” (see comments for Part
1, Section 2.6) |
CO |
223 |
te |
Section 6 |
4343(4350) |
OOXML specifies here a
markup language called Vector Markup Language (VML) which, in addition to
DrawingML, specifies a vocabulary for describing graphical objects.
Section 6.1 says, “The DrawingML format is a newer and richer format
created with the goal of eventually replacing any uses of VML in the
Office Open XML formats. VML should be considered a deprecated format
included in Office Open XML for legacy reasons only and new applications
that need a file format for drawings are strongly encouraged to use
preferentially DrawingML” The need to support VML by OOXML consumers, in
addition to DrawingML, would come at great implementation expense (the VML
specification is over 600 pages) , would disadvantage all vendors but
Microsoft, and would hurt interoperability. |
Remove VML from OOXML
and use DrawingML instead. If needed add special legacy features in
DrawingML. |
CO |
224 |
te |
6.1.2.7 |
4444(4451),
“tableproperties” |
This element uses a
bitmask to specify VML table properties. The use of bitmasks rather than a
set of boolean types makes this data almost impossible to work with
standard XML tools like XSLT which lack bit-level operations. |
Rewrite this subclause
to express the feature using XML constructs rather than
bitmasks. |
CO |
225 |
te |
6.1.2.19 |
4643 (4650) |
The "equationxml"
attribute of the "shape" element is "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". This makes
interoperability impossible when this element is present. |
It is suggested that
this element, for the sake of interoperability, not be made extensible. If
it is considered absolutely necessary it would be preferable to create a
separate element, e.g. "alternateequationxml", and mark the document as
“extended” (see comment for Part 1, Section 2.6) |
CO |
226 |
te |
6.1.2.19 |
4653 (4660) |
The "gfxdata" is defined
as an encoded package whose contents are application defined. This lack of
definition breaks interoperability as content placed here by an
application may not be understood by another one. |
It is suggested that
this element, for the sake of interoperability be limited to a particular
package type. If extensibilty is desired in this case mark the document as
“extended” (see comment for Part 1, Section 2.6) |
CO |
227 |
te |
6.4.2.10 |
4653 (4660) |
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. |
CO |
228 |
te |
6.4.3.1 |
4955(4962) |
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. |
Make standard neutral by
adding options for other relevant platforms. The desire is to allow cross
platform interoperability and efficiency. |
CO |
229 |
te |
7.1 |
4961(4968) |
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. |
It is recommended that
this section be removed from OOXML and that the proposers of OOXML work
within the W3C's MathML activity, where MathML 3.0 is currently being
drafted, to produce a single standard for equations that can be used later
referenced by a future version of OOXML. |
CO |
230 |
te |
7.1 |
4961(4968) |
OOXML is not compatible
with the industry standard language for displaying mathematical equations
— MathML — used by the research community and the most important
publications as Science, Nature, etc... . No interoperability with MathML
is in the OOXML specifications. |
Add the pertinent
interoperability with MathML |
CO |
231 |
te |
7.4.2.4 |
5122(5129) |
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. |
CO |
232 |
te |
7.4.2.4 |
5122(5129) |
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 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.” |
Remove the bstr type
from OOXML |
CO |
233 |
te |
7.4.2.5 |
5122(5129) |
It doesn't make sense to
specify 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. |
The entire Clipboard
Data representation needs thought. It looks very much like it is mapping
directly to the arbitrary internals of a single application. This clause
should be rewritten to express this feature in an application and platform
neutral way. |
CO |
234 |
te |
7.4.2.5 |
5122(5129) |
This element defines
usage on Windows and Macintosh platforms only, but it doesn't specify
whether OS 9 or OS X, and leaves out other important operating systems
like Linux. |
Make standard neutral,
defining values for other prominent systems. |
CO |
235 |
te |
7.4.2.5 |
5122(5129) |
There is not enough
information about the contents and their usage to provide
interoperability. If these are binary blobs, they may present a security
risk. |
Expand section to
provide interoperability, and consider using XML syntax. |
CO |
236 |
de |
7.5.2.1 |
5140(5220) |
The address at www.contoso.com points to the
Microsoft Office product page. |
Use a neutral
example. |
CO |
237 |
te |
throughout |
throughout |
The naming of elements
is very inconsistent. Even though the choice of one letter for common
elements seems appropriate, there seems to be no common technique for
naming. The capitalization and vowel removal is inconsistent, as there are
elements with names like: (from, but not limited to, Part 4 Section
2.15.1): ActiveWritingStyle, attachedSchema, documentType, docVars,
endnotePr, hdrShapeDefaults) . This is not a problem with the
clarity of the specification, but it complicates the implementation of it
unnecessarily, as developers will need to refer more often than necessary
to the document to check for a certain element's particular
spelling. |
Use a common element
naming system |
|
|
|
|
|
|
|
Some of the
wording for the comments is taken from the comments by AENOR and
BSI. |
|