Template for comments and secretariat observations | Date: 22nd August 2007 | Document: ISO/IEC DIS 29500 |
1 | 2 | (3) | 4 | 5 | (6) | (7) |
MB1 |
Clause No./ Subclause No./ Annex (e.g. 3.1) |
Paragraph/ Figure/Table/Note (e.g. Table 1) |
Type of com-ment2 | Comment (justification for change) by the MB | Proposed change by the MB | Secretariat observations on each comment submitted |
Office Open XML Overview | ||||||
GB | Throughout | ed | The name "Office Open XML" is often mistakenly called 'Open Office XML” implying a connection to the OpenOffice project which does not exist. This naming confusion has been documented and has occurred numerous times, including by analysts and even in Microsoft press releases and blogs. Since “Open Office” is the pre-existing name, by 6 years, ECMA should choose a new name, less apt to continue this confusion. | Proposed change: Change the
name of Office Open XML to a name which is not confused with OpenOffice.
SC34 standards usually end with 'DL' (description langage) 'SL' (schema
language), etc. For DIS 29500 a suitable name is ODDL (Office Document
Description Language), which would remedy the fault noted.
The standard must refer to its proper name throughout (or “this international standard”) rather than sometimes adopting ad hoc alternative forms (e.g. “Open XML” in the present DIS). |
||
GB | Throughout | te | The UK considers it critical that
the text makes clear statements on conformance.
The text must make clear throughout that purely syntactic conformance is not enough for a implementation to claim it is conformant. The text must describe conformance in terms of semantics which have to be observed (though not necessarily replicated) by conformant applications. |
Proposed change: What is required, and what is optional, for conformance must be clearly distinguished within the text. | ||
GB | Throughout | te | It must be possible to process
data within office documents using standard tools for processing XML
files, including tools that can process XML Schema Datatypes. In many
cases the same sort of data is recorded in different ways in the various
sections of the DIS. Obvious examples are the way in which dates are
recorded in word processing documents and spreadsheets, and the way binary
data is identified.
It must be possible to identify and record an XSL processable form of every datatype represented in an OOXML document. For example, every element recording a date should be qualified with an attribute whose value is a processable xsd:date (or xsd:dateTime) representation of the recorded date. All integer, real and currency datatypes that are referenced in spreadsheet formulas should also be appropriately datatyped. Similarly every element containing binary data, or extensions that need to be processed using a non-XML processor, should have an attribute that records the MIME type of the data to be processed. This suggestion does not imply that all data that is processed as strings should need to be datatyped (as it is in languages such as the Web Ontology Language – OWL). |
Proposed change All atomic
values in the XML which have the same type should use the same typing
scheme (e.g. dates should all conform to ISO 8601). Where possible this
scheme should be an ISO or W3C XML scheme, and identified as such.
All mechanisms that allow referral to external and/or non XML resources should provide a means of identifying those resources’ media types using the MIME scheme. |
||
GB | 4.1 Interoperability [p3] | ed | “Foremost, the interoperability of
OpenXML has been accomplished through extensive contributions,
modification, and review of the Specification by members of the Ecma TC45
committee...”
OOXML has not yet been proven to be interoperable, as no conforming consumers and producers have yet been created. This claim cannot be made until more than one full implementation of an application that produces and consumes conformant OOXML exists. This is made difficult by the problems with the conformance definition in Part 1 - Fundamentals as described elsewhere in these comments. |
Remove inappropriate PR hyperbole from the text. | ||
GB | 4.1 INTEROPERABILITY [p4] | ed | References in the following
bulleted list refer to the wrong sections:
|
Proposed change: Change the
references to
|
||
GB | 4.1 INTEROPERABILITY [p4] | te | “One of the central requirements
for interoperability is independence from any particular type of source
content.”
This claim is dubious, and relies on the absence of a clear definition of “interoperability” in the specification. The UK assumes that one of the meanings of interoperability involves the ability for Application A to produce an OOXML file, that can be consumed by Application B, presented to the user with 100% fidelity, edited and saved, then consumed by Application N, still with 100% fidelity of representation. If this is the case, it seems logical that a central requirement would be for clear standards-based specification of source content, such that a future consuming application, unknown to the producer, has clear expectations of the valid range of content found within a conforming OOXML file. Interoperability between applications requires rules that impose constraints, whereas “independence from any particular type of source content” implies a lack of determining structure. If a conformant OOXML file can contain any type of source content, conforming consumers will have to support any type of source content - which is clearly impossible |
Proposed change: The standard must supply a precise definition of “interoperability”, and relate it to a definition of conformance as per the comment on conformance above. | ||
GB | 5.2 WORDPROCESSINGML [p11] | te | r – run (§3:2.4.2). The description of a run is confused about whether it is limited to text-only, and whether it contains additional markup. "[A run] Can contain multiple types of run content, primarily text ranges. ... A run is a contiguous piece of text with identical properties; a run contains no additional text markup." Part 3 and Part 4 reiterate "...the run, which defines a region of text..." [Implied "text-only" is wrong] Part 3 and Part 4 define with many examples that the run can contain a range of additional text markup in child elements like delText, endnoteRef, fldChar, ... (e.g., see §4:2.3.2.23). Part 3 and Part 4 also define that the run can contain non-text items like drawing (DrawingML Object), object (Inline Embedded Object), pict (VML Object), ... (e.g., see §4:2.3.2.23). | Proposed change: Clearly define the general concept of a run that can contain multiple types of content, primarily a text range with the same properties. [If the primary intent of a run is for text rather than other content types - if not the primary intent, use words like "such as a text range ...".] This also needs changes to the sections in Parts 3 and 4, including section titles that imply runs are only for text. [The text content is defined by a sub-element, t. §4:2.3.3.30] | ||
GB | 5.2 WORDPROCESSINGML [p11] | te | t – text range (§3:2.4.3.1). The statement about text formatting inheritance from run properties and paragraph properties is too limiting, because it does not account for the entire style hierarchy, as alluded to in the following paragraph in the Overview. | Proposed change: Change sentence to indicate inheritence from style hierarchy. "The formatting for the text is inherited from any run properties and paragraph properties, and from the higher style hierarchy as outlined in the following paragraph." | ||
GB | 5.2 WORDPROCESSINGML [p11] | te | t – text range (§3:2.4.3.1). Is it
OK to define OOXML attributes and behaviour within another standard (the
separate XML 1.0 specification)?
I believe that preserve whitespace is not "often" used, for routine text runs (only likely if several text runs need to be merged? If preserve is "often" used, why is the WordprocessingML default to remove white space? |
Proposed change: Change sentence to clarify use of the xml:space="preserve" attribute. | ||
GB | 6 SUMMARY [p13] | ed | "OpenXML ... and its documentation
has become both complete (through extensive reference material) ..."
The documentation is not complete (yet?) which in part is a reason for the review process. |
Proposed change: Change sentence to state OpenXML ... and its documentation includes extensive reference material ... | ||
GB | 6 SUMMARY [p13] | ge | "The compelling need exists for an
open document-format standard that is capable of preserving the billions
of documents that have been created in the preexisting binary formats,..."
As stated, the need is for an open document-format standard that is
capable of preserving the documents. This does not mean that the standard
has to be a new XML representation of the preexisting binary formats.
There is already an open document-format standard that is capable of
preserving the documents, and that already has widespread use and for some
time its evolution has "enjoyed the checks and balances afforded by an
open standards process".
If the Summary needs a statement about the need for an OOXML standard, it should qualify if there is a need for another open document-format standard alongside existing established standards, and how the new standard will interoperate with established standards. |
Remove inappropriate PR hyperbole from the text | ||
Part 1 - Fundamentals | ||||||
GB | General | te |
Namespace prefix mappingsThere is no table listing an explicit mapping between the namespace prefixes used in the rest of the specification and their namespace URIs. This makes developing an application that uses these examples significantly more difficult. |
Remedy - add a table, listing all
the namespace prefixes and their associated URIs. (Not part of the specification, but a recommendation: ensure that these URIs also resolve as URLs to web pages containing documentation about the namespace and a link to the schema for it) |
||
GB | General | ed |
Definition of "deprecated" and "legacy"Various parts of the specification are described as "legacy" and "deprecated", such as the entire VML section, and specific parts of other sections such as the autoSpaceLikeWord95 element. However, these descriptions are informative, rather than normative. In addition, there is no mandated behaviour associated with these deprecated sections. The commonly accepted meaning of "deprecated", when applied to an application using OOXML, would be that an application should be able to read deprecated elements (subject to the limitations described in 2.6), but would not write them out, except when they already existed in the source document. No non-deprecated sections of the specification should depend on deprecated sections. |
Proposed change: Deprecated and legacy parts of the specification should be marked as deprecated in normative text. A definition of deprecation and the associated behaviour should be included in this document. The specification should make it clear that applications conforming to the OOXML specification should not produce new instances of deprecated elements or attributes. Existing non-deprecated parts of the specification dependent on deprecated sections should either be changed to use non-deprecated sections, or be deprecated themselves (so the "background" element in WordProcessingML should be changed to use DrawingML, for example). | ||
GB | General | ed | The word "will" is used inappropriately throughout all Parts of the standard. It generally should be used only for an event at some indeterminate future time. | Proposed change: Replace the use of "will" with the correct present definite tense. For example, "The numbering definition part will contain the definition for..." should become "The numbering definition part contains the definition for..." and "This simple type specifies that its contents will contain ..." should become "This simple type specifies that its contents contain ..." | ||
GB | Foreword [xi] | ed | The "Office Open XML Overview" document is not listed as part of the Ecma 376 standard in the Forward to Part I “Fundamentals” and its status whether informative or normative is not explicitly stated. | Proposed change: Clarify the status of this Overview document. If it is merely a promotional whitepaper about Ecma 376, then it should not be included in the published standard. | ||
GB |
Introduction [xii] |
te | Claims that this text will enable implementation "in a way that is fully compatible with the large existing investments in Microsoft Office documents". Yet there is no mapping provided between DIS 29500 and existing (legacy) Office document formats. | Proposed change: Provide such a mapping or remove this claim. | ||
GB | Section 2 – Conformance | te | The conformance section fails to
provide a testable definition, defining conforming documents
tautologically as “documents which conform”. It raises a series of issues,
and includes an “informative” guidelines section that indicate loopholes
in conformance, without then closing them off.
The three goals of the standard introduce a broad set of objectives that contain contradictions. Innovation, interoperability and preserving investment in existing files have different requirements.
|
Proposed change: (as above) what is required, and what is optional, for conformance must be clearly distinguished within the text. Clarify the meaning of this text | ||
GB | 2 [p2] | te | The text currently reads, “Unless documented otherwise, any feature shall be implemented as specified by the normative text describing that feature in this Standard.” This is open-ended since it does not say where “otherwise” something may be documented. Presumably a feature should be implemented exactly as specified by the normative text, period. Isn’t that the reason for having normative text? | Proposed change: Either remove this sentence or clarify how or where something “documented otherwise” can change how something specified in the normative text. | ||
GB | 2.1 [p2] | ed | There are no normative statements in this clause, though Section 2 is indicated to be normative | Proposed change: Mark clause as informative using one of the mechanisms of Section 7 | ||
GB | 2.2 [p2] | ed | There are no normative statements in this clause, though Section 2 is indicated to be normative | Proposed change: Mark clause as informative using one of the mechanisms of Section 7 | ||
GB | 2.2 Issues | te | Whether normative or informative,
there are a variety of problems with the text:
|
Revise the text to address these concerns. | ||
GB | 2.3 What this Standard specifies [p3, 9] | te | “this Standard constrains both syntax and semantics,” but then both document and application conformance are stated to be “purely syntactic”. Only sub-clause 2.6 Interoperability Guidelines refers to the use of semantic specifications, and this section is marked as Guidance so is informative, not normative. In what sense does the standard constrain semantics, if they are purely normative, and conformance does not require semantics to be accounted for? | Proposed change: (as above) what is required, and what is optional, for conformance must be clearly distinguished within the text. Clarify the meaning of this text | ||
GB | 2.3 [p3, 14] | te | 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? | Proposed change: What may be meant is that the additional syntactic constraints are normative, period. Clarify this sentence, perhaps by omitting the editorial explanation about why such additional constraints are not in the schema | ||
GB | 2.3 [p3, 16] | te | 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? | Proposed change: Clarify the use of the word “element” perhaps by saying “XML element” if that is what is meant. | ||
GB | 2.4 [p3, 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? | Proposed change: An explicit Unicode version reference should be made in the Conformance section. | ||
GB | 2.6 [p3, 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. | Proposed change: Change to read, “a software application should be accompanied by documentation...” | ||
GB | 2.6 [p3-34 to p4-6] | te | The ability to allow different
applications of OOXML to implement individually selected sets of optional
features, and to "highlight any behaviors that would, without that
documentation, appear to violate the semantics of document" means that it
will be impossible for OOXML implementations to interoperate. As this
statement is not normative it is not necessary for implementations to
document apparent violations of semantics, which will make
interoperability harder to achieve.
[To expand on this point slightly in less formal language - the problem is that two independent implementations of the specification can choose a different subset to implement, and still be described as conforming to the OOXML specification. For example, two different wordprocessors can each choose to implement 90% of the specification, but each will implement a different 90%. The size and complexity of the specification means that this is highly likely to happen in practice (and an inspection of the existing ECMA 376 implementations shows that this is already starting to occur). Then, interchanging documents between those two wordprocessors will not work reliably - and ISO's goal of "compatible technology" will not have been achieved. The argument could be made that there are certain base functions that must be implemented by any wordprocessor (such as headings, paragraphs, text formatting, etc.), and so these most important functions will be fully interoperable - but this definition of basic functions should be embedded in the standard] |
Proposed change: There should be a normative definition of what an application needs to support in order to conform to this specification. This definition should define a clear list of elements and attributes that are required to be supported by an implementation in order for it to be described as conforming to the specification. This definition should not include any deprecated elements or attributes. This definition should be created with practical interoperability between OOXML implementations in mind. | ||
GB | 2.6 [p4, 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? | Proposed change: Clarify the use of the word “element” perhaps by saying “XML element” if that is what is meant. | ||
GB | 2.6 [p4, 15] | ed | Obviously the Standard anticipates such behavior since it explicitly contains the present example describing this behavior and calls it conforming. | Proposed change: Perhaps it is meant to say, “...this Standard does not recommend this behavior”. | ||
GB | 4 [p6, 9] | ed | (behavior, implementation-defined) “application-specific”, at least in common standards use, is not the same as application-defined, viz. ANSI C Programming Language | Proposed change: Use “application-defined” consistently where the intent is for applications to document their behavior. | ||
GB | 4 [p6, 13] | te | (behavior, unspecified) This definition doesn't work, because 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. | Proposed change: Clarify this definition. Perhaps it is meant to say, “Behavior for which this Standard does not make a recommendation”? | ||
GB | 4 [p7, 1] | te | (Office Open XML Document) 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? | Proposed change: Clarify the definition | ||
GB | 5 [p8, 3-13] | te | Notation conventions 3, 4 and 6 appear to rely upon styles that are not visually distinguishable in the version of the specification under review. | Proposed change: If the stylistic distinction is necessary, the styles should be made clearly distinct for both screen-based and paper-based readers. | ||
GB | 8.6.5 [29-30] | te | Should be revised to read as follows (the problem is that "Math" is not a tag): | Math is used, mainly in documents, to specify the structure and appearance of equations. The outermost element is oMath or oMathPara, a paragraph with one or more equations where each equation is specified using a single oMath element. | ||
GB | 9.1.1 [p16, 10] | te | ASCII requires a normative reference since there are several national variations. | Proposed change: Suggest reference be made to ISO/IEC 646:1983 or ANSI X3.4-1986 | ||
GB | 9.1.5 [p16, 25] | te | 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. | Proposed change: If interleaving is not permitted then it should not be described in Part 2. | ||
GB |
9.1.7 [p17, 7] |
te | The naming convention given is incorrect. H is a hexadecimal digit, not a hexadecimal value. | Proposed change: Follow correct usage pattern as established earlier in 9.1.1. | ||
GB | 9.1.9 [p17, 25] | ed | Incorrect subject. A producer qua producer does not round trip | Proposed change: Should say, “Conforming producers that are also consumers should...” | ||
GB | 9.2 [p18, 8] | ed | Extra full stop following “explicit.” | Proposed change: Remove extraneous punctuation | ||
GB | 10.1.2 [20] | ed | Reference is made to material in Part 12, Clause 12. Although a clause of that number does exist, it does not contain the material 10.1.2 references it for. | Proposed change: Correct the reference to point to the correct clause. | ||
GB | 11.3.1 [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. | Proposed change: Change lines 3-5 to read, “An alternative format import part allows content specified in an application-defined alternate format to be embedded directly in a WordprocessingML document...” | ||
GB | 12.3.5 [p68] | te | This binary part is said to be used for the storage of “arbitrary user-defined data”. No further detail is given as to what user action would trigger the use of this “user-defined” data. Without further definition, no interoperability of this feature is possible. | Proposed change: Fully define the use of Custom Property Part | ||
GB | 14.2.2 [p126 18] | te | We believe from the schemas that the root namespace here may be http://schemas.openxmlformats.org/drawingml/2006/chartDrawing, rather than http://schemas.openxmlformats.org/drawingml/2006/chart. | Remedy: confirm that this is correct, and update the namespace accordingly. | ||
GB | 15.2.6 [p142 3] | te | 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? | Proposed change: Clarify the meaning. | ||
GB |
15.2.8[p143 -146] |
te | The examples given are rendered useless by the predominance of the VML in the markup. | Proposed change: Make a more succinct and clear example by concentrating on the control persistence. | ||
GB | 15.2.12 [p154] | te | There is no reference made to a particular dated version of TrueType or OpenType specifications. And if TrueType and OpenType differ, then there should be different ways to refer to them, rather than calling them both “application/x-font-ttf” | Proposed change: Provide reference to intended specifications for TrueType and OpenType | ||
GB | 15.2.14 [p155] | te | It is unsatisfactory to store printer settings in OS-dependent binary formats like DEVMODE structures. This is a considerable security concern (DEVMODE structures are loaded directly into device driver memory), as well as lacking cross-platform adaptability. There is also no interoperability with print settings as currently defined. | Proposed change:
Alternatives are available for expressing print settings in XML rather
than in binary. For example, Microsoft's own XPS specification defines a
PrintTicket markup for which the XPS specifications says, “The PrintTicket
is XML that provides print settings in a consistent, accessible, and
extensible manner. We would like the same qualities in OOXML's print
settings, not a binary blob.
Adopt such an alternative. |
||
GB | 15.2.15 [p156] | te | 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. | Proposed change: Clarify what size the thumbnails should be, or that the images are scaled. | ||
GB | Annex A [p162 7] | te | The reference given for the Zip format does not provide a date or version, though this specification is frequently revised, | Proposed change: Reference should be made to a particular dated and labeled Zip version. | ||
Part 2 – Open Packaging Conventions | ||||||
GB | General | te | 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. | Proposed change: Part 2 should be amended either by: a) referencing an established standard (in which case placing documented constraints upon its use in OOXML would be fine), or else b) tightening Part 2 contents so as to keep it focused on OOXML related matters, or else c) submit OPC as a separate packaging-focused standard and, provided that it is accepted as a standard, apply option a) to it. | ||
GB | 1 Scope [p1, 9] | te | The 'well-defined naming guidelines' expression is an oxymoron in the context of a standard. This is reinforced in the case of OOXML proposal by the fact that 'guidance' parts of the text are explicitly meant to be informative only (as opposed to normative). | Proposed change: Replace 'guidelines' with 'rules'. | ||
GB | Page 2 Normative References | ed | The normative references listed here include only ISO and ISO/IEC standards, while the normative body of the text makes reference to many other specifications, such as RFC3986, RFC2616, XML Schema Part 2: Datatypes, ZIP specification, XML-Signature Syntax & Processing (most of the bibliography entries could be moved to normative references). | All normative standards should be referenced as such (whether ISO/IEC standards or not) | ||
GB | 3 Definitions [p4, 20] | te | This definition of 'package model' is not compatible with the prior definition given in Part 2, Section 1. Scope, page 1, line 5. | Proposed change: Define 'package model' in unambiguous terms and use the resulting definition consistently throughout the OOXML text. | ||
GB | Page 9 line 25 | ed | This line references "a note as specified in 4.1, “Document Conventions.”", but there's nothing in 4.1 describing notes. | Either 4.1 needs a description of a note to be added, or this cross reference must be removed. Without knowing how "standard" the use of notes is in this standard according to Ecma procedures, it is not possible to suggest which is better. | ||
GB | Page 10 lines 13-15 | ed | The second sentence in this paragraph is normative text in a clause explicitly described as informative. It would be better to make this whole paragraph normative, but that may cause problems as the normative/informative split in this Ecma standard appears to be at the level of whole clauses, except where notes are used. A change in the normative/informative status of the clause would also require changes in section 6. | No proposal | ||
GB | Page 12 line 3 | ed | It looks as if this line should have been a sub-clause (8.1.1.1) | No proposal | ||
GB | Page 62 line 4 | ed | Missing space in "SignatureValueelement". | should be "SignatureValue element" | ||
GB | Page 80 line 2 | ed | Incorrect cross-reference | this one should be [M3.21] | ||
GB | ANNEX A [p81, OpenPackagingConventions-XMLSchema.zip ] | ed | There is no explicit indication given as to whether this annex is informative or normative. See ISO Directives, Part 2, section 5.2.6. | Proposed change: Clarify the status of this annex. | ||
GB | ANNEX A [p81, OpenPackagingConventions-XMLSchema.zip ] | ed | This annex was not provided in a humanly-readable citable format as required by JTC1 Directives 8.3.5 and Annex H. | Proposed change: The annex should be provided in a humanly-readable, lined-numbered format so it can be referenced and cited. Additionally, an electronic machine-readable version can be provided according to Annex H. | ||
GB | Page 82 line 5 | te | It is stated "If discrepancies exist between the electronic version of a schema and its corresponding representation as published in this part, Part 2, the electronic version is the definitive version.". | The editor must ensure no such discrepancies exist, as the published schema examples are normative | ||
GB | ANNEX B [p82, OpenPackagingConventions-RELAXNG.zip ] | ed | There is no explicit indication given as to whether this annex is informative or normative. See ISO Directives, Part 2, section 5.2.6. | Proposed change: Clarify the status of this annex. | ||
GB | ANNEX B [p82, OpenPackagingConventions-RELAXNG.zip ] | ed | This annex was not provided in a humanly-readable format as required by JTC1 Directives 8.3.5 and Annex H. | Proposed change: The annex should be provided in a humanly-readable, lined-numbered format so it can be referenced and cited. Additionally, an electronic machine-readable version can be provided according to Annex H. | ||
Part 3 - Primer | ||||||
GB | 2.4.1 [36] | ed | (The same phrase is also used on p34 in 2.3.1 [28] of the WordprocessingML Reference Manual.) | Replace "... a designating specifying ..." with "... an attribute specifying ..." | ||
GB | 2.4.2 [9 on p5] | ed | Run properties are not represented by the r element. | Proposed change: Change the order or the sentence to more directly relate the r element to the run. "The next level of the document hierarchy is the run, which defines a region of text with a common set of 9 properties. A run is represented by an r element, which allows the producer..." | ||
GB | 2.4.2 [30 on p5] | ed | wrong style: | "emphasized" should be in italics. | ||
GB | 2.4.2 [4 on p6] | ed | Missing forward slash from end tag: | </w:rPr> | ||
GB |
2.4.2 [17 on p6] |
ed | Missing forward slash from end tag: | </w:rPr> | ||
GB | 2.4.2 [23 on p6] | ed | Missing forward slash from end tag | </w:rPr> | ||
GB | 2.4.2 [28 on p6] | ed | - | Insert "of" in "... only some of the text ..." | ||
GB | 2.5.2 [17] | ed | Missing closing double quotes in attribute: | w:sz="4" | ||
GB | 2.5.3 [5 on p12] | ed | Replace curly quotes with straight quotes: | w:val="2"/> | ||
GB |
2.5.3 [26 on p12] |
ed | Replace curly quotes with straight quotes: | w:val="2"/> | ||
GB | 2.5.4 [31 on p13] | ed | 'W' in 'World' should be lower case: | <w:t>Hello, world</w:t> | ||
GB | 2.5.4 [13 on p14] | ed | - | Delete line 13: "..." | ||
GB | 2.5.4 [16 on p14] | ed | - | Replace "5145" with "7368" to make consistent with example on p12: w:w="7368" | ||
GB | 2.5.4 [23 on p14] | ed | - | Replace "2145" with "1488" to make consistent with example on p12: w:w="1488" | ||
GB | 2.7.1 [1 - 28 on p28] | ed | - | Delete lines 1 to 28 as the same listing is on the previous page. | ||
GB | 2.8.2 [2 on p30] | ed | - | "h" in "heading 1" should be upper case: <w:name w:val="Heading 1"/> | ||
GB | 2.8.2 [6] | ed | It appears that the child w:priority of w:style has been changed to w:uiPriority in the schema and in the tables in the Language Reference but has not been changed in any of the examples throughout the documents I've seen so far. | Replace "w:priority" with "w:uiPriority" | ||
GB | 2.8.2 [21 - 31 on p30] | ed | - | Delete lines 21 to 31 | ||
GB | 2.8.2 [32 - 33 on p30] | ed | - | Move lines 32 to 33 to between lines 12 and 13 on p30. | ||
GB |
[2.8.4 [27] |
ed | See 2.8.2 [6] above. | Replace "w:priority" with "w:uiPriority" | ||
GB | 2.8.5 [31] | ed | - | Change line 31 to include the information from lines 28 to 29 on p34 (see below) to: "Consider the following two styles comprising a linked style pairing which defines: font = Arial, font color = green, paragraph spacing = double, indent = 1" left. The resulting style definitions would be:" | ||
GB | 2.8.5 [28 on p34 - 14 on p35] | ed | The xml listing for the linked styles is repeated unnecessarily. | Move lines 28 and 29 on p34 and merge with line 31 on p33, as specified above. Delete from line 30 on p34 to line 14 on p35. | ||
GB | 2.8.6 [17] | ed | See 2.8.2 [6] above. | Replace "w:priority" with "w:uiPriority" | ||
GB | 2.8.7 [15 on p38] | ed | See 2.8.2 [6] above. | Replace "w:priority" with "w:uiPriority" | ||
GB | 2.8.11 [26] | ed | Incorrect attribute name | Replace "w:defPriority" with "w:defUIPriority" | ||
GB | 2.8.11 [31] | ed | See 2.8.2 [6] above. | Replace "w:priority" with "w:uiPriority" | ||
GB | 2.8.11 [32] | ed | See 2.8.2 [6] above. | Replace "w:priority" with "w:uiPriority" | ||
GB | 2.8.11 [35] | ed | See 2.8.2 [6] above. | Replace "w:priority" with "w:uiPriority" | ||
GB | 2.8.11 [36] | ed | See 2.8.2 [6] above. | Replace "w:priority" with "w:uiPriority" | ||
GB | 2.8.11 [1 on p43] | ed | See 2.8.2 [6] above. | Replace "w:priority" with "w:uiPriority" | ||
GB | 2.8.11 [2 on p43] | ed | See 2.8.2 [6] above. | Replace "w:priority" with "w:uiPriority" | ||
GB | 2.8.11 [3 on p43] | ed | See 2.8.2 [6] above. | Replace "w:priority" with "w:uiPriority" | ||
GB | 2.8.11 [4 on p43] | ed | See 2.8.2 [6] above. | Replace "w:priority" with "w:uiPriority" | ||
GB | 2.8.11 [5 on p43] | ed | See 2.8.2 [6] above. | Replace "w:priority" with "w:uiPriority" | ||
GB | 2.8.11 [6 on p43] | ed | - | Add slash to close element. | ||
GB | 5.9.4.3 [33 on p344] | ed | - | Replace curly quotes with straight quotes in XML attributes. | ||
GB |
5.9.4.3.1 [29 on p345] |
ed | - | Replace curly quotes with straight quotes in XML attributes. | ||
GB | 5.12.3 [p356-7] | ed | The XML example is not well-formed. Although it is acceptable to use ellipsis to elide some information in examples, that should not include the key parts of the example (i.e. the rectangle shape, in this instance). | Proposed change: correct the example to be well-formed and to provide useful information. | ||
GB | 5.14.3 [p373-4] | ed | The XML example is not well-formed. Although it is acceptable to use ellipsis to elide some information in examples, that should not include the key parts of the example (i.e. the rectangle shape, in this instance). | Proposed change: correct the example to be well-formed and to provide useful information. | ||
GB | 5.15.3.1.3 [20 on p379] | ed | - | Add missing quote at end of maxOccurs attribute | ||
GB | 5.15.3.1.4 [5 on p380] | ed | - | Add missing quote at end of CT_Cxn attribute value. | ||
GB | 5.15.4.1 [26 on p382] | ed | - | Add missing quote at end of lang attribute value. | ||
GB | 5.15.4.1.3 [15 on p384] | ed | - | Add missing quote at end of CT_Colors attribute value. | ||
GB | 5.15.4.1.6 [9 on p386] | ed | - | Add missing quote at end of styleLbl attribute value. | ||
GB | 5.15.4.1.6 [10 on p386] | ed | - | Remove extraneous text "odoc". | ||
GB | 5.15.5.1.3 [33 on p389] | ed | - | Remove backtick at end of line. | ||
GB | 5.15.6.3.1 [25,26 on p403] | ed | - | Add missing quotes around "NAME OF TYPE" and "NAME OF SIMPLE TYPE" | ||
GB | 5.15.6.3.16 [11 on p407] | ed | - | Add missing quote and space to break up animLvl from type attribute. | ||
GB | 5.15.6.3.39 [16 on p415] | ed | - | Add missing quote at end of minOccurs attribute. | ||
GB | 7.1 | ed | On page 1, the Primer states that
"this Part contains a detailed introduction to the following Office Open
XML topics" and includes "Various shared MLs" in the list. However as far
as the "detailed introduction" is concerned:
|
Revise the text to address these concerns | ||
GB | 7.1 [18] | ed | The expression "abc" with the arrow and with the brace over the top are both repeated. In each case, one is oMath and the other is a picture. | The picture version needs to be deleted in each case. | ||
GB | 7.1 [19] | ed | The bar fraction "n/k" at the end of the line is repeated. One is oMath and the other is a picture. | The picture version needs to be deleted. | ||
GB | 7.1 [20] | ed | The stack object, n over k, at the start of the line is repeated. One is oMath and the other is a picture. | The picture version needs to be deleted. | ||
GB | 7.1.10 [5] | ed | - | Replace "x + x + x" with "x + x + ...". | ||
GB |
7.1.12 [11] |
ed | - | Replace "upper limit" with "lower limit". | ||
GB | 7.2.1 [6 on p440] | ed | Missing forward slash from end tag: | </dc:creator> | ||
GB | 7.4.3 [7 - 8 on p445] | ed | - | Insert new line between lines 7 and 8 containing missing end tag: </b:NameList> | ||
GB | 7.4.3 [14 - 15 on p445] | ed | - | Insert new line between lines 14 and 15 containing missing end tag: </b:NameList> | ||
GB | 7.4.3 [21 - 22 on p445] | ed | - | Insert new line between lines 21 and 22 containing missing end tag: </b:NameList> | ||
GB | 8.3.4.2.1 [2 - 9 on p470] | ed | XML example not well formed. | Insert missing end tags for choice and fallback. | ||
GB | 8.3.4.1.1 [p455] | ed | The graphic provided in the example is almost impossible to read, and includes malformed XML. | Proposed change: Make an easy to read example (perhaps lighter background color) and make the example well-formed. |
Part 4 - Markup Language Reference | ||||||
GB | Foreword [vi, 9] | ed | Explicitly references annexes that are not provided in a humanly-readable format, whereas a human-readable format is required by JTC1 Directives 8.3.5 and Annex H | Proposed change: Annexes should be provided in a humanly readable, lined-numbered format so it can be referenced and cited. The reference to electronic form only annexes should be removed. | ||
GB | Introduction [vii, 7] | ge | Full compatibility of the proposed OOXML with any existing application is demonstrably unreachable (because the proposed OOXML explicitly gives up describing parts of what it aims to describe, e.g. Part 4 page 1378 lines 12-17). | Proposed change: Rephrase the compatibility goal so as to make it realistic. | ||
GB | Introduction [vii, 8] | te | An XML markup cannot be “fully compatible” with an “investment” | Proposed change: Remove inappropriate PR hyperbole from the introduction. | ||
1. Part Overview | ||||||
GB | General | ge | It is unclear what the term "interoperability" means within the proposed standard. The standard needs to differentiate between issues that affect interoperability between different implementations of OOXML (i.e. implementations which make different choices in areas where options are provided, or make different interpretations of ambiguous text) and interoperability between applications based on different standards and specifications (e.g. interoperability between OOXML Maths and MathML). | Revise the text to address this comment | ||
GB | General | ge | It should not be necessary to read any informative text to implement a function defined in a normative section of this standard. Normative text should describe all requirements and not rely on informative examples to identify requirements. | Revise the text to address this comment | ||
GB | 1. Part Overview [p1] | ge | The use of 'Part' for different things is confusing. Line 1 (title) it refers to Part 4 as a subpart of OOXML. Line 3 it implicitly refers to WordprocessingML, SpreadsheetML, etc. | Proposed change: Use another word like 'subpart' when referencing WordprocessingML etc., or else use their full names. | ||
GB | 1.1 [p1, 5] | ed | Table row 'Alternative Format Import' is deemed to have no root element and no reference. The value of this row is unclear. | Proposed change: Clarify the table purpose. | ||
GB | 1.2 [p1, 6] | ed | Table row 'Custom Property' is deemed to have no root element and no reference. The value of this row is unclear. | Proposed change: Clarify the table purpose. | ||
GB | 1.5 [p3, 1] | ed | Eleven table rows are deemed to have no root element and no reference. The value of these rows is unclear. | Proposed change: Clarify the table purpose. | ||
2. WordprocessingML Reference Material | ||||||
GB | General | te | Prefixed element names are used throughout without indication whether these prefixes are bound to XML Namespace URIs. | Revise the text to address this comment | ||
GB | General | te | There are approximately 2300
examples in the WordProcessingML section of the specification. These
examples were tested for well-formedness and validity against the
schema, using custom software. Approximately 300 of the examples are in
error - more than 10%. The list is available at http://surguy.net/articles/ooxml-validation-and-technical-review.xml
The examples in error haven't all
been checked manually - but a random selection has been checked, and all
of those have proved to be correctly identified as errors, which gives a
high confidence that the majority of the remainder are also genuine
errors.
(Opinion: While a certain number of errors is understandable in any large specification, the sheer volume of errors indicates that the specification has not been through a rigorous technical.) The use of xml:space='preserve' is inconsistent in examples, which is confusing because it is not clear when and how they should be used. For example on page 989 one of the w:t elements has this attribute, the others do not. This should be corrected here and in all other examples. |
Revise the text to address this comment. Provide a guarantee all examples are tested and syntactically meaningful. | ||
2. WordprocessingML Reference Material - Interoperability between ODF and OOXML | ||||||
GB | General | ge | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following features: | See following comments on Interoperability between ODF and OOXML | ||
GB | Absolute image positioning within a frame | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: image can be positioned absolutely within a frame | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | An option to rotate the text by 90 or 270 degrees | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: an option to rotate the text by 90 or 270 degrees. | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Any number of rows can be selected for repeating Heading | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: any number of rows can be selected for repeating Heading | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Allow 8192 table columns rather than OOXML's 63 | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: allow 8192 table columns rather than OOXML's 63 | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Background Image in Tables | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: Background Image in Tables -- background image can be defined for an entire table, a row or an individual cell. This image is automatically resized when modifying the table. | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Evenly distribute contents in a multi-column section | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: Contents in a multi-column section can be evenly distributed resulting in balanced columns | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Ability to set arbitrary Text background color | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: ability to set arbitrary Text background color | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Before/After text around foot notes references | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: Before/After text around foot notes references | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Copy Heading while splitting Table | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: Copy Heading while splitting Table | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Table Shadowing Style | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: Table Shadowing Style | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Vertical numbering in list items | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: vertical numbering in list items | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | 'Leading' line spacing in a paragraph | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: 'Leading' line spacing in a paragraph | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | 'May Break Between Rows' attribute so as not to split a table | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: a 'May Break Between Rows' attribute so as not to split a table | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | An option to specify "Numbers of lines" for widow or orphans lines | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: an option to specify "Numbers of lines" for widow or orphans lines | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | 'Manual' and 'From left' alignment in tables | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: 'Manual' and 'From left' alignment in tables | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats | ||
GB | Last line alignment in justified paragraph | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: Last line alignment in justified paragraph (provision that we can change the last line of the paragraph as Left, Center and Justify) | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Allow entire sections to be marked as hidden | ed | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: allow entire sections to be marked as hidden | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Tabs fill character of a paragraph | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: Tabs fill character of a paragraph | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | 'Title' and 'lowercase' style options | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: 'Title' and 'lowercase' style options | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Table can have 'keep with next paragraph' set | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: table can have 'keep with next paragraph' set | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Ability to set each image border with different properties | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: ability to set each image border with different properties | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Font weights beyond just 'normal' and 'bold'. | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: font weights beyond just 'normal' and 'bold'. | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Table of content protection against manual changes | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: Table of content protection against manual changes | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Background opacity | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: Background opacity | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | auto page break option | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: 'auto' option when application decides if it should insert a page break | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Shadow distance, and a color of shadow other than black | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: shadow distance, and a color of shadow other than black | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Table cell protection | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: Table cell protection | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Text blinking | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: Text blinking | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Column separator attributes | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: Column separator attributes : width, color, height, vertical-align. | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Text-box can define the vertical text alignment | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: text-box can define the vertical alignment of text (top, center, bottom) | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Notes embedded in text-boxes | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: Notes embedded in text-boxes | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats | ||
GB | Assign different page colors in a document | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: ability to assign different page colors throughout the document | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Columns for frames/text-boxes | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: Columns for frames/text-boxes | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
GB | Keep ratio feature for frames | te | It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: Keep ratio feature for frames | Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats. | ||
2. WordprocessingML Reference Material – Other issues | ||||||
GB | 2.1 [36 on p12] | ed | - | Replace "Pansose-1" with "Panose-1" | ||
GB | 2.2 [p26, 24 and 27] | te | These lines define the contents of an OOXML document of type Wordprocessing in terms that are not compatible with the definition of OOXML documents given in Part 1, Section 4. Definitions, page 7, lines 1 to 3. Note that Section 2.2 as a whole is affected by that inconsistency. | Proposed change: Rewrite or remove Section 2.2. May consider explaining what a OOXML story would be in terms of documents renditions by applications. | ||
GB | 2.2 [p26, 27 and 28] | te | The definition of 'story' is inappropriate. We shouldn't be defining a markup standard in application terms. We should be defining markup in markup terms. Where the user can type is immaterial. | Proposed change: Clarify the definition of 'story'. | ||
GB | 2.2.1 [p27] | te | The child elements of the background element are defined to be in the VML namespace. VML is "a legacy format... included for backwards compatibility reasons". WordProcessingML should be dependent on a deprecated legacy format. | Proposed change Remove this reference to VML. The child elements of the background element should be defined in DrawingML. | ||
GB | 2.2.1 [p27, 1 and 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. | Proposed change: Clarify the definition of 'background'. | ||
GB | 2.2.1 [p27, 8 and 21] | te | Contradicting use of accent3 and accent5 – the text says one thing, but the example says another. | Proposed change: Fix the contradiction. | ||
GB | 2.2.1 [p28, 0] | ge | 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. | Proposed change: Remove all references to VML from the OOXML text, hence remove the reference to the urn:schemas-microsoft-com:vml namespace here. | ||
GB | 2.2.1 [p28, 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. | Proposed change: Describe the background element in terms of non-deprecated elements or remove it. | ||
GB | 2.2.1 [p28, 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.' | Proposed change: Define the characteristics of the auto value for the color attribute of the background element properly. | ||
GB | 2.2.1 [p29, 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). | Proposed change: 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. | ||
GB | 2.3.1 [28] | te | (The same phrase is also used on p4 in 2.4.1 [36] of the Primer.) | Replace "... a designating specifying ..." with "... an attribute specifying ..." | ||
GB | 2.3.1.8 [p59] | te | This element uses a bitmask to specify various paragraph conditional formatting properties.. The use of bitmasks rather than a set of boolean types makes this data sub-optimal to work with standard XML tools like XSLT which lack bit-level operations. | Proposed change: Rewrite this subclause to express the feature using named XML constructs rather than bitmasks. | ||
GB | 2.3.2 [9 on p159] | te | Run properties are not represented by the r element. | Proposed change: Change the order or the sentence to more directly relate the r element to the run. "The next level of the document hierarchy is the run, which defines a region of text with a common set of 9 properties. A run is represented by an r element, which allows the producer..." | ||
GB | 2.3.2.36 [13 on p229] | te | This section should make it clear that it applies only to non-complex script characters. Compare with "2.3.2.37 1 szCs (Complex Script Font Size)". | Proposed change: Change the title to read "2.3.2.36 sz (Non-Complex Font Size)" | ||
GB | 2.3.2.36 [14 on p229] | te | This section should make it clear that the font size are expressed in half-point values. | Proposed change: Change
line 14 to read "This element specifies the font size, in half-point
values, which shall be applied to all non-complex script characters in
the contents of this run when displayed."
Why are half-point values needed anyway? The OOXML binary constrained need for half-point should be within the implementation that takes the standard back to the old binary format. For future documents and evolution, the font size should be specified in a real standard way. Why are different units of measurement used elsewhere? There should be a standard unit of measurement throughout, or some unit from existing standards such as in the @font-face font description of [CSS2] and the element of [SVG]. |
||
GB | 2.3.2.36 [16 on p229] | te | Line 16 has confusing structure and use of "value". | Change this to "If this element is not present, the default is to leave the font size as the value applied at the previous level in the style hierarchy. | ||
GB | 2.3.2.36 [16 on p229] | te | The font size value used
ultimately depends on the font being available. If the font is not
available, and font substitution is turned on, then a different font(and
size) may be displayed. (See 2.15.3.46 subFontBySize (Increase Priority
Of Font Size During Font Substitution))
Font substitution is the process by which an application determines which font to use in place of a font that is referenced by a document, but is not available to the application trying to display the document. Typically, applications may perform font substitution using any mechanism available. This element, when present with a val attribute value of true (or equivalent), specifies that finding a font with a similar font size shall have increased precedence when doing font substitution for this document. |
Change this section and section 2.7.2 Style Hierarchy to clarify effect of missing fonts and font-substitution on the text style and font size used. (link to 2.8 Fonts) | ||
GB | 2.3.3.6 [26] | te | It is not clear why the day is
shown in the example as 12 rather than Wednesday.
The use of US-style dates in these examples is misleading (do Canadian's use the US format or the UK format?). Dates should be printed in the unambiguous ISO 8601 format in international standards. |
Revise the text to address this comment | ||
GB | 2.3.3.14 [p256] | ed | The text says, “This element specifies the language which shall be for this phonetic guide.” This sentence is missing a verb. Is it "used"? | Proposed change: Insert the missing verb | ||
GB | 2.3.3.19 [p261] | 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 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. | Proposed change: Define layout properties of embedded objects using DrawingML rather than VML | ||
GB | 2.3.3.30 [7 on p276]
(continued) |
te | The space name for the attribute implies w:space, which is confusing with the description of xml:space. | Proposed change: For clarity, the name should be shown as xml:space. | ||
GB | 2.3.3.30 [7 on p276]
(continued) |
te | Does w:t use of xml:space
attribute need the xml namespace to be specified in the
“/[Content_Types].xml” or some other aspect of a WordprocessingML
document? If needed, clarify any extra impact.
The space attribute description does not define what the default white-space processing mode means for WordprocessingML. |
Proposed change: Qualify that default white-space processing depends on application implementing the standard, and what the default mode is for OOXML. | ||
GB | 2.3.3.30 [7 on p276]
(continued) |
te | The example states "Although there are three spaces on each side of the text content in the run,..." In the example, the three spaces are at the end of the text content. | Proposed change: Change
the example to match description, for most complete example of removing
preceding and trailing white space.
<w:t> significant whitespace </w:t> |
||
GB | 2.3.3.30 [7 on p276]
(continued) |
te | The default surely depends on the application implementing the standard. Therefore the example cannot say that the white space is removed if the space attribute is not specified. (That may be the default for the MS implementation, but not for other standard implementations.) | Proposed change: Qualify example default white-space processing. | ||
GB | 2.3.3.30 [7 on p276]
(continued) |
te | The namespace referenced does not define the possible values. They are defined in the separate XML 1.0 specification, (currently) linked from the namespace reference. | Proposed change: Include definition of supported values or provide dependable link to external definition. | ||
GB | 2.4.1.16 [7] | ed | - | re-word FROM "does this cell ... " TO "whether this cell continues the horizontal merge or starts a new merged group of cells". | ||
GB | 2.4.7 [p302] | te | This element uses bitmasks to specify various table cell formatting properties. The use of bitmasks rather than a set of boolean types makes this data sub-optimal to work with standard XML tools like XSLT which lack bit-level operations. | Proposed change: Rewrite this subclause to express the feature using XML constructs rather than bitmasks. | ||
GB | 2.4.8 [p303] | te | This element uses bitmasks to specify various table cell formatting properties. The use of bitmasks rather than a set of boolean types makes this data sub-optimal to work with standard XML tools like XSLT which lack bit-level operations. | Proposed change: Rewrite this subclause to express the feature using XML constructs rather than bitmasks. | ||
GB | 2.4.46 [p421] | te | 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. | Proposed change: Include in this section the ability to specify that the first N rows of a table can be selected as a header. | ||
GB | 2.4.51 [p428-429] | te | This element uses bitmasks to specify various table cell formatting properties. The use of bitmasks rather than a set of boolean types makes this data sub-optimal to work with standard XML tools like XSLT which lack bit-level operations. | Proposed change: Rewrite this subclause to express the feature using XML constructs rather than bitmasks. | ||
GB | 2.4.52 [p430-431] | te | This element uses bitmasks to specify various table cell formatting properties. The use of bitmasks rather than a set of boolean types makes this data sub-optimal to work with standard XML tools like XSLT which lack bit-level operations.. | Proposed change: Rewrite this subclause to express the feature using XML constructs rather than bitmasks. | ||
GB | 2.5.2.8 [7] | te | The date in the w:fullDate
attribute should be specified in an ISO 8601 format (yyyy-mm-dd) so that
it can be processed by XML processors as an XSD date.
This attribute is inconsistent with respect to the w:date attribute, which requires the use of ISO 8601 format dates. |
Proposed Change:: adopt ISO 8601 dates. | ||
GB | 2.7.3 [16] | ed | See 2.7.3.17 [6 on p690] below. | Replace "w:priority" with "w:uiPriority" | ||
GB | 2.7.3.17 [6 on p690] | ed | It appears that the child w:priority of w:style has been changed to w:uiPriority in the schema and in the tables in the Language Reference but has not been changed in any of the examples throughout the documents I've seen so far. | Replace "w:priority" with "w:uiPriority" | ||
GB | 2.7.3.17 [27 on p690] | ed | See 2.7.3.17 [6 on p690] above. | Replace "w:priority" with "w:uiPriority" | ||
GB | 2.7.5 [4 on p709] | ed | See 2.7.3.17 [6 on p690] above. | Replace "w:priority" with "w:uiPriority" | ||
GB | 2.7.6 [23] | ed | See 2.7.3.17 [6 on p690] above. | Replace "w:priority" with "w:uiPriority" | ||
GB | 2.7.8 [7 on p734] | ed | See 2.7.3.17 [6 on p690] above. | Replace "w:priority" with "w:uiPriority" | ||
GB | 2.8.2.2 [p740, 0xEE] | te | 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. | Proposed change: Explain what is meant by “an Eastern European character set”. | ||
GB | 2.8.2.2 [p740, 2] | te | 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. | Proposed change: Provide normative reference for “the ANSI character set”. | ||
GB | 2.8.2.13 [5] | ed | - | Replace "Pansose-1" with "Panose-1" | ||
GB | 2.8.2.16 [p758-763] | te | This element uses bitmasks to specify various table cell formatting properties. The use of bitmasks rather than a set of boolean types makes this data sub-optimal to work with standard XML tools like XSLT which lack bit-level operations. | Proposed change: Rewrite this subclause to express the feature using XML constructs rather than bitmasks. | ||
GB | 2.11 [6] | ed | - | typo: "storied" | ||
GB | 2.13.4 [20] | te | The w:date attribute is (correctly) shown in ISO 8601 format. This attribute is, therefore, inconsistent with the w:fullDate attribute defined in 2.5.2.8. Inconsistent use of value types in attributes that serve similar purposes will only serve to confuse developers and will inherently lead to errors in coding of applications. | Adopt a consistent ISO 8601 date format for all date representation | ||
GB | 2.13.5.26 [p988] | te | The restriction applied here has no place in a standard. The presence of a move without proper from and to locations is an error and should not be treated as an insertion. This provisio makes it harder for the reader and easier for a writer, but an interchange standard should always make it easier for a reader, whose task is more difficult in any case. This and other similar provisos should be removed from the specification. | Revise the text to address this comment | ||
GB | 2.15.1.14 [p1126] | te | Heading and schema refer to "bordersDoNotSurroundFooter", but text and examples refer to "bordersDontSurroundFooter". | Replace "bordersDontSurroundFooter" with "bordersDoNotSurroundFooter" throughout. | ||
GB | 2.15.1.15 [p1127] | te | Heading and schema refer to "bordersDoNotSurroundHeader", but text and examples refer to "bordersDontSurroundHeader". | Replace "bordersDontSurroundHeader" with "bordersDoNotSurroundHeader" throughout. | ||
GB | 2.15.1.28 [p1158, 7] | re | 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”. | Proposed change: Clarify this contradiction. | ||
GB | 2.15.1.28 [p1158] | te | A hash algorithm is provided, likely based on a legacy algorithm used in Word. 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. | Proposed change: Use a standard, FIPS-180 compliant hash algorithm as the default. Legacy hash algorithms should be supported via the described extension mechanism. | ||
GB | 2.15.1.28 [p1158, 13...] | te | This algorithm description fails to specify the encoding of the input password. Presumably it is Unicode, but in what encoding? UTF-16BE? UTF-16LE? UTF-16 with a BOM (Byte Ordering Mark)? The described algorithms make use of byte-level manipulations which depend on the machine architecture (big endian versus little endian). So it is necessary that all byte ordering assumptions be made explicit. | Proposed change: 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. | ||
GB | 2.15.1.28 [p1158, 16] | te | 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? | Proposed change: Clarify this processing step. | ||
GB | 2.15.1.28 [p1159, 6-9] | te | The described processing steps are ambiguous. In particular SHR and SHL give different results on different machines and with signed and unsigned values | Proposed change: Describe the hash algorithm in a platform independent manner. | ||
GB | 2.15.1.29 [p1172] | te | 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. | Proposed change: Either provide a reasonable document type taxonomy, or loosen the type to an xsd:string to allow applications to provide their own. | ||
GB | 2.15.1.86 [p1251] | te | This element uses bitmasks to specify various table cell formatting properties. The use of bitmasks rather than a set of boolean types makes this data sub-optimal to work with standard XML tools like XSLT which lack bit-level operations. | Proposed change: Rewrite this subclause to express the feature using XML constructs rather than bitmasks. | ||
GB | 2.15.1.87 [p1253] | te | This element uses bitmasks to specify various table cell formatting properties. The use of bitmasks rather than a set of boolean types makes this data sub-optimal to work with standard XML tools like XSLT which lack bit-level operations. | Proposed change: Rewrite this subclause to express the feature using XML constructs rather than bitmasks. | ||
GB | 2.15.2.32 [p1337] | 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 users want their application to produce standards-compliant output? So yes to PNG, no to VML, yes to MathML and SVG? That’s difficult or impossible to achieve! | Proposed change: The proposer must rethink and revise the entire optimizeForBrowser subclause. It looks very much like it is mapping directly to the arbitrary choices of a single vendor's application. This clause should be rewritten to express this feature in an application- and platform-neutral way. | ||
GB | 2.15.3 [p1368] | 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. | Proposed change: Remove the compatibility settings from OOXML. | ||
GB | 2.15.3.6 [p1378] | te | The “autoSpaceLikeWord95” element is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. | Proposed change: Define the intended behavior. | ||
GB | 2.15.3.26 [p1416] | te | The “footnoteLayoutLikeWW8” element is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. | Proposed change: Define the intended behavior. | ||
GB | 2.15.3.31 [p1426] | te | The “lineWrapLikeWord6” is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. | Proposed change: Define the intended behavior. | ||
GB | 2.15.3.32 [p1427] | te | The “mwSmallCaps” element is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. | Proposed change: Define the intended behavior. | ||
GB | 2.15.3.41 [p1442] | te | The “shapeLayoutLikeWW8” element is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. | Proposed change: Define the intended behavior. | ||
GB | 2.15.3.51 [p1462] | te | The “suppressTopSpacingWP” element is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. | Proposed change: Define the intended behavior. | ||
GB | 2.15.3.53 [p1467] | te | The “truncateFontHeightsLikeWP6” element is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. | Proposed change: Define the intended behavior. | ||
GB | 2.15.3.54 [p1469] | te | The “uiCompat97To2003” element is defined as: “Disable UI functionality that is not compatible with Word97-2003”. But what use is this for a user using OOXML in OpenOffice or WordPerfect Office? What if that user wants to disable UI functionality that is not compatible with OpenOffice 1.5? Or WordPerfect 8? Or any other application? Where is the ability for other implementations to specify their preferences? | Proposed change: 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. | ||
GB | 2.15.3.63 [p1481] | te | The “useWord2002TableStyleRules” element is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. | Proposed change: Define the intended behavior. | ||
GB | 2.15.3.64 [p1482] | te | The “useWord97LineBreakRules” element is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. | Proposed change: Define the intended behavior. | ||
GB | 2.15.3.65 [p1483] | te | The “wpJustification” element is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. | Proposed change: Define the intended behavior. | ||
GB | 2.15.3.66 [p1485] | te | The “wpSpaceWidth” element is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. | Proposed change: Define the intended behavior. | ||
GB | 2.16.1 [p1487] | te | The production rule for field-switch-character is defined as: “field-switch-character: ! one or two Latin letters” However, “Latin letters” is not defined in this specification. Are we to take this literally as only allowing the letters used in Latin, i.e., capital letters A-Z excluding J, U and W? Or is meant the ISO 8859-1, the Latin-1 character set? Or is something else meant? | Proposed change: Provide a precise definition for this production rule. | ||
GB | 2.16.3 [p1581] | ed | Incorrect capitalization and typo in example | Substitute "fldChar" for "fldchar" in example. Substitute "separate" for "seperate" in example. | ||
GB | 2.16.4 [p 1497, day names in different languages] | ed | The instruction ddd "Formats the day of the week or month in its abbreviated form according to the language specified by the lang element (§2.3.2.18) on the run containing the field instructions." There is a similar instruction for month names. There is no list of these names referenced in the specification. | Proposed change: Provide a normative reference to the day and month names used to be used. | ||
GB | 2.16.4.3 [p1501] | te | The definition for BATHTEXT references 'the given Thai format', which makes no sense in the context of that definition. What “given Thai format”? | Proposed change: Clarify the definition of 'BATHTEXT'. | ||
GB | 2.16.5.1 [p 1509, address formats in different countries] | te | The switch \d "Specifies that the address is to be formatted according to the country/region of the recipient." There is no list of address formats in the specification. | Proposed change: Provide a normative reference to the address formats to be used. | ||
GB | 2.16.5.3 [p 1511, missing default for ASK response] | te | The switch \d specifies a default response. "If no default response is specified, the most recent response is used". No behaviour is specified if there is no prior response. | Proposed change: Document the behaviour if there is no default specified, and no prior response. | ||
GB | 2.16.5.5 [p1512, 11-12] | te | According to the text, the AUTONUM field is deprecated. A new standard should not contain deprecated parts. | Proposed change: Remove all references to AUTONUM from the OOXML text. | ||
GB | 2.16.5.6 [p1513] | te | AUTONUMLGL is deprecated - see the comments on AUTONUM. | Revise the text to address this comment | ||
GB | 2.16.5.7 [p1514] | te | AUTONUMOUT is deprecated - see the comments on AUTONUM. | Revise the text to address this comment | ||
GB | 2.16.5.8 [p1515] | te | AUTOTEXT "Inserts the AutoText entry whose name is specified by text in field-argument. Regarding XML generation, the field result is the value of the autotext.". What does this mean? Does it mean that it is possible to use AUTOTEXT to generate OOXML elements that should be parsed? What is the behaviour if that generated OOXML contains further AUTOTEXT elements? How can a document containing the AUTOTEXT element be validated if it can self-modify? | Proposed change: Clarify this text. Add an example of XML generation. Describe the behaviour if AUTOTEXT is present recursively. Describe the implications for validation. | ||
GB | 2.16.5.8 [p1515] | te | The AUTOTEXT entry "can be arbitrarily complex and involve VML". VML is deprecated elsewhere in the specification. Non-deprecated components should not depend on deprecated components. | Proposed change: Either deprecate AUTOTEXT, or replace the use of VML within it with the use of DrawingML. | ||
GB | 2.16.5.10 [p1516] | te | BARCODE produces barcodes in FIM or POSTNET format. There is no reference to a definition of these formats. | Proposed change: Provide a reference to FIM and POSTNET formats. | ||
GB | 2.16.5.12 [p1518] | te | BIDIOUTLINE replicates the AUTONUMOUT command, except for differences in Arabic/Hebrew numbering. AUTONUMOUT is deprecated. BIDIOUTLINE should likewise be deprecated if it replicates a deprecated command. | Proposed change: Deprecate BIDIOUTLINE in normative text. | ||
GB | 2.16.5.16 [p1524 definition of calendars] | te | Various calendars (the Saka Era, the Gregorian calendar, and the Lunar/Hijri calendar) are mentioned in the specification without a reference to a definition of those calendars. This is particularly serious for the Gregorian calendar here, because the specification doesn't make clear what sort of Gregorian calendar it is (and calendars such as GregorianXLitEnglish are mentioned elsewhere in the specification). | Proposed change: Provide a reference to the formal definition of those calendars used within the specification. | ||
GB | 2.16.5.18 [p1524] | te | The \l switch specifies "If no date-and-time-formatting-switch is used, the date shall use the date format last used by the hosting application when inserting a new DATE field". There is no behaviour specified when a date format has not previously been used. | Proposed change: Specify the behaviour when \l is used and there is no previous date format. | ||
GB | 2.16.5.22 [p1527] | te | The EQ command allows equations to be inserted. This is using a different mechanism from the one specified in the Math section of the SharedML. There should not be multiple non-deprecated methods for defining equations defined within the specification. | Proposed change: Deprecate the EQ command in favour of the Math markup language. | ||
GB | 2.16.5.24 [p1532] | te | FILESIZE can "round to the nearest kilobyte". The example specifies a file with 4660736 bytes and gives the result of rounding to the nearest kb as 4661 - this is incorrect. It should be 4552, since there are 1024 bytes in a kilobyte. | Proposed change: Correct the example to match the specification. | ||
GB | 2.16.5.33 [p1537] | te | This field 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? | Proposed change: Define what is to be done with the picture once it is retrieved. | ||
GB | 2.16.5.33 [p1537] | te | This does not define how a picture is named (field-argument). 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. | Proposed change: Define how pictures are named. | ||
GB | 2.16.5.33 [p1537] | te | This subclause defines an INCLUDEPICTURE field which “Retrieves the picture contained in the document named”. However, no mention is made of what formats are permissible for the picture. | Proposed change: There should be specified at least a small set of interoperable formats. | ||
GB | 2.16.5.34 [p1537-1538] | te | This does not define how a document is named (field-argument-1). 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. | Proposed change: Define how documents are named. | ||
GB | 2.16.5.34 [p1538] | te | This subclause defines an INCLUDETEXT field which “Inserts all or part of the text and graphics contained in the document named”. However, no mention is made of what formats are permissible for the retrieved text. | Proposed change: There should be specified at least a small set of interoperable formats. | ||
GB | 2.16.5.34 [p1538] | 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. | Proposed change: Provide a proper external normative reference for the XSLT which is allowed here. | ||
GB | 2.16.5.35 [p1539] | ed | "The text in this switch's field-argument is specifies the language ID" | Proposed change: Remove "is" | ||
GB | 2.16.5.40 [p1543, 12-13] | te | 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'. | Proposed change: Expand or reference the definition for 'series', and/or clarify the definition for 'LISTNUM' by any appropriate means. | ||
GB | 2.16.5.41 [p1545] | te | This describes a “MACROBUTTON” field which can run a designated macro or command. But there is no mention of what programming language or API's are allowed for such a designated macro or command. | Proposed change: Described this feature to a level where cross-platform, cross-application interoperability is possible. | ||
GB | 2.16.5.53 [p1552] | te | The PRINT field specifies PostScript strings to be sent to the printer. Presumably this is only on printing of the document, but the specification does not make this explicit. | Proposed change: Make it explicit that PostScript within a PRINT field should only be sent to the printer when the document is printed.. | ||
GB | 2.16.5.77 [p1570] | te | The example that illustrates USERINITIALS section instead shows USERNAME. | Proposed change: Correct the example. | ||
GB | 2.16.19 [p1591] | te | Apparently the fldData element contains custom data which must be preserved, but the contents of which are undefined. In other words, this is a place where the legacy format is not being specified.. It should be deleted or explained. Similarly 2.16.20. | The proposer must clarify the purpose of this construct. | ||
GB | 2.16.20 [p1591/2] | te | Same comment as 2.16.19. | Revise the text to address this comment | ||
GB | 2.16.25 [p1604] | te | Incorrect capitalization and typo in example | Substitute "fldChar" for "fldchar" in example. Substitute "separate" for "seperate" in example. | ||
GB | 2.18.4 [p1631...] | 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. | Proposed change: Provide full normative definitions for these graphical elements. Also, for informative purposes, these graphics may be provided in standalone file form, preferably in a scalable graphics format like SVG. | ||
GB | 2.18.4 [p1631...] | 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. | Proposed change: Provide an interoperable extensibility mechanism for a document author or application to specify their own art border graphics. | ||
GB | 2.18.7 [p1690] | te | Various calendars are mentioned in the specification (Saka Era, Taiwan, Gregorian, GregorianXLitEnglish, etc.) without a reference to a definition of those calendars. | Proposed change: Provide a reference to the formal definition of those calendars used within the specification. | ||
GB | 2.18.45 [p1737] | te | Length is said to be “exactly 3 characters”. This is inconsistent with the example given which has a length of 6 characters. | Proposed change: Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters. | ||
GB | 2.18.51 [p1747] | 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. | Proposed change: Drop the use of the redundant ST_LangCode | ||
GB | 2.18.51 [p1747, 22] | ed | Double quotes used incorrectly, with two sets of close quotes. | Proposed change: XML examples should be given using straight quotes | ||
GB | 2.18.52 [p1748] | te | This type is defined as containing, “a two digit hexadecimal language code”. It is further 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. | Proposed change: Reconcile the description of the type with the enumerated values. | ||
GB | 2.18.57 [p1759] | 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. | Proposed change: Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters. | ||
GB | 2.18.66 [p1771] | te | The formatting system described here is not comprehensive, lacking, for example, support for Armenian, Tamil, Greek alphabetic, Ethiopic and Khmer numerations, all in use today, as well as the various historical systems still used by scholars. | Proposed change: Use a more flexible, extensible, generative approach to numeration, such as that used by the W3C's XSLT standard in their xsl:number support | ||
GB | 2.18.66 [p1771] | te | There is nothing in this section which is normatively defined except some enumeration values. No normative meanings to these values are given. An informative example is insufficient in all but the most trivial cases. For example, where is “Korean Legal Counting System” defined? | Proposed change: Give explicit definitions of these numbering styles or proper external normative references. | ||
GB | 2.18.66 "chicago" [p1772] | ed | Format is defined in reference to the “Chicago Manual of Style”, but no edition or page reference is provided. | Proposed change: Either include the entire definition in the standard, or provide a proper external reference. | ||
GB | 2.18.66 “decimalEnclosedFullstop” [p1772] | te | The example given does not show enclosed characters and so contradicts the normative text. | Proposed change: Reconcile the text and the example. | ||
GB | 2.18.66 “decimalFullwidth”, etc. [p1773] | te | There are several mentions of double-byte and single-byte Arabic numbering schemes. Since the conformance clause for OOXML requires the use of Unicode in UTF8 or ITF16 encodings, there should be no mention of other encodings. | Proposed change: Reconcile the text and the conformance clause. | ||
GB | 2.18.66 “lowerLetter”, etc. [p1776] | te | 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. | Proposed change: Clarify the text to explicitly cover this case. | ||
GB | 2.18.66 “numberInDash”, etc. [p1776] | te | Format requires use of “dash” to surround the number, but no indication of which Unicode dash is intended, en-dash, em-dash, hyphen-minus, figure-dash, quotation-dash, etc. | Proposed change: Specify the intended dash explicitly. | ||
GB | 2.18.72 [p1786] | te | No definition is provided for a “Panose-1 classification” of a font. | Proposed change: Provide a proper external normative reference for this term. | ||
GB | 2.18.72 [p1786] | te | Length is said to be “exactly 10 characters”. This is inconsistent with the example given which has a length of 20 characters. | Proposed change: Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters. | ||
GB | 2.18.85 [p1800] | 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? | Proposed change: Provide full normative definitions for these graphical elements. | ||
GB | 2.18.86 [p1808] | te | 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. | Proposed change: Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters. | ||
GB | 2.18.106 [p1837] | te | Length is said to be “exactly 1 characters”. This is inconsistent with the earlier language and the schema fragment given which defines it as being 1 octet long or two characters. | Proposed change: Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters. | ||
GB | 3.2.29 [p1915-1923 ] | te | A hash algorithm is provided, likely based on a legacy algorithm used in Excel. This legacy algorithm is known to be a weak algorithm and has effectively been cracked. One could argue that no hash algorithm would be effective in OOXML, since a user could simply unzip the document and hand edit the XML to remove the hash or to set it to some known value. However, some application types such as online editing via Google Docs, or other similar applications, can secure physical access to the document via other means. Editing access to the document does not necessarily presuppose physical access to the document's XML. So there is a necessity for a secure & interoperable hash algorithm, such as SHA-256 for document protection. | Proposed change: Use a standard, FIPS-180 compliant hash algorithm as the default. Legacy hash algorithms should be supported via the described extension mechanism. | ||
GB | 3.2.29 [p1916, Armenian and Ethiopic ] | te | This seems to imply that if a password is entered in a script like Armenian or Ethiopic then the characters will be replaced all by a single character 0x3F, making the protection feature useless. This is unacceptable. | Proposed change: Remedy so password hashes can be calculated on any Unicode password. | ||
GB | 3.2.29 [p1916, input password encoding ] | te | This algorithm description fails to specify the encoding of the input password. Presumably it is Unicode, but in what encoding? UTF-16BE? UTF-16LE? UTF-16 with a BOM (Byte Ordering Mark)? The described algorithms make use of byte-level manipulations which depend on the machine architecture (big endian versus little endian). So it is necessary that all byte ordering assumptions be made explicit. | Proposed change: 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. | ||
GB | 3.2.29 [p1916, input password conversion ] | te | 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? | Proposed change: Clarify this processing, especially for passwords that use characters from more than one script. | ||
GB | 3.2.29 [p1917-1922 ] | te | 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. | Proposed change: 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. | ||
GB | 3.3.1.61 [p1988, paperSize ] | ge | The paperSize 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. | Proposed change: Rather than trying to maintain a paper size registry, a more flexible approach would be to simply record the dimensions of the paper size selected. | ||
GB | 3.3.1.69 [p2003-2004 ] | te | 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. | Proposed change: 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. | ||
GB | 3.3.1.69 [p2004, hashing algorithm ] | te | A hash algorithm is provided, likely based on a legacy algorithm used in Excel. This legacy algorithm is known to be a weak algorithm and has effectively been cracked. One could argue that no hash algorithm would be effective in OOXML, since a user could simply unzip the document and hand edit the XML to remove the hash or to set it to some known value. However, some application types such as online editing via Google Docs, or other similar applications, can secure physical access to the document via other means. Editing access to the document does not necessarily presuppose physical access to the document's XML. So there is a necessity for a secure & interoperable hash algorithm, such as SHA-256 for document protection. | Proposed change: Use a standard, FIPS-180 compliant hash algorithm as the default. Legacy hash algorithms should be supported via the described extension mechanism. | ||
GB | 3.3.1.69 [p2004, securityDescriptor ] | 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. | Proposed change: Fully define this attribute. | ||
GB | 3.17.4.1 [p2522, 14] | 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. | Proposed change: Allow a range of vendor-declared date bases, or explicitly allow negative date serial values to express dates prior to 1900 | ||
GB | 3.17.4.1 [p2522, 15] | 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. | Proposed change: If needed for legacy reasons with legacy Excel documents, then introduce an additional vendor-specific tag such as “doWrongDateCalculationsLikeExcel” or similar. This is the approach recommended elsewhere in OOXML for legacy Word features. | ||
GB | 3.17.4.1 [p2522, 14-18] | te | The text proposes a dual date base system. There is no clear advantage to having two slightly different systems, and this brings significant costs and confusion, as illustrated by the need to specify a default base system, etc. | Proposed change: Choose and keep a single date system. | ||
GB | 3.17.4.1 [p2522, 16 and 18] | te | The documented upper limits for serial date times match 9999-12-31 00:00:00, which is most probably not what was intended. The expected upper limits would match 9999-12-31 23:59:59. | Proposed change: Clarify the upper limits. | ||
GB | 3.17.4.1 [p2522, 19] | te | The proposed date system does not cope with dates prior to 1900-01-01. | Proposed change: Adopt a better date system. | ||
GB | 3.17.7.341 [p2818-2819] | te | As written this function mandates an incorrect calculation for day of week for certain dates in the year 1900. An ISO standard should not be mandating incorrect values for the well-established Gregorian Calendar. To do so will only lead to confusion, poor interoperability and perpetuation of errors. | Proposed change: Remove the text that defines behavior that results in incorrect date calculations. | ||
GB | 3.18.86 [p2929-2930] | te | 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. | Proposed change: Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters | ||
GB | 3.18.87 [p2930] | te | 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. | Proposed change: Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters. | ||
GB | 5.1.3.2 [p3292] | te | No mention is made of what audio formats or codecs are permitted. | Proposed change: An interoperable set of formats should be specified. | ||
GB | 5.1.3.4 [p3294] | 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. | Proposed change: Provide an external reference for the version(s) of QuickTime format intended here as well as an interoperable codec. | ||
GB | 5.1.12.28 [p3700] | te | This type is used in only two places, 5.1.2.2.32 and 5.1.2.2.33, in both cases to represent an RGB color value. Since you already have defined a ST_HexColorRGB type that should be used. | Proposed change: Use the ST_HexColorRGB type and remove ST_HexBinary3 | ||
GB | 5.1.12.28 [p3700] | te | 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. | Proposed change: Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters. | ||
GB | 5.1.12.37 [p3719] | ed | No definition is provided for a “Panose setting of a font”. | Proposed change: Provide a proper external normative reference for this term. | ||
GB | 5.1.12.37 [p3719] | te | 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. | Proposed change: Describe the intended font matching procedure. | ||
GB | 5.1.12.37 [p3719] | te | Why are there several different definitions for a Panose value, both in Word Processing ML as well as Drawing ML? | Proposed change: Because the definitions are exactly the same, they should be defined once in a shared schema. | ||
GB | 5.1.12.37 [p3719] | te | Length is said to be “exactly 10 characters”. This is inconsistent with the schema fragment given which defines it as being 10 octets long. | Proposed change: Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters. | ||
GB | 5.1.12.50 | ed | The appearance of shapes for ST_PresetMaterialType values should be defined verbally using the vocabulary of computer 3D rendering (e.g. specular highlight values). | Revise the text to address this comment | ||
3. SpreadsheetML Reference Material | ||||||
GB | Throughout [xsd:boolean] | te | There are hundreds of instances
where invalid xsd:boolean attribute values are used. For example, take
part 4, 3.10.1.90 "sharedItems. In the definition of the attributes
containsBlank, containsDate, it says:
"Specifies a boolean value that indicates whether this field contains a blank value. A value of on, 1, or true indicates this field contains one or more blank values. A value of off, 0, or false indicates this field does not contain blank values. The possible values for this attribute are defined by the XML Schema boolean datatype." However, XML Schema 3.2.2.1 (http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#boolean) defines allowed lexical value space for xsd:boolean as: "An instance of a datatype that is defined as boolean can have the following legal literals {true, false, 1, 0} " "On" and "Off" are not allowed values. |
Proposed change: Either change the text to remove the "on" and "off" options or change the schema reference to the ST_OnOff type defined in 2.18.67, which does allow this set of values. | ||
GB | 3.2.1 [2] | ed | "each view can specifies": | change to "...can specify" | ||
GB | 3.2.2 p.1876, row 2, col 2 [3] | ed | When you use open a workbook": | delete "use" or "open" as appropriate. | ||
GB | 3.2.2 p.1877, row "forceFullCalc", col 2 [5-6] | ed | "recalculation of workbook": | change to "...the workbook" | ||
GB | 3.2.2 p.1877, row "forceFullCalc", col 2 [8] | ed | "when the workbook.": | supply omitted closing text | ||
GB | 3.2.2 p.1879, row "refMode", col 2 [2] | ed | "this options": | change to "...option" | ||
GB | 3.2.3 p.1880, row "activeSheetId", col 2 [2]: | ed | "Correpsonds": | change to "Corresponds" | ||
GB | 3.2.3 p.1884, row "tabRatio", col 2 [1] | ed | - | change "Specified" to "Specifies" | ||
GB | 3.2.5 p.1889, row "vbProcedure", col 2 [1]: | ed | - | change "Specified" to "Specifies" | ||
GB | 3.2.11 p.1894, row "autoRecover", col 2 [5]: | ed | - | change "/false." to "false" | ||
GB | 3.2.12 p.1895 [9] | ed | "This element tracks file sharing File sharing settings": | delete second occurrence of "File sharing" | ||
GB | 3.2.24 p.1905, row "allowPng", col 2: | ed | - | change "...indicates does not..." to "...indicates the application does not..." | ||
GB | 3.2.24 p.1905, row "codePage", col 2: | ed | change "A code is table..." to "A code page is a table..." | |||
GB | 3.2.27 [20] | ed | "...represent descriptive that...": | supply omitted text after "descriptive" | ||
GB | 3.2.28 p.1911, row "allowRefreshQuery", col 2: | ed | - | change "will refresh query table" to "will refresh query tables" | ||
GB | 3.2.28 p.1912, row "filterPrivacy", col 2: | ed | "application has been inspected
the workbook": remove "been"
"the user performs do an action": delete "do" "comment might inserts": change to "insert" |
|||
GB | 3.3 [p.1926, 22-23] | ed | “Sheets often have Workbooks usually contain more than one sheet.” | Change to:”Sheets often have Workbooks which usually contain more than one sheet.” | ||
GB | 3.3.1.17 [p.1945, 26] | ed | - | “applicaiton” Change to”application” | ||
GB | 3.3.1.31 [p.1960, 24] | ed | - | “specify constaints” change to”specify constraints”. | ||
GB | 3.3.1.37 [p.1968, final row ] | ed | - | “not subsequent formula's” change to”not subsequent formulas” | ||
GB | 3.3.1.41 [p.1971, line 3] | ed | - | “It used as a bounds” change to”It is used as a bounds” | ||
GB | 3.3.1.41 [p.1971, 8] | ed | - | “It used as a bounds” change to”It is used as a bounds” | ||
GB | 3.3.1.47 [p.1976, 6] | ed | - | “Note that this simply a guess” change to”Note that this is simply a guess” | ||
GB | 3.3.1.69 [p.2003, 17] | ed | - | “may be ignored by applications who choose not to support this functionality” change to”may be ignored by applications which choose not to support this functionality”?? | ||
GB | 3.3.3.83 [p.2025, 10] | ed | - | “sheet. containing” change to”sheet containing” | ||
GB | 3.3.1.95 [p.2040, 14] | ed | - | “Note:When” add space to change to”Note: When” | ||
GB | 3.3.2.5 [p.2047, 15] | ed | - | change”fitler” to”filter” | ||
GB | 3.3.2.10 [p.2052, 6] | ed | - | “repsectively” change to”respectively” | ||
GB | 3.4 [p.2053, 9] | ed | - | “a tremendous savings” change to”a tremendous saving” | ||
GB | 3.5.1.3 [p.2074, final row] | ed | - | “… so it shall should only be used” – delete”shall” | ||
GB | 3.5.1.5 [p.2076, 11] | ed | - | “Styles define set of formatting properties” change to”Styles define a set of formatting properties” | ||
GB | 3.6.1 [p.2086, 3] | ed | - | “Cell's are calculated” change to”Cells are calculated” | ||
GB | 3.7 [p.2087, 21] | ed | - | “attached to & associated” change to”attached to and associated” | ||
GB | 3.7.3 [p.2089, 15] | ed | - | “This element represents a single user entered comment..” delete additional fullstop | ||
GB | 3.8.31 [p.2136, Description and Result Table] | ed | \ -”Display the next character
in the format.” Change to”Displays the next character in the format.”
(underline) –”Skip the width of the next character” change to”Skips the width of the next character” “text” –”Display whatever text” change to”Displays whatever text” |
|||
GB | 3.8.36 [p.2146, 12] | ed | - | “body & paragraph” change to”body and paragraph” | ||
GB | 3.10 [p.2232, 10] | ed | - | “row & column axes” change to”row and column axes” | ||
GB | 3.10.1.22 [p.2267, 15] | ed | - | “that’s derived from” change to”that is derived from” | ||
GB | 3.10.1.22 [p.2267,16] | ed | - | “that's labeled” change to”that is labeled” | ||
GB | 3.10.1.46 [p. 2300, 4] | ed | - | “Therefore f you” change to”Therefore if you” | ||
GB | 3.1.10.59 [p.2315, 6] | ed | - | “additional information that's” change to”additional information that is” | ||
GB | 3.11 [p. 2400, 14] | ed | - | “update it's own state” change to”update its own state” | ||
GB | 3.17 [p2507..., throughout] | te | Many of the financial functions rely on a “day count basis” value that is not defined in this standard. Without this level of definition implementors will not be able to evaluate these functions | Proposed change: Provide a full definition of “day count basis”, in particular with respect to treatment of leap years and leap days. | ||
GB | 3.17.2 [p2508, 16, 17] | te | The reference to the definition of the space operator is broken ('§0'). | Revise the text to address this comment | ||
GB | 3.17.2.1 [p2509, Constants ] | te | The syntax of constants is defined using an unspecified notation, that appears to borrow some characteristics of Backus-Naur Form for grammar productions, some notations from popular ways of specifying command line applications options, etc., all without formally defining the notation used. Note that other parts of the syntax for formulas similarly lack a proper format definition. The reference to the “constants” section is one example. | Proposed change: Either adopt a formal lexical-syntactic notation by reference (for example ISO 14977:1996 EBNF), or explicitly define one. | ||
GB | 3.17.3 [p2521, #DIV/0!] | te | The “note” for this error value appears to define required behavior, not informative remarks. | Proposed change: Make the contents of the note be part of the main text, not as a note. | ||
GB | 3.17.4.1 [14-18] | te | Historical dates preceding 1st March 1900 cannot be recorded as dates in OOXML spreadsheets. This makes them unsuitable for genological work, etc, where sorting by date prior to 1900 is often a requirement. | Proposed change: Modify the text to accommodate such dates properly.. | ||
GB | 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.
As currently defined an OOXML spreadsheet may not express a date prior to January 1st, 1900. Microsoft Excel has a similar restriction. However, the other spreadsheets that have announced a desire to implement OOXML allow a broader range of date values in their spreadsheets. For example, Corel's Quattro Pro supports dates back to 3/1/1800, while OpenOffice , which Novell is adding OOXML support to, allows date back to 1 A.D. So it seems unwise to limit the date support to the more limited capabilities of Excel. We should offer vendors the choice to use a date origin of their choice, so long as they declare it in their documents. Excel could continue to declare a 1900 (or 1904) date basis, but other vendors could express their full capabilities. Remember, there are people alive today, receiving government benefits, housing, pensions, healthcare, etc., who were born before 1900. As defined now, OOXML cannot represent their date of birth. Supporting dates 8,000 years into the future are not as useful, from a practical perspective, as supporting dates back a few hundred years in the past. Of course, each application vendor may have their own priorities. |
Proposed change: Allow a range of vendor-declared date bases, or explicitly allow negative date serial values to express dates prior to 1900 | ||
GB | 13.17.4.2 [24-25] | te | The use of decimal values to represent time within a day that require incrementing by 1/864 for each 1/100th of a second makes it difficult to convert SpreadsheetML times to ISO 8601 format datetimes accurately. | Use a more naturally-processable mechanism.. | ||
GB | 13.17.6.7 [29] | te | The phrase "as accurately as possible" is ambiguous and should not be used in a standard. This phrase suggests that the points raised in reference to 13.17.4.2 [24-25] are significant and that it is not possible to accurately move from the decimal representation of time to an XML processible one. | Define the bounds of accuracy precisely. | ||
GB | 13.17.6.7 [4] | te | The date1904 attribute should be shown with the boolean value of "true" rather than its numeric representation 1 to avoid any ambiguity. | Revise the text to address this comment | ||
GB | 13.17.6.7 [28-4] | te | Dates as stored in SpreadsheetML are not processible by other applications of XML as they are not defined using the standard XML datetime datatype. It would be an easy matter to add an extra attribute, ISO8601datetime, to the representation that would allow a processible form of the date to be associated with the XML record of each SpreadsheetML specific date. | Revise the text to address this comment | ||
GB | 13.17.6.7 [p2529, 29] | te | This calls for the date serial number to be stored, “as accurately as possible”. This requirement is not precise and is untestable. Further, “as accurately as possible” may entail the use of codes such as arbitrary precision arithmetic, etc. which would have large performance penalties. | Proposed change: State the minimum precision required. | ||
GB | 13.17.7 [p2530] | te | There appears to be a production issue in the creation of the PDF version of this DIS. Many of the mathematical formulas that define the spreadsheet functions are illegible, and all of them are of low quality. For example, 3.17.7.24, 3.17.7.32, 3.17.7.38, etc. | Proposed change: Provide higher resolution of the mathematical equations. | ||
GB | 13.17.7.4 [p2536, ACOS] | te | It is not indicated whether the returned value shall be in radians or degrees | Proposed change: Specify the angular units that should returned. | ||
GB | 13.17.7.9 [p2541, AND] | te | It is not specified whether this function short-circuits or not. In other words, must the remaining arguments be evaluated once one of them is found to be FALSE? Since some functions have side effects, it is necessary to define this in order to ensure interoperability. | Proposed change: Specify whether this function allows short-circuit evaluation. | ||
GB | 13.17.7.11 [p2542, ASC] | te | 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? | Proposed change: Provide a full definition of this function. | ||
GB | 13.17.7.12 [p2542, ASIN] | te | It is not indicated whether the returned value shall be in radians or degrees. | Proposed change: Specify the angular units that should returned. | ||
GB | 3.17.7.14 [p2544, ATAN] | te | It is not indicated whether the returned value shall be in radians or degrees. | Proposed change: Specify the angular units that should returned. | ||
GB | 3.17.7.15 [p2544, ATAN2] | te | It is not indicated whether the returned value shall be in radians or degrees. | Proposed change: Specify the angular units that should returned. | ||
GB | 3.17.7.17 [p2546, AVEDEV argument-list] | te | The function description has a typo/duplication: “cells with the value 0value 0” | Proposed change: Fix the typographical error | ||
GB | 3.17.7.17 [p2546, AVEDEV example] | te | 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. | Proposed change: Provide a correct example. | ||
GB | 3.17.7.34 [p2560, CELL] | te | 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? | Proposed change: Specify what happens in this case. | ||
GB | 3.17.7.35 [p2563, CHAR] | te | This function maps between numbers and characters. But this mapping must be defined b y a character set and none is defined here. | Proposed change: Specify what character set is used for this mapping. | ||
GB | 3.17.7.37 [p2564, CHIINV 15] | te | This function says, “CHIINV uses an iterative search technique”. This is specifying an implementation, not a testable performance criterion. Other approaches should be permitted. | Proposed change: Keep the suggestions, but put them in informative Notes or Guidance. | ||
GB | 3.17.7.38 [p2564, CHITEST 15] | te | 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? | Proposed change: Specify the required results for the case where the two ranges are of unequal size. | ||
GB | 3.17.7.47 [p2564, CHIINV 15] | te | This function cannot be calculated without making an assumption about the distribution of the data? Are we assuming normally distributed data? uniformly distributed data? | Proposed change: Make the distribution assumptions explicit. | ||
GB | 3.17.7.48 [p2572, CHANGE 15] | te | 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. | Proposed change: Refine the definition of this function, especially with respect to pre-metric measures so as to remove ambiguity. Page. | ||
GB | 3.17.7.49 [CORREL] | te | The definition of the arguments in the function is incorrect. It should say that x-bar and y-bar are the sample means, not x and y. | Proposed change: Correct the text | ||
GB | 3.17.7.50 [COS] | te | It is not indicated whether the parameter is in radians or degrees | Proposed change: Specify the angular units that this parameter is in. | ||
GB | 3.17.7.63 [COVAR] | te | The definition of the arguments in the function is incorrect. It should say that x-bar and y-bar are the sample means, not x and y. | Proposed change: Correct the text | ||
GB | 3.17.7.65 [CUBEKPIMEMBER] | te | The “kpi-property” parameter lists a number of values which are undefined such as “temporal context”, “relative importance”, etc. This is made even more cryptic by the fact that this function, unlike almost all the others, has examples that fail to illustrate the returned values. If there is to interoperability in the use of this function, semantics in additional to syntax will need to be specified. | Proposed change: Provide the semantics for this function | ||
GB | 3.17.7.65 [CUBEKPIMEMBER] | te | 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? | Proposed change: Provide a vendor-neutral definition of this function. | ||
GB | 3.17.7.66 [CUBEMEMBER] | te | This function refers to, “A multidimensional expression (MDX) that evaluates to a unique member in the cube”. But MDX is undefined. | Proposed change: Define the syntax and semantics of an MDX | ||
GB | 3.17.7.74 [DATE] | te | The definition of date normalization is rather loose. The UK imagines the text might want to say something like this; “if 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”. | Proposed change: Clarify the definition of date normalization. | ||
GB | 3.17.7.76 [DATEVALUE] | te | This function says that it can take a string in any valid date and/or time format. It further says that if the year portion of the input string is 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? Or assume January 1st of the current year? | Proposed change: Resolve the ambiguity in the definition when a string with time format is passed in. | ||
GB | 3.17.7.77 [DAVERAGE] | te | 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. | Proposed change: Rework the note into the normative description of this function. | ||
GB | 3.17.7.78 [DAY] | te | 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? | Proposed change: Define fully what this function returns. | ||
GB | 3.17.7.89 [DEVSQ] | ed | The function description has a typo/duplication: “cells with the value 0value 0” | Proposed change: Fix the typographical error | ||
GB | 3.17.7.91 [DISC] | ed | 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. | Proposed change: Recommend the use of the generic currency sign here (U+00A4). | ||
GB | 3.17.7.95 [DOLLARDE] | te | 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. | Proposed change: Clarify how this function works | ||
GB | 3.17.7.96 [DOLLARFR] | ed | 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. | Proposed change: Rework the note into the normative description of this function. | ||
GB | 3.17.7.101 [DURATION] | ed | 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. | Proposed change: Recommend the use of the generic currency sign here (U+00A4) | ||
GB | 3.17 [throughout] | ed | The mathematical formula given in many places borders on unreadable and compares very poorly with the clarify of the rest of the text and most other images. | Proposed change: Provide better quality mathematical formula. | ||
GB | 3.17.7.111 [EXACT] | te | 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. | Proposed change: Clarify what defines two strings as having identical content. | ||
GB | 3.17.7.118 [FIND] | te | Similar issue to EXACT. Is this a lexical comparison or collation-based? | Proposed change: Clarify the basis for finding substrings | ||
GB | 3.17.7.119 [FINDB] | te | Similar issue to EXACT. Is this a lexical comparison or collation-based? | Proposed change: Clarify the basis for finding substrings | ||
GB | 3.17.7.120 [FINV] | te | This function says, “FINV uses an iterative search technique”. This is specifying an implementation, not a testable performance criterion. Other approaches should be permitted. | Proposed change: Keep the suggestions, but put them in informative Notes or Guidance. | ||
GB | 3.17.7.123 [FIXED] | te | The rounding algorithm is not specified. How for example, do we calculate FIXED(0.5,0)? | Proposed change: State what the rounding conventions are. | ||
GB | 3.17.7.125 [FORCAST] | te | The definition of the arguments in the function is incorrect. It should say that x-bar and y-bar are the sample means, not x and y. | Proposed change: Correct the text | ||
GB | 3.17.7.131 [GAMMAINV] | ed | This function says, “GAMMAINV uses an iterative search technique”. This is specifying an implementation, not a testable performance criterion. Other approaches should be permitted. | Proposed change: Keep the suggestions, but put them in informative Notes or Guidance. | ||
GB | 3.17.7.143 [HOUR] | te | This function returns the hour given a date/time value. However, the text says, “The returned value shall be in the range 0–59.” Surely the hour should be in the range 0-23? | Proposed change: Correct the text | ||
GB | 3.17.7.144 [HYPERLINK] | te | 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. | Proposed change: Provide a normative definition or reference for a UNC path. | ||
GB | 3.17.7.169 [INTERCEPT] | te | The definition of the arguments in the function is incorrect. It should say that x-bar and y-bar are the sample means, not x and y. | Proposed change: Correct the text | ||
GB | 3.17.7.172 [IRR] | te | This text says, “IRR uses an iterative calculation technique”. This is specifying an implementation, not a testable performance criterion. Other approaches should be permitted. | Proposed change: Keep the suggestions, but put them in informative Notes or Guidance. | ||
GB | 3.17.7.186 [KURT] | te | 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” | Proposed change: Provide the complete definition | ||
GB | 3.17.7.186 [LINEST] | te | The definition of the arguments in the function is incorrect. It should say that x-bar and y-bar are the sample means, not x and y. | Correct the text | ||
GB | 3.17.7.201 [LOWER] | te | 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. | Proposed change: Clarify what it means to convert to lower case. | ||
GB | 3.17.7.206 [MDURATION] | ed | 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. | Proposed change: Recommend the use of the generic currency sign here (U+00A4) | ||
GB | 3.17.7.207 [MEDIAN] | te | 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...” | Proposed change: Clarify the definition. | ||
GB | 3.17.7.227 [NORMINV] | ed | This text says, “NORMINV uses an iterative search technique”. This is specifying an implementation, not a testable performance criterion. Other approaches should be permitted. | Proposed change: Keep the suggestions, but put them in informative Notes or Guidance. | ||
GB | 3.17.7.229 [NORMSINV] | ed | This text says, “NORMSINV uses an iterative search technique”. This is specifying an implementation, not a testable performance criterion. Other approaches should be permitted. | Proposed change: Keep the suggestions, but put them in informative Notes or Guidance. | ||
GB | 3.17.7.243 [OR] | te | It is not specified whether this function short-circuits or not. In other words, must the remaining arguments be evaluated once one of them is found to be TRUE? Since some functions have side effects, it is necessary to define this in order to ensure interoperability. | Proposed change: Specify whether this function allows short- circuit evaluation | ||
GB | 3.17.7.244 [PEARSON] | te | The definition of the arguments in the function is incorrect. It should say that x-bar and y-bar are the sample means, not x and y. | Proposed change: Correct the text | ||
GB | 3.17.7.249 [p2745, PI ] | te | The provided example contradicts the description, since it displays 10 significant digits in its fractional part instead of the (minimum) 15 significant digits which is stated as a requirement. | Proposed change: Fix the example or the text, so this contradiction is resolved. | ||
GB | 3.17.7.280 [RSQ] | te | The definition of the arguments in the function is incorrect. It should say that x-bar and y-bar are the sample means, not x and y. | Proposed change: Correct the text | ||
GB | 3.17.7.282 [SEARCH/SEARCHB] | te | Is this a lexical comparison or collation-based search? | Proposed change: Clarify the basis for string comparisons | ||
GB | 3.17.7.287 [SINE] | te | It is not indicated whether the parameter is in radians or degrees | Proposed change: Specify the angular units that this parameter is in. | ||
GB | 3.17.7.291 [SLOPE] | te | The definition of the arguments in the function is incorrect. It should say that x-bar and y-bar are the sample means, not x and y. | Proposed change: Correct the text | ||
GB | 3.17.7.296 [STDEV] | te | The definition of the argument in the function is incorrect. It should say that x-bar is the sample means, not x. | Proposed change: Correct the text | ||
GB | 3.17.7.297 [STDEVA] | te | The definition of the argument in the function is incorrect. It should say that x-bar is the sample means, not x. | Proposed change: Correct the text | ||
GB | 3.17.7.298 [STDEVP] | te | The definition of the argument in the function is incorrect. It should say that x-bar is the sample means, not x. | Correct the text | ||
GB | 3.17.7.299 [STDEVPA] | te | The definition of the argument in the function is incorrect. It should say that x-bar is the sample means, not x. | Proposed change: Correct the text | ||
GB | 3.17.7.300 [STEYX] | te | The definition of the arguments in the function is incorrect. It should say that x-bar and y-bar are the sample means, not x and y. | Proposed change: Correct the text | ||
GB | 3.17.7.313 [TAN] | te | It is not indicated whether the parameter is in radians or degrees | Proposed change: Specify the angular units that this parameter is in. | ||
GB | 3.17.7.335 [VAR] | te | The definition of the argument in the function is incorrect. It should say that x-bar is the sample means, not x. | Proposed change: Correct the text | ||
GB | 3.17.7.336 [VARA] | te | The definition of the argument in the function is incorrect. It should say that x-bar is the sample means, not x. | Proposed change: Correct the text | ||
GB | 3.17.7.337 [VARP] | te | The definition of the argument in the function is incorrect. It should say that x-bar is the sample means, not x. | Proposed change: Correct the text | ||
GB | 3.17.7.338 [VARPA] | te | The definition of the argument in the function is incorrect. It should say that x-bar is the sample means, not x. | Proposed change: Correct the text | ||
GB | 3.17.7.344 [WORKDAY] | te | 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. | Proposed change: Define this function unambiguously and preferably in a way which provides for cultural adaptability in the definition of a weekend. | ||
GB | 3.17.7.348 [YEARFRAC] | te | This function is ambiguous. Specifically it does not treat the calculation in the presence of leap years. In the Actual/Actual basis, do we ever divide by 366? Or only by 365? Would we divide by 366 only if the leap day is between start-date and end-date? Of either start-date or end- date are in the leap year? If both start-date and end-date are in a leap year? | Proposed change: Clarify the definition of the function when involving leap years. | ||
GB | 3.18.95 [p2939] | te | All of the URLs provided here are incorrect. They lack the colon following “http”. | Proposed change: Correct the URLs | ||
4. PresentationML Reference Material | ||||||
GB | 4.2.9 | te | tags (Customer Data Tags) Typo in line 23, “PresenationML” | Correct | ||
GB | 4.2 [29-30] | te | This section defines complex types that allow the capture of attribute values as well as elements. In practice it defines no "elements" as such, only referencing elements defined elsewhere. | Revise the text to address this comment | ||
GB | 4.3.1.4 | te | Is the defined maximum limit of 10 for the clrMru element too small for some applications? Why is this the only element constrained with a maxOccurs other than 1 or unbounded? | Revise the text to address this comment | ||
GB | 4.3.1.10 [6] | te | The definition of the charset attribute contains the sentence "Specifies the most similar character set to the one being used." Subjective phrases such as "most similar" are extremely woolly and should be avoided in standards. The same phrase is used in the definition of the pitchFamily attribute. | Revise the text to address this comment | ||
GB | 4.3.1.35 | te | smartTags element specifies existence of Smart Tags, but no reference to what these constructs are, or where to find a definition of them elsewhere in the standard. | Revise the text to address this comment | ||
GB | 4.6
Animation |
ed | Typo in line 6 “The schema
describes all the animations effects on that reside on a slide”
Typo in line 10? “All elements described in this schema are contained within the slide XML file. More superficially they are in the...” The word “specifically” would make more sense. Both of these typos are also found in sub-clause 4.4.1 of the section on PresentationML contained in Part 3 – Primer, (p. 250 lines 1 and 5.) |
Correct | ||
GB | 4.8.6 [14] | te | The restricted list of values provided in the list of supportable browsers, which only includes IE3, IE4 and Netscape3 and Netscape4, is totally unacceptable for an international standard. The list must be extensible to allow for updates as new browsers appear. It must also include all existing browsers. The phrase "The following are possible enumeration values for this type:" suggests that these are only some possible values, but the following sentence states categorically that "The following XML Schema fragment defines the contents of this simple type:". Clarify whether or not this list is extensible and if it is make the example list clearly an example and more up-to-date and inclusive than its current listings. Note that for interoperability reasons, allowing each user community to define its own names may lead to problems: a registry of commonly accepted browser identifiers should be set up to aid interoerability and be referenced in this section. | Revise the text to address this comment | ||
GB | Page 5.4.2 [23] | te | Ambiguous comments that looks like something is missing. | Proposed change: Add missing part of XML example or remove the ambiguous comment. | ||
GB | Page 22 [3] | ed | References to www.contoso.com should be replaced with references to generic www.example.com. | Proposed change: Do not refer to a Microsoft internal beta site for an unannounced product. | ||
GB | 7 - Citations [13] | ed | URL refers to RFC documents at a different location to the rest of the standard. RFC docs are issued by IETF and not W3C. | Proposed change: Replace (http://www.w3.org/Protocols/rfc2616/rfc2616.html) with (http://www.ietf.org/rfc/rfc2616.txt) | ||
GB | Page 8.2.2 [13] | ed | In a description of name spaces a reference is made to http://www.woodgroveBank.com. This URL yields a security warning and it is bad form to refer to a company web site (especially in my view, one that belongs to a bank) in this way. | Proposed change: Replace with a dummy URL. Contoso is again used here as well. | ||
GB | 13.3.1 [5] | te | Namespace for author initials does not allow for more than one person to share the same initials without combining with the ID value as a unique key. Mary Anne Smith and Maurice Albert Stone both have the initials MAS. The ID and colour would distinguish them but when querying the XML, comments from both would be aggregated. | Proposed change: Ensure that duplicates are extended by a numeric suffix so that the namespace remains unpolluted. | ||
GB | 15.2.2 [Table 1] | ed | The URL describing the audio/x-me-wax does not exist. | Proposed change: Replace http://msdn.microsoft.com/library/en-us/wmplay10/mmp_sdk/asx_elementsintro.asp with a static URL that is guaranteed to always exist. | ||
GB | 15.2.14 [4] | ed | Misleading URL (http://developer.apple.com/documentation/Carbon/Reference/CarbonPrintingManager_Ref/Reference/refer4 ence.html). Does not exist and describes deprecated functionality in Mac OS. | Proposed change: Remove all references to Carbon implementation when describing Mac OS functionality and replace them with the corresponding descriptions of contemporary Mac OS X Cocoa implementations. Carbon is a compatibility shim, which allows developers to continue using legacy Mac OS Classic (System 9 and earlier) applications source code. It should not be referred to in a forward looking standard or specification. This is a better URL (http://developer.apple.com/documentation/Printing/index.html) because it refers to the Carbon, Cocoa and CUPS printing documentation. Go up a level to (http://developer.apple.com/documentation/) for the index to all developer documentation topics when correcting other references. | ||
GB | 15.2.16 [Table 1] | ed | Most entries describe references to technical specifications. The QuickTime entry describes a reference to a trademark licencing page. | Proposed change: Replace (http://developer.apple.com/softwarelicensing/agreements/quicktime.html) with (http://developer.apple.com/documentation/QuickTime/index.html) which is a more useful reference when referring to technical material on QuickTime. | ||
GB | Annexes | ge | Overall - must check that these bibliographic references are to permanent pages with a guaranteed lifetime; can the proposer assure us that this has been arranged? | Revise the text to address this comment | ||
GB | Annexe A: Bibliography [8] | ed | Ambiguous URL. | Proposed change: Replace (http://www.rfc-editor.org) with (http://www.ietf.org/rfc/rfc2045.txt) | ||
GB | Annexe A: Bibliography [10] | ed | Ambiguous URL. | Proposed change: Replace (http://www.rfc-editor.org) with (http://www.ietf.org/rfc/rfc2616.txt) | ||
GB | Annexe A: Bibliography [12] | ed | Ambiguous URL. | Proposed change: Replace (http://www.rfc-editor.org) with (http://www.ietf.org/rfc/rfc3066.txt) | ||
GB | Annexe A: Bibliography [14] | ed | Ambiguous URL. | Proposed change: Replace (http://www.rfc-editor.org) with (http://www.ietf.org/rfc/rfc3339.txt) | ||
GB | Annexe A: Bibliography [16] | ed | Ambiguous URL. | Proposed change: Replace (http://www.rfc-editor.org) with (http://www.ietf.org/rfc/rfc3629.txt) | ||
GB | Annexe A: Bibliography [18] | ed | Ambiguous URL. | Proposed change: Replace (http://www.rfc-editor.org) with (http://www.ietf.org/rfc/rfc3986.txt) | ||
GB | Annexe A: Bibliography [19] | ed | The Unicode standard is now at revision 5 as of July 2006. | Proposed change: Unless this standard is specifically only designed to operate with Unicode 4, you should check any references to Unicode technology and ensure they are compliant with Unicode version 5. | ||
GB | Annexe A: Bibliography [23] | ed | URL does not exist (http://www.w3.org/TR/2004/REC-xml-20040204/xml11-20040204/). | Proposed change: Replace with a persistent URL. The reference is to an out of date third edition. The fourth edition is at this URL (http://www.w3.org/TR/2006/REC-xml-20060816/). | ||
GB | Annexe A: Bibliography [3 (p.162)] | ed | The reference to the application note has a URL that is somewhat generalised and requires further searching. It also lacks a trailing slash character. (http://www.pkware.com) | Proposed change: More specific URL for this is (http://www.pkware.com/documents/casestudies/APPNOTE.TXT). | ||
GB | Annexe B: Bibliography [12] | ed | Ambiguous URL. | Proposed change: Replace (http://www.rfc-editor.org) with (http://www.ietf.org/rfc/rfc3986.txt). | ||
GB | Annexe B: Bibliography [13] | ed | Missing URL. | Proposed change: Add (http://www.ietf.org/rfc/rfc4234.txt). | ||
GB | Annexe B: Bibliography [lines 9,10,14,15 and 16] | ed | Inconsistent with other documents. Missing URL and reference needs to be checked for whether it is the latest revision. | Proposed change: Add reference to correct W3C document. | ||
GB | Annexe I: Bibliography [7] | ed | Inconsistent reference to Unicode 3. Other bibliographies refer to Unicode 4 but Unicode 5 is current. | Proposed change: Bring up to date. | ||
GB | Annexe I: Bibliography [general] | ge | Many references are made to RFC and W3C documents with ambiguous or missing URLs. Sometimes the documents are not the latest version. | Proposed change: All bibliographic references should be rechecked to ensure they are up to date, relevant to the standard and have URLs that will persist permanently (permalinks). | ||
GB | Page 1246 [15] | ed | Another reference to the contoso internal microsoft beta test software (also at 7.5.2.1 and 8.2.1). | Proposed change: Remove all references to contoso throughout the standard. | ||
GB | Page 1302 [8] | ed | Typographic styling of this reference is different to other URL references. | Proposed change: Decide on a typographic style model and stick to it. Check throughout the entire standard to ensure styling is consistent | ||
GB | Page 1536 [3] | ed | DO NOT refer to real target web sites in URLs unless they are meaningfully related to the standard. This is most definitely not related to the standard. | Proposed change: Here is yet another inconsistent example URL quoted. Replace with http://www.example.com/ | ||
GB | Page 1601 [Middle column in table] | ed | http://example.com/ inconsistent usage. | Proposed change: Replace with http://www.example.com/ | ||
GB | Pages 1905, 1916, 1917 [Codepage] | ed | This refers to a very Windows Specific Unicode page without making it clear that if you walk further up the tree there are code page mapping for other platforms and environments. | Proposed change: Add a reference to and description of (http://www.unicode.org/Public/MAPPINGS/). | ||
GB | [Page 5142 [9] | ed | Bullets in table that list some URLs are not consistently styled. They also contain a reference to Contoso again. | Proposed change: Correct the URLs and the presentation styling. | ||
5. DrawingML Reference Material | ||||||
GB | Throughout [xsd:boolean] | te | There are hundreds of instances
where invalid xsd:boolean attribute values are used. For example, take
part 4, 5.1.6.13 "tblPr". In the definition of the attributes bandCol,
it says:
"A value of on, 1 or true will enable the banded column formatting defined in the table style. ... The possible values for this attribute are defined by the XML Schema boolean datatype." However, XML Schema 3.2.2.1 (http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#boolean) defines allowed lexical value space for xsd:boolean as: "An instance of a datatype that is defined as boolean can have the following legal literals {true, false, 1, 0} " "On" and "Off" are not allowed values. |
Proposed change: Either change the text to remove the "on" and "off" options or change the schema reference to the ST_OnOff type defined in 2.18.67, which does allow this set of values. | ||
6. VML Reference Material | ||||||
GB | General | te | 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. | Proposed change: Remove VML from OOXML. Vendors who have access to the legacy binary format documentation, such as Microsoft, are free to convert the VML to the “newer and richer” DrawingML at the same time they convert the document to OOXML. (See also 5.3 DrawingML - Legacy Compatibility) | ||
GB | All subsections | ge | All subsections of Section 6 describe deprecated only material, making Section 6 deprecated as a whole. A new standard should not contain deprecated parts. | Proposed change: Remove Section 6. | ||
GB | 6.1 [p4343, 4 and 5] | te | What does 'This namespace' refer to? There is no obvious namespace in the context of that sentence. | Proposed change: Clarify the namespace reference. | ||
GB | 6.1 [p4343, 5] | te | The relationship of 'Other VML namespaces' to the OOXML proposal is unclear. | Proposed change: If the said other namespaces are related to OOXML, clarify the relationship, else remove the reference to them from the text. | ||
GB | 6.1 [p4343, 8] | te | The reference to 'millions of documents' is an unsupported assertion. Furthermore, it is irrelevant in the context of a standard proposal. | Proposed change: Remove the marketing fluff from the text. | ||
GB | 6.1 [p4343, 9] | ed | The reference to the specific commercial product 'Office 2000' brings no value to the proposal. | Proposed change: Remove the reference to Office 2000. | ||
GB | 6.1.2.7 [p4444, tableproperties] | te | This element uses bitmasks to specify various table cell formatting properties. The use of bitmasks rather than a set of boolean types makes this data sub-optimal to work with standard XML tools like XSLT which lack bit-level operations.. | Proposed change: Rewrite this subclause to express the feature using XML constructs rather than bitmasks. | ||
GB | 6.1.2.19 [p4653, equationxml] | te | This describes the "equationxml" attribute of "shape" elements, "used to rehydrate an equation using the Office Open XML Math syntax". However, the "actual format of the contents of this attribute are application-defined", which makes them impossible to exchange between applications. If we're going to have a new math markup language in XML, and ignore the existing MathML, let's at least use the new markup in its elemental form, as well-formed XML (not stuffed into an attribute value), and without extending it in application-dependent ways. | Proposed change: Define equations in an interoperable way. | ||
GB | 6.1.2.19 [p4655, gfxdata] | te | Describes a "gfxdata" attribute for the "shape" elements, which "contains DrawingML content" that is "base-64 encoded". However, the "contents of this package are application-defined", so even though they "shall use the Parts defined by this Standard whenever possible" there is not sufficient information for an independent implementation to read this data or display the "DrawingML content" contained therein. If we're going to have a new graphics markup language in XML, and ignore the existing SVG, let's at least use the new markup in its elemental form, as well-formed XML (not stuffed into an attribute value), and without extending it in application-dependent ways. | Proposed change: Define this in an interoperable way. | ||
GB | 6.2.2.14 [p4813] | te | This describes an "ink" element which stores "ink annotations in an application-defined format." This is apparently intended to store annotations, used with tablet input devices to add hand-written annotations to documents. These annotations are often a vital part of documents and their specification is undefined in OOXML. We are opposed to standardizing placeholder elements for entirely application-dependent proprietary formats without also specifying an interoperable format for those who with to create interoperable formats. | Proposed change: Specify the “ink” format or remove the element from OOXML and make this an application extension using the extensibility mechanisms of OOXML. | ||
GB | 6.4.2.4 [p4925, AutoFill ] | te | The text says, “This element specifies that the object is an AutoFill object. If this element is specified without a value, it is assumed to be true. This is a general-use element.” However, nowhere in the spec is an “AutoFill object” defined. | Proposed change: Define the behaviour of an “AutoFill object” | ||
GB | 6.4.2.5 [p4925, AutoLine ] | te | The text says, “This element specifies that the object is an AutoLine object. If this element is specified without a value, it is assumed to be true. This is a general-use element.” However, nowhere in the spec is an “AutoLine object” defined. | Proposed change: Define the behaviour of an “AutoLine” object” | ||
GB | 6.4.2.6 [p4926] | tet | The text says, “This element
specifies whether the object's size is formatted automatically by the
application. If this element is specified without a value, it is assumed
to be true. This is a general-use element for objects that use an image
representation, such as OLE objects, Embedded controls, cameras, and
signature lines.”
The objects listed after the words "such as ..." must be interpreted as an exhaustive or partial list ? What ST_ObjectType's object types (6.4.3.2) correspond to "OLE objects", "Embedded controls" or "signature lines"? |
Proposed change: Define the applicable objects for this element according to the ST_ObjectType type. | ||
GB | 6.4.2.7 [p4926, AutoScale] | te | The text reads, “This element specifies whether the object's font is automatically scaled by the application when the object is resized. If this element is specified without a value, it is assumed to be true. This element is used for attached text.” “attached text” is not one of the allowed values of the ST_ObjectType type. | Proposed change: Define the applicable objects for this element according to the ST_ObjectType type. | ||
GB | 6.4.2.8 [p4926, Camera] | te | The text reads, “"This element specifies that the object is a camera object. A camera object shows a live view of another part of the spreadsheet. If this element is specified without a value, it is assumed to be true. This element is used for cameras." However, a “camera” is not defined in this context, nor its behavior. | Proposed change: Define the behaviour of this “camera object”. | ||
GB | 6.4.2.10 [p4927] | te | The CF 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. | Proposed change: Provide a proper external normative reference for the allowed formats containable within this element. | ||
GB | 6.4.27 [p4938, FmlaMacro ] | te | The text reads, “This element specifies the custom function associated with the object” But no objects are listed for this element. | Proposed change: List what ST_ObjectType objects this element can be applied to. | ||
GB | 6.4.3.1 [p4955] | te | The allowed values of this enumeration, EMF, WMF, etc., are Windows-specific formats. No allowance seems to have been made for use by other operating systems. For example, in Linux images are typically copied on the clipboard in an open standard format like PNG. | Proposed change: The desire is to allow cross platform interoperability, which must be allowed. Revise as necessary. | ||
7. Shared MLs Reference Material | ||||||
GB | 7.1 [all] | te | This is the specification of Office Open Math Markup Language, a specialized XML vocabulary for the describing the layout of mathematical equations. This solves the same problem as MathML, a long-established W3C standard and an ongoing activity in the W3C. Since the equation editing feature of Word was entirely rewritten in Word 2007, there doesn't not seem to be the argument that an additional equation language must be introduced for the sake of legacy documents. | Proposed change: It is recommended that this section be removed from OOXML and that the proposers works 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. | ||
GB | 7.1 | ge | oMath stands out as being
treated differently in the standard compared to the other topics. It is
much lighter–there is less narrative, fewer examples. Some of the
comments on the Primer also
apply in this Part. In the following, usually one example is given to
illustrate each point, but there are others.
Some of the issues stem from the fact that the xml alone is not sufficient to display a mathematical expression. Use is made of implicit semantic knowledge of the characters that form an expression, i.e. which are operators, which are special characters that need to be handled in specific ways and how they behave.
|
Revise the text to address these comments | ||
GB | 7.1 [5] | te | - | Change end of paragraph starting
"... or functions (such as" to:
"... or functions such as accents (acc) or fractions (f)." |
||
GB | 7.1.2.1 | te | - | <m:accPr> can be omitted from the <m:acc> element. The text needs to specify what the default character will be when it is omitted. | ||
GB | 7.1.2.1 [38] | ed | - | Delete the heading "Parent Elements" at the bottom of the page. | ||
GB | 7.1.2.2 | ed | The text needs to specify the defaults when <chr> and / or <ctrlPr> are omitted | Revise the text to address this comment | ||
GB | 7.1.2.2 [10] | ed | - | Add the following after "[Example:": "The diacritical mark * (tilde) is:" | ||
GB | 7.1.2.3 [3] | ed | - | Replace 'true' with '"on"': "... When "on", this operator emulator ..." | ||
GB | 7.1.2.3 [5] | ed | - | Replace "point." with "point:" | ||
GB | 7.1.2.5 [24] | ed | - | Delete heading "Parent Elements" from bottom of the page. | ||
GB | 7.1.2.6 [23] | ed | - | Wrong end tag, it should be: </m:r> | ||
GB | 7.1.2.6 [27] | ed | - | Delete heading for attributes table at bottom of the page. | ||
GB | 7.1.2.7 [6 on p4970] | ed | - | Add a space between "a" with the bar above it and "and" at the end of the line. | ||
GB | 7.1.2.9 [26-27 on p4972] | ed | - | The schema only allows <m:count> before <m:mcJc>: transpose lines 26 and 27. | ||
GB | 7.1.2.9 [after 39 on p4973] | ed | - | Missing end tag for second row
and missing start tag for third row of the matrix. Insert after line 39
(with correct indent):
</m:mr> <m:mr> |
||
GB | 7.1.2.11 [13] | ed | - | Need to specify the defaults when <borderBoxPr> is omitted. | ||
GB | 7.1.2.12 [20] | ed | - | Insert "end example]" at the end of the line. | ||
GB | 7.1.2.13 | te | - | Need to specify what the defaults are when <boxPr> is omitted. | ||
GB | 7.1.2.13 [19-20] | ed | - | Move "[Example:" from line 20 to the start of line 19 where the example starts. | ||
GB | 7.1.2.15 [attribute table] | te | Need to specify what happens when alnAt attribute is omitted. | Revise the text to address this comment | ||
GB | 7.1.2.16 [9] | te | - | The possible values for brkBin are before, after and repeat (not duplicate): replace "Duplicate" with "Repeat". | ||
GB | 7.1.2.18 | te | Need to specify what happens when cGpRule is omitted. | Revise the text to address this comment | ||
GB | 7.1.2.18 [9-12] | te | It isn't possible to set an
additional spacing between columns of ".5 ems" unless 1 em is the normal
spacing between columns, but normal spacing isn't specified. Even then,
a 1.5 spacing gap would be set by cGpRule on its own and not cGp.
Also, the xml for this example sets a spacing of 6 lines between columns, so the example xml does not match the example matrix. |
Revise the text to address this comment | ||
GB | 7.1.2.18 [16-17] | te | - | The schema only allows <m:count> before <m:mcJc>: transpose lines 16 and 17. | ||
GB | 7.1.2.18 [attributes table] | ge | It seems strange to define column spacing in terms of number of lines. Something like ems might be more appropriate. | Revise the text to address this comment | ||
GB | 7.1.2.18 [attributes table line 1] | ed | - | Insert "columns of " into the first sentence so it becomes: "Specifies the amount of space between columns of the parent element." | ||
GB | 7.1.2.19 [6] | ed | - | Line 6 is garbled: delete
"horizontal spacing between columns in a matrix. Type of" so that it
reads
"This element specifies the type of gap (horizontal spacing) ..." |
||
GB | 7.1.2.19 [15-16] | te | - | The schema only allows <m:count> before <m:mcJc>: transpose lines 15 and 16. | ||
GB | 7.1.2.20 [5] | ed | chr is used to specify any characters and not just accents. | Proposed change: call it
"chr (Character)" not "chr (Accent Character)".
This will have a knock-effect wherever it is referenced. |
||
GB | 7.1.2.20 [7] | te | The default for chr depends on the parent element. The defaults need to be specified for each of the parents: accPr, groupChrPr and naryPr. | Revise the text to address this comment | ||
GB | 7.1.2.20 [2 (attributes table)] | ed | The description relates to <m:dPr> and not to <m:chr>. | Proposed change: Change
the example to:
[Example: <m:accPr> <m:chr m:val="̃"/> </m:accPr> end example] |
||
GB | 7.1.2.21 [9] | ed | - | Change the first word of the line from "represents" to "specifies". | ||
GB | 7.1.2.21 [15-16] | te | - | The schema only allows <m:count> before <m:mcJc>: transpose lines 15 and 16. | ||
GB | 7.1.2.21 [22] | te | - | Delete the attribute table heading that is on its own at the bottom of the page. | ||
GB | 7.1.2.21 [attribute table, line 1] | ed | - | Change "... to which a column attribute applies." to ".... to which a column property applies." | ||
GB | 7.1.2.21 [attribute table, line 2] | ed | - | "Example" should be italic. | ||
GB | 7.1.2.21 [attribute table, line 2] | ed | - | Replace "first" at the end of the line by "next" since the count applies to the next three columns and not always the first three. | ||
GB | 7.1.2.21 [attribute table, line 3] | ed | - | "end example" should be italic. | ||
GB | 7.1.2.22 | te | The description of cSp refers to the "setting of the rule of the parent element", but what rule this might be isn't specified. Should there be a cSpRule? The rule should be included in the example. Compare cGpRule where if it is omitted, the spacing is single spacing so the value of cGp would be ignored. . | The text need to say how cSp interacts with cGp if both are specified | ||
GB | 7.1.2.22 [8-9] | ed | - | Change the first sentence of the example to: "[Example: The following xml specifies that there should never be fewer than 6 pts between adjacent column edges of the matrix:" | ||
GB | 7.1.2.22 [attribute table] | te | The description given in the table doesn't match the example: the example doesn't have a rule for the parent element and a value of 120 suggests the units are twips and not points or lines. | Revise the text to address this comment | ||
GB | 7.1.2.23 [20-22] | te | "Linear representation", "linear
string" and "professional form" need to be defined.
The string *_0^1 is used as an example. (i) This needs to be explained. (ii) The syntax for it needs to be specified. (iii) Where can it be used? (iv) Does that mean "_" and "^" are special characters in text so can't be used as themselves? If so, how can we use them without their special meaning? (v) What other special characters are there? |
Revise the text to address this comment | ||
GB | 7.1.2.31 | te | The use of "e" for the name of this element can cause confusion, as e also stands for the constant 2.718282... This makes it difficult to read descriptions like line 22, for example. A better name might be "b" or "base". | Revise the text to address this comment | ||
GB | 7.1.2.31 [21] | te | This element is used in about 18 different ways, one of which is the base argument of a mathematical function. The description needs to describe its general use. | Revise the text to address this comment | ||
GB | 7.1.2.32 [22] | te | - | Move the limit "n**" in the first occurrence below "lim". | ||
GB | 7.1.2.32 [36 on p5000] | ed | - | Delete heading "Child Elements" that's on its own at the bottom of the page. | ||
GB | 7.1.2.32 [2-8 on p5002] | te | All the subelements of e can be omitted. Need to specify what the defaults are, especially when they are all omitted. | Revise the text to address this comment | ||
GB | 7.1.2.33 [18] | ed | - | Delete attributes table heading that is on its own at the bottom of the page. | ||
GB | 7.1.2.33 [attributes table] | ed | - | Add "end example]" after last line of xml: "</m:dPr>" | ||
GB | 7.1.2.34 [7] | ed | - | Insert "with" so the line starts: "vertically justified as a unit with respect to..." | ||
GB | 7.1.2.34 [10] | ed | - | Delete "tens". The digits line up. | ||
GB | 7.1.2.34 [11] | ed | A better example would be one where the operators lined up (as in line 9) and we could see how it all fitted together. | Revise the text to address this comment | ||
GB | 7.1.2.34 [24] | ed | - | Delete "Parents Elements" heading that's on a line on its own at the bottom of the page. | ||
GB | 7.1.2.34 [3-8 on p5004] | ed | Need to specify the default when eqArrPr is omitted. | Revise the text to address this comment | ||
GB | 7.1.2.36 [17] | te | - | Replace "Stacked" with "Bar" (the example has a bar). | ||
GB | 7.1.2.36 [20] | te | - | Make this consistent with usage elsewhere by changing the start of the line to: "No-Bar Fraction (Stack):" | ||
GB | 7.1.2.37 [13] | te | - | Move the limit "n**" in the first occurrence below "lim". | ||
GB | 7.1.2.38 [14] | te | - | Replace "Stacked" with "Bar" (the example has a bar). | ||
GB | 7.1.2.38 [17] | te | - | Make this consistent with usage elsewhere by changing the start of the line to: "No-Bar Fraction (Stack):" | ||
GB | 7.1.2.39 [4] | te | - | Move the limit "n**" in the first occurrence below "lim". | ||
GB | 7.1.2.41 [8] | te | - | The example at the bottom of the preceding page (p5011) shows a midline horizontal ellipsis (U+22EF), not a horizontal ellipsis or 3 dots. Change line 8 to: "<m:t>x+x+⋯</m:t>" | ||
GB | 7.1.2.42 [24] | te | Need to show what character U+23DF is (bottom curly bracket). | Revise the text to address this comment | ||
GB | 7.1.2.43 [11] | te | - | Delete "at the document level". grow is a property of its parent and is not used in setting the document properties. | ||
GB | 7.1.2.51 [20] | te | - | Change "right" to "centerGroup" to match example: <m:jc m:val="centerGroup"/> | ||
GB | 7.1.2.52 [6] | te | - | Change the name to "Limit" instead of "Limit (Lower)". This element is used for both lower and upper limits. | ||
GB | 7.1.2.52 [9] | te | - | Add a comment about upper limit to the end of the sentence so it ends: "... limLow function and the upper limit of the limUpp function." | ||
GB | 7.1.2.52 [26] | te | - | Delete "Child Elements" table heading that is on its own at the bottom of the page. | ||
GB | 7.1.2.53 [14-18] | te | Need to show or explain which option the XML example is. | Revise the text to address this comment | ||
GB | 7.1.2.58 [9-10] | te | The special characters referred to need to be identified, together with their expected behaviours. | Revise the text to address this comment | ||
GB | 7.1.2.58 [12-21] | te | Need to show what the example generated by the xml looks like and compare it to how it would look without using lit. | Revise the text to address this comment | ||
GB | 7.1.2.59 [3] | ed | - | Replace "lmargin" by "lMargin". | ||
GB | 7.1.2.60 [25] | te |
|
Revise the text to address this comment | ||
GB | 7.1.2.60 [26] | ed | - | Replace "an" by "and". | ||
GB | 7.1.2.60 [6-7 on p5028] | te | - | The schema only allows <m:count> before <m:mcJc>: transpose lines 6 and 7. | ||
GB | 7.1.2.60 [15-20 on p5029] | te | Need to specify the default if mPr is omitted. | Revise the text to address this comment | ||
GB | 7.1.2.62 [2-23 on p5031] | te |
|
Revise the text to address this comment | ||
GB | 7.1.2.63 | ed | Need to give diagrams to show how maxDist works, as in the Primer. Need to explain how it interacts with objDist. | Revise the text to address this comment | ||
GB | 7.1.2.64 [12-13] | te | - | The schema only allows <m:count> before <m:mcJc>: transpose lines 12 and 13. | ||
GB | 7.1.2.65 [17-18] | te | - | The schema only allows <m:count> before <m:mcJc>: transpose lines 17 and 18. | ||
GB | 7.1.2.67 [6-7] | te | - | The schema only allows <m:count> before <m:mcJc>: transpose lines 6 and 7. | ||
GB | 7.1.2.69 [23-24] | te | - | The schema only allows <m:count> before <m:mcJc>: transpose lines 23 and 24. | ||
GB | 7.1.2.71 [3] | te | - | Replace "integral object" with "summation object". | ||
GB | 7.1.2.71 [attributes table] | te | - | Replace "limits on an integral." with "limits on an n-ary object that is not an integral." | ||
GB | 7.1.2.72 [26] | te | Need to specify what the "type of n-ary operator" means. | Revise the text to address this comment | ||
GB | 7.1.2.72 [3-12 on p5044] | te | Need to specify the defaults, e.g. what is the chr if chr is omitted? | Revise the text to address this comment | ||
GB | 7.1.2.78 [13] | te | - | Delete 'maxOccurs="1"' as this is the default and is not given in the schema. | ||
GB | 7.1.2.78 [14] | te | - | Delete 'minOccurs="1"' as this is the default and is not given in the schema. | ||
GB | 7.1.2.78 [15-22] | te | Need to explain what these lines are used for. m:annotation and m:context, m:content don't appear to be in the namespace. | Revise the text to address this comment | ||
GB | 2.1.2.79 [7] | te | - | Delete 'maxOccurs="1"' as this is the default and is not given in the schema. | ||
GB | 7.1.2.80 [12] | te | Need to specify what the properties of an operator are. Two properties are given in the text as examples. What are the others? | Revise the text to address this comment | ||
GB | 7.1.2.81 | te | The use of phantoms needs to be
explained better. The examples in the Primer need to be shown together
with the xml that was used to produce them. Otherwise it's almost
impossible to work out how they work if you don't know. The explanation
needs to be in the normative part.
Need to explain some of the terms used: glyph, ascent, descent. |
Revise the text to address this comment | ||
GB | 7.1.2.83 [20] | te | The two matrices shown look identical. One should show placeholders and the other one shouldn't. Neither do. | Revise the text to address this comment | ||
GB | 7.1.2.84 | te | - | Change the name to "Position" as bar is used for groupChrPr as well as bar. The descriptive text needs changing to reflect its use. | ||
GB | 7.1.2.92 | te | The example in line 22 with a spacing of 1.6 does not match the xml which gives a spacing of 3 lines. How do you get 1.6 and what are the units? | Revise the text to address this comment | ||
GB | 7.1.2.94 [10] | ed | - | Replace left curly quotes with straight quotes: <m:scr m:val="double-struck"/> | ||
GB | 7.1.2.97 | te | The name "shape" is not a good choice. This element only affects the height and location of the delimiter, not its shape. Maybe "height" would be better. | Revise the text to address this comment | ||
GB | 7.1.2.105 [9] | te | - | The description refers to sSub instead of sSup. Change the start of the line to: "This element specifies the superscript function sSup,..." | ||
GB | 7.4.2.4 [p5122, bstr] | te | 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.” | Proposed change: Remove the bstr type from OOXML | ||
GB | 7.4.2.4 [p5122, bstr escape mechanism] | 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? | Proposed change: Complete the definition of the escape mechanism. | ||
GB | 7.4.2.5 [p5122] | 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. | Proposed change: The proposer should rethink the entire Clipboard Data representation. It looks very much like it is mapping directly to the arbitrary internals of a single application. This clause must be rewritten to express this feature in an application and platform neutral way. | ||
GB | 7.4.2.5 [p5122, GUID and FMTID] | 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. | 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. | ||
GB | 7.4.2.5 [p5122, platforms] | te | This element defines values for use on Windows and Macintosh platforms, but not for Linux or any other operating system. | Proposed change: Several options here, but the desire is to allow cross platform interoperability. Revise accordingly. | ||
GB | 7.4.2.5 [p5122, platform interoperability] | 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”? | Proposed change: Specify adequate information so interoperability may be achieved. | ||
8. Logon required to edit | ||||||
Part 4 Annexes | ||||||
GB | ANNEX A [p5203, OfficeOpenXML-XMLSchema.zip ] | ge | There is no explicit indication given as to whether this annex is informative or normative. See ISO Directives, Part 2, section 5.2.6. | Proposed change: Clarify the status of this annex. | ||
GB | ANNEX A [p5203, OfficeOpenXML-XMLSchema.zip ] | ed | This annex was not provided in a humanly-readable format as required by JTC1 Directives 8.3.5 and Annex H. | Proposed change: The annex should be provided in a humanly-readable, lined-numbered format so it can be referenced and cited. Additionally, an electronic machine-readable version can be provided according to Annex H. | ||
GB | ANNEX B [p5204, OfficeOpenXML-RELAXNG.zip ] | ge | There is no explicit indication given as to whether this annex is informative or normative. See ISO Directives, Part 2, section 5.2.6. | Proposed change: Clarify the status of this annex. | ||
GB | ANNEX B [p5204, OfficeOpenXML-RELAXNG.zip ] | ge | This annex was not provided in a humanly-readable format as required by JTC1 Directives 8.3.5 and Annex H. | Proposed change: The annex should be provided in a humanly-readable, lined-numbered format so it can be referenced and cited. Additionally, an electronic machine-readable version can be provided according to Annex H. | ||
GB | ANNEX D [p5206, OfficeOpenXML-SpreadsheetMLStyles.zip] | ge | There is no explicit indication given as to whether this annex is informative or normative. See ISO Directives, Part 2, section 5.2.6. | Proposed change: Clarify the status of this annex. | ||
GB | ANNEX D [p5206, OfficeOpenXML-SpreadsheetMLStyles.zip] | ge | This annex was not provided in a humanly-readable format as required by JTC1 Directives 8.3.5 and Annex H. | Proposed change: The annex should be provided in a humanly-readable, lined-numbered format so it can be referenced and cited. Additionally, an electronic machine-readable version can be provided according to Annex H. | ||
GB | ANNEX E [p5207, OfficeOpenXML-DrawingMLGeometries.zip] | ge | There is no explicit indication given as to whether this annex is informative or normative. See ISO Directives, Part 2, section 5.2.6. | Proposed change: Clarify the status of this annex. | ||
GB | ANNEX E [p5207, OfficeOpenXML-DrawingMLGeometries.zip] | ge | This annex was not provided in a humanly-readable format as required by JTC1 Directives 8.3.5 and Annex H. | Proposed change: The annex should be provided in a humanly-readable, lined-numbered format so it can be referenced and cited. Additionally, an electronic machine-readable version can be provided according to Annex H. | ||
Part 5 - Markup Compatibility and Extensibility | ||||||
GB | 4 [12] | te | Why "element type name"? The example suggests it should be a "datatype name". | Revise the text to address this comment | ||
GB | 6 [2] | ge | Why is this specification targetted at academics? It does not seem to contain any formal definitions of new processes. | Revise the text to address this comment | ||
GB | 8 [30] | ed | - | Remove linebreak in middle of "document". | ||
GB | 8.2 [25] | ed | The term specification (or standard) normally refers to the whole of a standard. When referring to a specific part of a standard it is more usual to refer to "this part of the specification". | Revise the text to address this comment | ||
GB | 9 [Table 9.2] | te | The phrases "element-qualified
name" and attribute-qualified name" are confusing. Most users would be
inclined to use "qualified element name" and "qualified attribute name".
If there is a deliberate reason for introducing a new variant name the
new names should be formally defined in Clause 3: Definitions.
The phrase "element qualified name" differs from the initial use of the phrase with a hyphen in it. Please adopt a consistent spelling for the phrase. NB These comments apply to subsequent clauses, where the phrases in this table form the first para of the clause. |
Revise the text to address this comment | ||
GB | 9.1.3 [2] | ed | - | Need a space between of and conditions. | ||
GB | 9.1.3 [6] | ed | - | Need a full stop between “behavior” and “Before”. | ||
GB | 9.1.4 [19] | ed | - | Need a space in "containsa" | ||
GB | 9.1.4 [8] | ed | - | The example should be number 9-5 not 10-5. | ||
GB | 9.2.1 [28-30] | te | It is not clear why this rule is needed. Surely once a Choice element has been matched there should be no need to read subsequent Choice or Fallback elements at all, but if this sentence is retained then they have to be read to check their attribute values, adding unnecessary processing to the consumer. | Revise the text to address this comment ' | ||
GB | 9.2.2 [16] | te | It's not clear what the relationship between Required and MustUnderstand attributes in a Choice element would be. Any miss-match between the values of the two is likely to trigger an error. Given the provision of a FallBack element, it is not clear there is any use case where there's a value in the use of MustUnderstand in a Choice. | Revise the text to address this comment | ||
GB | 9.2.3 [6] | ed | - | Remove space in "element s" | ||
GB | 10.2 [10 & 22] | te | It is not clear why v2: has been added to the element name in both these cases. | Revise the text to address this comment | ||
GB | 10.2 [22] | ed | There is no Example 13-1 in this part. Is this supposed to be a reference to Example 12-1? | Revise the text to address this comment | ||
GB | 11 [16] | te | Why is the quoted phrase island emboldened as if it were a definition rather than italicised as the first use of a term? | Revise the text to address this comment. | ||
GB | Annex B [7-8] | ed | Why are ISO/IEC directives referenced in this Bibliography (they are normally an implicit part of an ISO standard's references and not directly cited unless text from the directive is quoted.) | Revise the text to address this comment | ||
Schema Annexes | ||||||
GB | Incorrect use of xml:import | te | The OOXML XML Schemas use xml:import incorrectly. Stylesheets contain multiple import statements, each giving the same namespace, but different schemaLocation hints. It is ambiguous whether this is legal XML Schema, but it goes against the intention of the XML Schema specification (Noah Mendelsohn), is not supported by several major validation tools (e.g. XSV, Xerces 2.9, at least some versions of Tibco Turbo, and older versions of MSXML), and is not an approach recommended by XML Schema experts (Jeni Tennison, Michael Kay). | Remedy: Build an "adapter
schema" which is imported in place of the multiple existing imports,
which uses xs:include directives to include all the schemas that
reference the same namespace.
Affects files: dml-chart.xsd, dml-chartDrawing.xsd, dml-compatibility.xsd, dml-diagramColorTransform.xsd, dml-diagramDataModel.xsd, dml-diagramDefinition.xsd, dml-diagramElementPropertySet.xsd, dml-diagramElementPropertySet.xsd, dml-diagramStyleDefinition.xsd, dml-diagramStyleDefinition.xsd, dml-diagramStyleDefinition.xsd, dml-diagramStyleDefinition.xsd, dml-diagramStyleDefinition.xsd, dml-diagramStyleDefinition.xsd, dml-diagramStyleDefinition.xsd, dml-diagramStyleDefinition.xsd, dml-lockedCanvas.xsd, dml-picture.xsd, dml-spreadsheetDrawing.xsd, dml-spreadsheetDrawing.xsd, dml-spreadsheetDrawing.xsd, dml-spreadsheetDrawing.xsd, dml-spreadsheetDrawing.xsd, dml-wordprocessingDrawing.xsd, pml-animationInfo.xsd, pml-comments.xsd, pml-embedding.xsd, pml-presentation.xsd, pml-presentation.xsd, pml-presentation.xsd, pml-presentationProperties.xsd, pml-slide.xsd, pml-viewProperties.xsd |
||
GB | No schemaLocation for XML namespace | te | OOXML XML Schemas reference xml:space as an attribute value, but don't provide a schemaLocation for the schema for the XML namespace. Although this is legal XML Schema (the schemaLocation is a hint, rather than required), it imposes an unnecessary complication on using the schema (since the schema location must be specified separately, either automatically by the validator as MSXML does, or using a catalog as most other tools do). | Remedy: Alter the stylesheets
(wml.xsd, shared-math.xsd) which import the xml namespace to include a
schemaLocation of http://www.w3.org/2001/xml.xsd.
Affects files: wml.xsd, shared-math.xsd |
||
GB | Conflicting simple type definitions within XML schema | te | In a number of places within the
schema, the same simple type is defined within different parts of the
schema with different definitions. For example, ST_OnOff in
shared-math.xsd allows "on" and "off" as values; ST_OnOff in wml.xsd
allows "on", "off", "true", "false", "0", "1".
The vast majority of definitions that appear in more than one schema are different in some way, ranging from simple differences in the documentation, to actual conflicts in allowed values.] In the following analysis of conflicting definitions, the UK is restricting itself to commenting on those definitions which have the same type name, and are clearly intended to do the same thing. There are a number of other definitions which share the same name, but are intended to do different things (such as ST_Direction in DML and PML, and less clearly ST_Angle in DML and VML) - these are confusing but not as serious as the descriptions below. |
See following entries | s | |
GB | ST_AlgType | te | ST_AlgType is defined in wml.xsd and in pml-presentation.xsd. In the former, it allows value typeAny. In the latter, it allows values typeAny and invalid. It is unclear why it is legal to specify an invalid algorithm, and no behaviour is specified if an invalid algorithm is provided. | Remedy: Rationalize on the former | ||
GB | ST_AlgClass | te | ST_AlgClass is defined in wml.xsd and in pml-presentation.xsd. In the former, it allows value hash. In the latter, it allows values hash and invalid. It is unclear why it is legal to specify an invalid algorithm class, and no behaviour is specified if an invalid algorithm is provided.. | Remedy: Rationalize on the former | ||
GB | ST_CalendarType | te | ST_CalendarType is defined in sml.xsd and in wml.xsd. In the former, it allows values none, gregorianUs, gregorianMeFrench, and gregorianMeArabic that are not present in the latter. In the latter, it allows the value saka not present in the former. All sections of a standard should support the same calendars. | Remedy: Combine the valid calendar types into a single definition of valid calendars. | ||
GB | ST_ColorSchemeIndex | te | ST_ColorSchemeIndex is defined in wml.xsd and in dml-baseStylesheet.xsd. In the former, it allows values dark1, light1, etc. hyperlink and followedHyperlink. In the latter, it allows values dk1, lt1, etc. hlink and folHlink. | Remedy: Rationalize to the former. | ||
GB | ST_CryptProv | te | ST_CryptProv is defined in wml.xsd and in pml-presentation.xsd. In the latter it allows the value "invalid". It is unclear why it is legal to specify an invalid cryptographic provide, and no behaviour is specified if an invalid provider is provided. In addition, in the former, the rsaFull value is described as "Any provider" rather than "RSA Full Encryption Scheme" as it is in the latter.. | Remedy: Remove "invalid" as a value. Correct the documentation in the schema | ||
GB | ST_HorizontalAlignment | te | ST_HorizontalAlignment is defined in sml.xsd and dml-diagramTypes.xsd. In the former, it takes values "left", "right", "center". In the latter, it takes values "l", "r", "ctr". Terminology should be consistent within a standard. | Remedy: Change "l", "r" and "ctr" in the latter to match the "left", "right", "center" values in the former. | ||
GB | ST_OnOff | te | ST_OnOff in shared-math.xsd allows "on" and "off" as values; ST_OnOff in wml.xsd allows "on", "off", "true", "false", "0", "1". | Remedy: rationalize the schema definitions so the type does not conflict, preferably by restricting wml.xsd to only allow "on" and "off". | ||
GB | ST_TextAlignment | te | ST_TextAlignment is defined in wml.xsd and dml-diagramTypes.xsd. In the former, it takes values "left", "right", "center". In the latter, it takes values "l", "r", "ctr". Terminology should be consistent within a standard.. | Remedy: Change "l", "r" and "ctr" in the latter to match the "left", "right", "center" values in the former | ||
GB | ST_TrueFalseBlank | te | ST_TrueFalseBlank is defined in vml-officeDrawing.xsd and vml-spreadsheetDrawing.xsd. In vml-officeDrawing, it takes values "true" and "false" (among others). In vml-spreadsheetDrawing, these values must be "True" or "False". Terminology should be consistent within a standard. | Remedy: Change "True" and "False" in the latter to "true" and "false". | ||
GB | ST_TwipsMeasure | te | ST_TwipsMeasure is defined in shared-math.xsd and wml.xsd. In the former, it is an xsd:unsignedInt. In the latter, it is an ST_UnsignedDecimalNumber, which maps to an xsd:unsignedLong. The same type name should not have different ranges in different parts of the specification. | . Remedy: Change ST_TwipsMeasure to use xsd:unsignedLong throughout | ||
GB | ST_VerticalAlignment | te | ST_VerticalAlignment is defined in sml-styles.xsd and in dml-diagramTypes.xsd. In the former, it can be top, center or bottom (among other values). In the latter, these are "t", "mid" or "b". Terminology should be consistent within a standard. | Remedy: Change the latter to use "top", "center" and "bottom" in place of "t", "mid" and "b". | ||
GB | ST_YAlign | te | ST_YAlign is defined in shared-math.xsd and wml.xsd. In the former, it allows the value "bot". In the latter, the corresponding value is "bottom". Terminology should be consistent within a standard. | Remedy: Change the former to use "bottom". | ||
END |
1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **)
2 Type of comment: ge = general te = technical ed = editorial
NOTE Columns 1, 2, 4, 5 are compulsory.
page of 98
ISO electronic balloting commenting template/version 2001-10
|
![]() |
|