National Committee |
Clause |
Paragraph/ Figure/Table |
Type of comment (General/Technical
/Editorial) |
COMMENTS |
Proposed Change |
OBSERVATIONS OF THE
SECRETARIAT |
|
Office Open XML Overview |
|
ge |
The document does not indicate whether the zip
files are normative or informative |
Either have an index of zip files that will
describe the contents and whether the zip file is informative or normative
or each zip file should contain a comment line indicating whether it is
normative or informative |
|
|
Part 1, Annex A |
|
te |
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/or labelled version. |
|
|
Part 1, Foreword |
|
ed |
DIS 29500 is a multi-part document, not a
multi-part Standard, i.e., the individual parts of this Standard are not
themselves standards. |
Correct the terminology to correctly reflect
the status of DIS 29500. |
|
|
Part 1, Section 11.3.1 |
lines 15-17 |
ed |
This is requiring that a conforming OOXML
consumer also be able to understand a specified list of other document
formats, including proprietary ones such as MHTML and RTF, and for
conforming producers to understand how to convert these formats to
OOXML. |
Make it clear that the consumer does not need
to know these formats |
|
|
Part 1, Section 15.2.15 |
|
ed |
For there to be interoperability of this
feature, it must either specify what size the thumbnail should be or state
that the application will scale the image as needed. |
Clarify what size the thumbnails should be, or
that the images are scaled. |
|
|
Part 1, Section 15.2.6 |
|
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? |
The phrase "This part shall have no contents"
means that a part shall be created, but it shall have no contents (meaning
it would be a zero byte file). |
|
|
Part 1, Section 15.2.8 |
|
ed |
The examples given are rendered useless by the
predominance of the VML in the markup. |
Make a more succinct and clear example by
concentrating on the control persistence. |
|
|
Part 1, Section 2.1 “Goal” |
|
ge |
There are no normative statements in this
clause, though Section 2 is indicated to be normative |
Mark clause as informative using one of the
mechanisms of Section 7 |
|
|
Part 1, Section 2.2 “Issues” |
|
ge |
There are no normative statements in this
clause, though Section 2 is indicated to be normative |
Mark clause as informative using one of the
mechanisms of Section 7 |
|
|
Part 1, Section 2.3 |
Line 14 |
ed |
Are additional syntactic constraints only
normative when the cannot be feasibly expressed in the schema language?
Who judges this? The use of the word “whenever” is ambiguous.
Is this a condition under which such statements are normative or an
explanation of why such statements exist? |
The section 2.3: "What this standard
specifies", line 14 specifies that if the schema language used in
this standard cannot feasibly express all the syntactic constraints,
then those constraints are provided in written form. Such expressions are
normative. The application that implements this standard will judge
if the additional syntactic constraints are normative or not. The
editorial comment which explains why this statement is appropriate is
useful to the reader and does not detract from the value of this
statement. |
|
|
Part 1, Section 2.3 |
Line 16 |
ed |
The use of the word “element” is
ambiguous. Is this to mean XML elements (but not attributes,
character content, etc.)? Or does this mean an element of the
Standard, in the usage of ISO Directives, Part 2? |
Clarify the use of the word “element” perhaps
by saying “XML element” if that is what is meant. |
|
|
Part 1, Section 2.4 |
Line 22 |
ed |
This line require 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. Which is it? |
Unicode should be referenced consistently
throughout the document |
|
|
Part 1, Section 2.6 |
|
ed |
The use of the word “element” is
ambiguous. Is this to mean XML elements (but not attributes,
character content, etc.)? Or does this mean an element of the
Standard, in the usage of ISO Directives, Part 2? |
Clarify the use of the word “element” perhaps
by saying “XML element” if that is what is meant. |
|
|
Part 1, Section 2.6 |
Line 15 |
ed |
Obviously the Standard anticipates such
behavior since it explicitly contains the present example describing this
behavior and calls it conforming. |
Perhaps it is meant to say, “...this Standard
does not recommend this behavior”. |
|
|
Part 1, Section 2.6 |
Lines 33-34 |
ed |
Is this recommending that a non-public,
internal-only, work-for-hire application author create “publicly available
documentation” on what subset of the standard it supports? The business
relationship between the software author and his customer should not be a
concern of this standard. |
Change to read, “a software application should
be accompanied by documentation...” |
|
|
Part 1, Section 9.1.1 |
|
ed |
ASCII requires a normative reference since
there are several national variations. |
Suggest reference be made to a standard e.g.
ISO/IEC 646:1983 to avoid ambiguity |
|
|
Part 1, Section 9.1.5 |
|
ed |
This sub-clause, buried in introductory
material, negates a provision of the more detailed OPC specification in
Part 2. This will likely be missed by implementors. |
If interleaving is not permitted then it
should not be described in Part 2. |
|
|
Part 2, Section 3 |
Page 4, line 20 |
ed |
This definition of 'package model' is not
compatible with the prior definition given in Part 2, Section 1. Scope,
page 1, line 5. |
Define 'package model' in unambiguous terms
and use the resulting definition consistently throughout the OOXML
text. |
|
|
Part 4, Introduction |
Page vii, line 8 |
ed |
An XML markup cannot be “fully compatible”
with an “investment” |
Remove the word “investment” |
|
|
Part 4, Section 2.15.1.28 |
|
ed |
This says that document protection “shall be
enforced”. “Shall” indicates required behavior. But then a few
sentences later it says that document protection “may be ignored”.
|
This protection is not intended as a security
feature and may be ignored.” From the above paragraph, we
understand that the context in which the phrase “shall be enforced” is
used, then it means that if the attribute is turned on, then the
restrictions will be imposed. The context in which the phrase “may
be ignored” is used, then it means that the protection does not encrypt
the document, malicious applications may circumvent its use and so this
can be ignored as a security feature. The two phrases
mentioned are used in two different contexts and are appropriated in their
respective context.
This information should be marked as
informative |
|
|
Part 4, Section 2.15.1.28 |
Line 16 |
ed |
What if the entered password is shorter than
15 characters? Do we truncate to the actual length? Or fill
with 0's? Or something else? |
Clarify this processing step. |
|
|
Part 4, Section 2.15.1.28 |
pg 1159, lines 6-9 |
ed |
The described processing steps are not
ambiguous. In particular SHR and SHL give different results on
different machines and with signed and unsigned values |
Describe the hash algorithm in a platform
independent manner. |
|
|
Part 4, Section 2.15.2.32 |
|
te |
This feature has been defined in a way which
ignores the existence of current browsers other than Internet
Explorer. What about Firefox? What about Safari? What
about 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.” But what if I want my
application to produce standards-compliant output? So yes to PNG, no
to VML, yes to MathML and SVG? I can't seem to specify
this. |
Provide definitions of each of the elements,
make the current table an example (not part of the definition). Give
examples of other current browsers. |
|
|
Part 4, Section 2.15.3 |
Entire clause |
te |
These “compatibility” settings solve no
general problem. They are merely a museum of settings from previous
versions of Microsoft Word. No allowance has been made for legacy
settings from other applications. Better to have these be
application-specific settings using the existing extensibility mechanisms
of OOXML. |
It is proposed to move the whole of this
clause to an informative annex. Each feature should either be documented
or referenced for proper implementation. Other manufacturers should be
allowed to add their own compatibility issues to this proposed
annex. |
|
|
Part 4, Section 2.16.4.3 |
page 1501, line 0 |
te |
The definition for BATHTEXT references 'the
given Thai format', which makes no sense in the context of that
definition. What “given Thai format”? |
The switch argument is used for number
formatting.The definition completely makes sense,which means that the
switch argument formats the number in 'Thai' format.Hence 'thaiCounting'
is its ST_NumberFormat equivalent,as in the section 2.18.66,Page Number
1777.Since the fields require both text and numeric formatting ,a switch
argument is provided in context of the fields so that data formatting
becomes more developer friendly. |
|
|
Part 4, Section 2.16.5.33 |
|
te |
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 the syntax for the field
value |
|
|
Part 4, Section 2.16.5.34 |
|
te |
This does not define how a document 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. |
|
|
Part 4, Section 2.16.5.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. |
Text to be clarified |
|
|
Part 4, Section 2.16.5.40 |
|
ed |
The definition for 'LISTNUM' is built upon the
concepts of 'current' or 'specific' or 'next series', which are not
defined in this context (a backward search on 'series' shades no light on
this). Those concepts should be defined in the text, and their definition
should either be copied or referenced in the context of the definition for
'LISTNUM'. |
Expand or reference the definition for
'series', and/or clarify the definition for 'LISTNUM' by any appropriate
means. |
|
|
Part 4, Section 2.16.5.5 |
page 1512, lines 11-12 |
te |
According to the text, the AUTONUM field is
deprecated. A new standard should not contain deprecated parts. |
More information supporting the use of AUTONUM
is required |
|
|
Part 4, Section 2.16.5.77 |
|
ed |
The example that illustrates USERINITIALS
section instead shoes USERNAME. |
Correct the example.. |
|
|
Part 4, Section 2.18.106 |
|
ed |
Length 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. |
Look through the document and make sure the
reference is consistent |
|
|
Part 4, Section 2.18.4 |
|
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? Also, some of the images, such as 'apples' or
'balloons3Colors' show copying artifacts, where extraneous lines or
blotches appear. |
Provide graphic elements as a separate
collection e.g. zipped |
|
|
Part 4, Section 2.18.4 |
|
te |
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. |
Provide an interoperable extensibility
mechanism for a document author or application to specify their own art
border graphics. |
|
|
Part 4, Section 2.18.45 |
|
ed |
Length is said to be “exactly 3
characters”. This is inconsistent with the example given which has a
length of 6 characters. |
Look
through the document and make sure the use is consistent |
|
|
Part 4, Section 2.18.51 |
|
te |
The use of 255 enumerated language codes, in
addition to ISO 639-1 codes, adds no expressive value and only increases
the work required of any application that would process an OOXML
document. |
Drop the use of the redundant
ST_LangCode |
|
|
Part 4, Section 2.18.52 |
|
ed |
This type 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. |
Look through the document and make sure the
use is consistent |
|
|
Part 4, Section 2.18.57 |
|
ed |
The description of this type says it contains
four hexadecimal digits, four hexadecimal octets and exactly four
characters. These definitions are not compatible. A
hexadecimal octet is two hexadecimal digits. |
Look through the document and make sure the
use is consistent |
|
|
Part 4, Section 2.18.66 |
|
ed |
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? |
More clarification required |
|
|
Part 4, Section 2.18.66 |
“chicago” |
ed |
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. |
|
|
Part 4, Section 2.18.66 |
“decimalEnclosedFullstop” |
ed |
The example given does not show enclosed
characters and so contradicts the normative text. |
Reconcile the text and the example. |
|
|
Part 4, Section 2.18.66 |
“lowerLetter”, etc. |
ed |
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. |
|
|
Part 4, Section 2.18.66 |
“numberInDash”, etc. |
ed |
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. |
|
|
Part 4, Section 2.18.72 |
|
ed |
Length is said to be “exactly 10
characters”. This is inconsistent with the example given which has a
length of 20 characters. |
Look through the document and make sure the
use is consistent |
|
|
Part 4, Section 2.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? |
Graphics to be included in a separate
collection e.g. zipped |
|
|
Part 4, Section 2.18.86 |
|
ed |
The description of this type 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. |
Look through the document and make sure the
use is consistent |
|
|
Part 4, Section 2.2.1 |
page 28, line 0 |
te |
The reference to the
urn:schemas-microsoft-com:vml namespace references VML, which is
considered as deprecated (Part 4, page 4343, lines 11&12). A new
standard should not contain deprecated parts. |
Move all references to VML to an informative
annex. We strongly advise that DrawingML replaces all functionalities of
VML and VML be eliminated from the specification. |
|
|
Part 4, Section 2.2.1 |
page 28, line 0 |
te |
Child elements of background are described
using deprecated features only. Accordingly, the background element should
either be described in terms of current OOXML elements or
deprecated. |
If the element of background is to be part of
the spec. then it should be defined in terms other than VML. Otherwise it
should appear as a deprecated element in the informative annex and the
above comment applies. |
|
|
Part 4, Section 2.2.1 |
page 28, line 1 |
te |
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.' |
The attribute value 'auto' is to distinguish
one entity from another in situation where both cannot be distinguished,
which is mentioned in the Section 2.1.3.4,page 39,line 6,7,8 definition
for the attribute 'color' . Hence "appropriate" here means that the entity
,whose value is set as auto, immediately uses the default color,
distinguishing it from other entity. This should be made clear in the
standard. |
|
|
Part 4, Section 2.2.1 |
page 29, line 0 |
te |
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). |
There are a few typos where the word "border"
is used instead of "background". This needs to be addressed. |
|
|
Part 4, Section 2.2.1 background (Document
Background) |
page 27, lines 1&2 |
te |
Assuming that background be referring to the
background of the document defined by one of its enclosing elements,
assuming that the notion of document page and the notion of displaying be
properly defined and that their definitions match commonly accepted ones,
then the 'This background shall be displayed on all pages of the document,
behind all other document content.' sentence makes unclear whether the
total surface of a page must be filled with the background, or else how
the subpart of the said surface can be determined. |
Clarify the meaning of background in this
case. Does it refer to the document or the frame as referenced in other
parts of this sections |
|
|
Part 4, Section 2.2.1 background (Document
Background) |
page 27, lines 8&21 |
ed |
Contradicting use of accent3 and accent5 – the
text says one thing, but the example says another. |
Fix the typing error |
|
|
Part 4, Section 2.3.3.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. |
If the element of background is to be part of
the spec. then it should be defined int terms other than VML. Otherwise it
should appear as a deprecated element in the informative annex and the
previous comment applies. |
|
|
Part 4, Section 3.17.4.1 |
|
te |
The restriction to only two date bases is
arbitrary and based only on one vendor's applications. There are
other reasonable values for date bases, including earlier ones for
historical dates. |
Explicitly allow negative date serial values
to express dates prior to 1900 |
|
|
Part 4, Section 3.17.4.1 |
|
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. |
In the specification there should be only one
date base (1904). A tag for backward compatibility could be added as part
of the compatibility settings annex to treat dates where 1900 was wrongly
considered to be a leap year. The standard could include a reference to
this compatibility setting. |
|
|
Part 4, Section 3.18.86 |
|
ed |
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. |
Look through the document and make sure the
reference is consistent |
|
|
Part 4, Section 3.18.87 |
|
ed |
Length is said to be “exactly 2
characters”. This is inconsistent with the schema fragment given
which defines it as being 2 octets long or 4 characters. |
Look through the document and make sure the
reference is consistent |
|
|
Part 4, Section 3.3.1.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. |
Provide for a user defined paper
size |
|
|
Part 4, Section 3.3.1.69 |
|
ed |
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. |
The normative description of the hashing
algorithm used by OOXML, along with the flowchart is defined in section
2.15.1.28 and therefore section 3.3.1.69 should cross-reference section
2.15.1.28. |
|
|
Part 4, Section 3.3.1.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. |
|
|
Part 4, Section 5.1.12.28 |
|
ed |
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. |
Look through the document and make sure the
reference is consistent |
|
|
Part 4, Section 5.1.12.37 |
|
ed |
Length is said to be “exactly 10
characters”. This is inconsistent with the schema fragment given
which defines it as being 10 octets long. |
Look through the document and make sure the
reference is consistent |
|
|
Part 4, Section 5.1.3.4 |
|
te |
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. |
|
|
Part 4, Section 6. |
Entire clause (pages 4343-4960) |
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. |
Move whole section to an informative annex. We
strongly advise that DrawingML replaces all functionalities of VML and VML
be eliminated from the specification. |
|
|
Part 4, Section 7.4.2.4 |
|
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. |
|
|
Part 4, Section 7.4.2.5 |
|
te |
It doesn't make sense for us to be specifying
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. |
Eliminate the requirement for null-termination
of strings. |
|
|
Part 4, Section 7.4.2.5 |
|
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. |
Reference the GUID specification |
|
|
Part 4, Section 7.4.2.5 |
|
te |
This element defines values for use on Windows
and Macintosh platforms, but not for Linux or any other operating
system. |
Include other values for known formats that
will allow cross platform interoperability |
|
|
Part 4, Section 7.4.2.5 |
|
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”? |
Windows and Macintosh clipboard formats should
be made publicly available. The std should include a reference to these
documents. This comment would also extend to other formats included as a
result of the previous comment. |
|
|
Throughout |
|
ge |
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. |
We suggest that the name Office Open XML be
changed |
|
|
Part 1 Page xii |
Lines 5 - 8 |
ge |
The statement reads: 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, all in a way that is fully
compatible with the large existing investments in Microsoft Office
documents. |
The goal should not be to protect only
Microsoft Documents but also other legacy documents that we have in
existent e.g WordPerfect documents. |
|
|
2.4.46 |
|
te |
OOXML lacks the ability to specify a multi-row
header that repeats across pages |
Include in this section the ability to select
the first N rows as a header. |
|
|
11.6 |
|
ge |
It is not clear how the styles and formatting
will be handled in the case of master documents and subdocuments. If the
master document has been formatted bold, and the subdocuments have not,
which will have precedence over the other? |
The document should outline clearly which
takes precedence over the other |
|
|
|
|
ge |
Microsoft has given an “Open Specification
Promise”,4 promising not to sue third parties that use the Ecma
specification for patent infringement. However, there are several issues
with this promise:
The promise only relates to “Microsoft
Necessary Claims”, which are “[t]hose claims of Microsoft- owned or
Microsoft-controlled patents that are necessary to implement only the
required portions of the Covered Specification that are described in
detail and not merely referenced in such Specification.” |
The Open Specification Promise should extend
not only to the required parts in the std but also to allow a complete
implementation of the std including non-mandatory specifications and
backward compatibility tags. |
|
|
|
|
|
The promise does not relate to copyrights but
only to patents and leaves significant scope for legal uncertainty for
third party developers. |
The Open Specification Promise should be
extended to cover copyrights. |
|
|
Part 1, Section 4 |
behavior, unspecified |
ed |
This definition doesn't work, since the
Standard, in defining compliance in Section 2, says that “compliance is
purely syntactic”. So no behaviors are required. Therefore, by
this definition, all behaviors are unspecified? Surely this is not
what is meant. |
Clarify this definition. Perhaps it is
meant to say, “Behavior for which this Standard does not make a
recommendation”? |
|
|
Part 1, Section 4 |
Office Open XML Document |
ed |
This definition doesn't hold together.
Are these two different definitions? Or two clause of which either will
define the term? Or both together define the term? |
Clarify the definition |
|
|
Part 1, Section 9.1.7 |
line 10 |
ed |
The naming convention giving is
incorrect. H is a hexadecimal digit, not a hexadecimal
value. |
Follow correct usage pattern as established
earlier in 9.1.1. |
|
|
Part 1, Section 9.1.9 |
line 25 |
ed |
Incorrect subject. A producer qua
producer does not round trip. |
Should say, “Conforming producers that are
also consumers should...” |
|
|
Part 1, Section 9.2 |
page 18, line 8 |
ed |
Extra period following “explicit.” |
Remove extraneous punctuation |
|
|
Part 2 |
|
ge |
Part 2 defines Open Packaging Conventions
(OPC) in terms that, according to Part 1, Section 9.1 Constraints on
Office Open XML's Use of OPC, are more general than needed for the purpose
of OOXML. This is due to bring confusion, and should be
resolved. |
Part 2 should be amended either by tightening
Part 2 contents so as to keep it focused on OOXML related
matters |
|