Template for comments and secretariat observations | Date: 2008-08-31 | 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 |
AFNOR COMMENT ON ISO/IEC DIS
29500
0 Introduction
In accordance with 9.8 of the ISO/IEC JTC 1
Directives, AFNOR disapproves Fast Track
ISO/IEC DIS 29500
“Information technology -- Office Open XML file formats » for the reasons,
stated below, albeit with proposals for changes that would possibly make the
document acceptable as a two-part Technical Specification*).
Acceptance of these proposals shall be subject to a
two-months letter ballot for confirmation that the vote can be changed to an
approval.
1 General
After 5 months of extensive discussions between
stakeholders in the field of revisable document formats, AFNOR, in the aim to
obtain a single standard for XML office document formats within 3 years, makes
the following proposal:
2 Structure of the new documents to be
drafted
2.1 Part 1, The OOXML
Core
As regards Part 1, the OOXML core to be drafted, the
following comments shall be taken into account:
Many remaining (mainly editorial) comments that, for
reasons of a lack of time, could not be exhaustively dealt with shall be
resolved (field definitions need to be improved in order to take into account
different contexts)
The attention is drawn to the fact that according to
the AFNOR point of view, the issues with respect to mathematical functions and
vector representation of images cannot at present be rejected because of the
lack of maturity of standards and would only be dealt with during the
convergence process.
2.2 Part 2, The OOXML ECMA
Extensions
Part 2, the OOXML ECMA Extensions, shall contain the
following elements:
3 Specific technical
comments
The comment table attached to the vote is part of comments that were discussed in the national mirror committee of JTC 1/SC 34 and upon which no consensus has been reached as such.
These comments show that potential anomalies have been identified in the document.
The comments may however be taken into consideration by the BRM in the context of negotiation on reorganizing and redrafting the current ISO/IEC DIS 29500 into a two-part Technical Specification and the convergence process afterwards.
F1006 | Part 1, Section 2.4 “Document Conformance” | line 22 | te | 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? | An explicit Unicode version reference should be made in the Conformance section. | |
F1007 | Part 1, Section 2.6 “Interoperability Guidelines” | - | ed | The use of the word “element” is ambiguous. Is this to mean XML elements (but not attributes, character content, etc.)? Or does this mean an element of the Standard, in the usage of ISO Directives, Part 2? | Clarify the use of the word “element” perhaps by saying “XML element” if that is what is meant. | |
F1008 | Part 1, Section 2.6 “Interoperability Guidelines” | line 15 | ed | Obviously the Standard anticipates such behavior since it explicitly contains the present example describing this behavior and calls it conforming. | Perhaps it is meant to say, “...this Standard does not recommend this behavior”. | |
F1009 | Part 1, Section 2.6 “Interoperability Guidelines” | lines 33-34 | ed | Is this recommending that a non-public, internal-only, work-for-hire application author create “publicly available documentation” on what subset of the standard it supports? The business relationship between the software author and his customer should not be a concern of this standard. | Change to read, “a software application should be accompanied by documentation...” | |
F1010 | Part 1, Section 4 “Definitions” | behavior, implementation-defined | te | “application-specific”, at least in common standards use, is not the same as application-defined, viz. ANSI C Programming Language | Use “application-defined” consistently where the intent is for applications to document their behavior. | |
F1011 | Part 1, Section 4 “Definitions” | behavior, unspecified | ed | This definition doesn't work, since the Standard, in defining compliance in Section 2, says that “compliance is purely syntactic”. So no behaviors are required. Therefore, by this definition, all behaviors are unspecified? Surely this is not what is meant. | Clarify this definition. Perhaps it is meant to say, “Behavior for which this Standard does not make a recommendation”? | |
F1012 | Part 1, Section 4 “Definitions” | Office Open XML Document | ed | This definition doesn't hold together. Are these two different definitions? Or two clause of which either will define the term? Or both together define the term? | Clarify the definition | |
F1013 | Part 1, Section 9.1.1 | - | te | ASCII requires a normative reference since there are several national variations. | Suggest reference be made to ISO/IEC 646:1983 or ANSI X3.4-1986 | |
F1014 | Part 1, Section 9.1.5 | - | 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. | If interleaving is not permitted then it should not be described in Part 2. | |
F1015 | Part 1, Section 9.1.7 | line 10 | ed | The naming convention giving is incorrect. H is a hexadecimal digit, not a hexadecimal value. | Follow correct usage pattern as established earlier in 9.1.1. | |
F1016 | Part 1, Section 9.1.9 | line 25 | ed | Incorrect subject. A producer qua producer does not round trip. | Should say, “Conforming producers that are also consumers should...” | |
F1017 | Part 1, Section 9.2 | page 18, line 8 | ed | Extra period following “explicit.” | Remove extraneous punctuation | |
F1018 | Part 1, Section 10.1.2 | line 20 | te | 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. | Correct the reference to point to the correct clause. | |
F1019 | Part 1, Section 11.3.1 | lines 15-17 | te | 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. | 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...” | |
F1020 | Part 1, Section 12.3.5 | - | te | This binary part is said to be used for the storage of “arbitrary user-defined data”. No further detail is given as to what user action would trigger the use of this “user-defined” data. Without further definition, no interoperability of this feature is possible. | Fully define the use of Custom Property Part | |
F1021 | Part 1, Section 15.2.6 | - | 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? | Clarify the meaning. | |
F1022 | Part 1, Section 15.2.8 | - | ed | The examples given are rendered useless by the predominance of the VML in the markup. | Make a more succinct and clear example by concentrating on the control persistence. | |
F1023 | Part 1, Section 15.2.12 | - | 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” | Provide reference to intended specifications for TrueType and OpenType | |
F1024 | Part 1, Section 15.2.14 | - | 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. | 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. | |
F1025 | Part 1, Section 15.2.15 | - | 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. | Clarify what size the thumbnails should be, or that the images are scaled. | |
F1026 | Part 1, Appendix | te | The reference given for the Zip format does not provide a date or version, though this specification is frequently revised, | Reference should be made to a particular dated and labeled version. | ||
F1027 | Part 1, Section 4. Definitions | page 6, lines 2-4 | te | This paragraph does not account for many tokens of the fields and formulas grammars, and explicitly rejects that these be defined by implicit references to well-known entities borrowed from outside of the OOXML text. This has the probably unwanted effect to rule out most fields and formulas from the standard proposal, notwithstanding other parts that may need to leverage similar constructs. | Improve the section contents so as to enable the description of fields and formulas or else remove fields and formulas from the OOXML text. | |
F1028 | Part 1, Section 9.1.1 Part Names | page 16, line 14 | te | Since line 12 tells that '%' can be a non-escaped character, the only possible meaning of '%10' is the character numbered 10 hexa in the (unspecified so far) ASCII table. Proper ways to enter '%10' would encompass escaping '%', escaping '1' or escaping '0', or any combination of these. This is unexpected/complex enough to deserve a mention of that consequence of '%' being accepted as a non-escaped character. An alternative would be to command that '%' be always part of an escape character, the literal '%' then being only entered as an escape character (like the & of HTML). | Warn implementors about the consequences of '%' being a non-escaped character. | |
F1029 | Part 1, Section 9.1.1 Part Names | page 16, line 15 | ed | Extraneous square bracket at the end of the line. | Remove the extraneous square bracket. | |
F1030 | Part 1, Section 15.2.6 Digital Signature Origin Part | page 142, line 4 | ed | The beginning of the line is misaligned. | Align the beginning of the line. | |
F1031 | Part 1, Section 15.2.6 Digital Signature Origin Part | page 142, line 4 | te | The 'it shall the target' clause is meaningless. | Define the Digital Signature Origin Part properly or else remove it from the OOXML proposal. | |
F1032 | Part 1, Section 2.4 Document Conformance | page 3, line 20 | te | What does 'the schema' refer to? Examining the definition of OOXML document conformance from the viewpoint of the extensibility mechanism, the topic proves totally confused in the text, mixing references to 'the schema', that would induce that OOXML defines an overarching schema that all documents should conform to, and 'Schemas' (line 11), that emphasizes the existence of main subparts as WordprocessingML, relegating the schema parts dedicated to extensibility to the validation procedure (line 12), and even confusing the topic further with 'Any XML element or attribute not explicitly included in this Standard shall use the extensibility mechanisms described by Parts 4 and 5 of this Standard', which, beyond using a formulation that is inappropriate when describing the structural properties of a storage format, is presented as a separate constraint upon conformant documents whereas the very same constraint is already expressed line 20. | Clarify the respective contributions of OOXML schemas (including the extensibility one) and of extra schemas (the extending one) to the schema that is referred to in the definition of conformant documents. | |
F2000 | Part 2 | ge | Part 2 defines Open Packaging Conventions (OPC) in terms that, according to Part 1, Section 9.1 Constraints on Office Open XML's Use of OPC, are more general than needed for the purpose of OOXML. This is due to bring confusion, and should be resolved. | Part 2 should be amended either by: 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. | ||
F2001 | Part 2, Section 1. Scope | page 1, lines 9 | ed | 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). | Replace 'guidelines' with 'rules'. | |
F2002 | Part 2, Section 3. Definitions | page 4, line 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. | Define 'package model' in unambiguous terms and use the resulting definition consistently throughout the OOXML text. | |
F3000 | Part 3, Section 8.3.4.1.1 extLst/ext Syntax | page 456, line 0 | ed | The image that is supposed to define the syntax for the extLst element is blurred. | Provide the definition of the extLst element in plain text. | |
F3001 | Part 3, Section 8.3.4.1.1 extLst/ext Syntax | page 455, line 33 | te | The 'The extLst and ext construct' proposition makes no sense as far as XML is concerned. It appears from the text that the intent is to describe the extLst element, which includes ext elements. | Rewrite the sentence using XML concepts. | |
F3002 | Part 3, Section 8.3.4.1.1 extLst/ext Syntax | page 456, line 1 | te | The provided syntax is not a well-formed XML fragment. Therefore the definition of extLst is broken. | Provide a correct definition of the extLst element. | |
F4000 | Part 4 | ge | The elision of 'Office' from 'Office Open XML' in 'OpenXML' is confusing. | Replace 'OpenXML' by the proper abbreviation 'OOXML' (short notation) or 'Office Open XML' (long notation) throughout the document. | ||
F4002 | Part 4, Foreword | page vi, line 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 | 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. | |
F4004 | Part 4, Introduction | page vii, line 8 | te | A standard should not rely on existing applications and brands for its description. | Remove the reference to Microsoft Office. | |
F4005 | Part 4, Introduction | page vii, lines 7&8 | te | The use of 'large' into 'large existing investments in Microsoft Office documents' is a judgment call relying upon unsupported assertions. | Remove 'large'. | |
F4007 | Part 4, Section 1.1 WordprocessingML Part Summary | page 1, line 5 | ed | Table row 'Alternative Format Import' is deemed to have no root element and no reference. The value of this row is unclear. | Clarify the table purpose. | |
F4008 | Part 4, Section 1.2 SpreadsheetML Part Summary | page 1, line 6 | ed | Table row 'Custom Property' is deemed to have no root element and no reference. The value of this row is unclear. | Clarify the table purpose. | |
F4009 | Part 4, Section 1.5 Shared Part Summary | page 3, line 1 | ed | Eleven table rows are deemed to have no root element and no reference. The value of these rows is unclear. | Clarify the table purpose. | |
F4010 | Part 4, Section 2.2 Main Document Story | page 26, lines 24&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. | Rewrite or remove Section 2.2. May consider explaining what a OOXML story would be in terms of documents renditions by applications. | |
F4011 | Part 4, Section 2.2 Main Document Story | page 26, lines 27&28 | te | The definition of 'story' is inappropriate. As far as OOXML documents are concerned, the use of a text editor enables any user to modify (type into) each and any region of any XML subpart of a document. | Clarify the definition of 'story'. | |
F4012 | Part 4, Section 2.2 Main Document Story | page 26, lines 28 | ed | The notion of 'most important' subpart of a document is confusing. Is it expected that removing everything else would be harmless? Is there a hierarchy between subparts of documents that would underly that judgment call? | Remove references to a 'most important story'. Rework the introduction of the body element of a document element. | |
F4013 | Part 4, Section 2.2.1 background (Document Background) | page 27, line 2 | te | The use of the second instance of word 'this' within 'This element specifies the background information for this document.' is inappropriate, it makes the whole sentence meaningless, and background is hence undefined. | Clarify the definition of 'background'. | |
F4014 | Part 4, Section 2.2.1 background (Document Background) | page 27, lines 1&2 | te | Assuming that background be referring to the background of the document defined by one of its enclosing elements, assuming that the notion of document page and the notion of displaying be properly defined and that their definitions match commonly accepted ones, then the 'This background shall be displayed on all pages of the document, behind all other document content.' sentence makes unclear whether the total surface of a page must be filled with the background, or else how the subpart of the said surface can be determined. | Clarify the definition of 'background'. | |
F4015 | Part 4, Section 2.2.1 background (Document Background) | page 27, lines 8-22 | ed | This example is unduly heavy, the image brings no value. | Remove the image. | |
F4016 | Part 4, Section 2.2.1 background (Document Background) | page 27, lines 8&21 | te | Contradicting use of accent3 and accent5. | Fix the contradiction. | |
F4017 | Part 4, Section 2.2.1 background (Document Background) | page 28 | ed | The line numbering does not cope well with tables. In this particular case, the closest line number for the table of child elements lies on the previous page. | Number tables appropriately. | |
F4019 | Part 4, Section 2.2.1 background (Document Background) | page 28, line 0 | te | Child elements of background are described using deprecated namespaces only. Accordingly, the background element should either be described in terms of current OOXML elements or deprecated. | Describe the background element in terms of non-deprecated elements or remove it. | |
F4021 | Part 4, Section 2.2.1 background (Document Background) | page 28, line 1 | te | The definition of the themeColor attribute references the document's Theme part without properly defining it nor providing an explicit reference to the OOXML section that defines it. | Define the Theme part of a document properly or else add an explicit reference to the section that does so. | |
F4022 | Part 4, Section 2.2.1 background (Document Background) | page 28, line 1 | te | The sentence 'or auto to allow
a consumer to automatically determine the background color as appropriate.' does not define the appropriate behavior of the consumer, whereas the definition of the corresponding simple type, found in Part 4, page 1737, explicitly states that 'This value shall be used to specify an automatically determined color value, the meaning of which is interpreted based on the context of the parent XML element.' |
Define the characteristics of the auto value for the color attribute of the background element properly. | |
F4023 | Part 4, Section 2.2.1 background (Document Background) | page 28, line 1 | te | The sentence 'This color may either be presented as a hex value (in RRGGBB format)' does not make proper reference to a well accepted color description system. | Clarify the definition of the color attribute. | |
F4024 | Part 4, Section 2.2.1 background (Document Background) | page 28, line 1 | ed | The use of 'presented' in the 'This color may either be presented as a hex value (in RRGGBB format)' sentence is not appropriate, since the text is referring to the definition of the document contents, not its presentation. | Use 'defined' or 'specified' instead. | |
F4025 | Part 4, Section 2.2.1 background (Document Background) | page 28, line 1 | te | The color value can be superseded, according to 'this value is superseded by the theme color value'. The use of superseded values in a given document instance should be discouraged, or even forbidden, since these only introduce clutter and ambiguity. | Define color and themeColor attributes as mutually exclusive. | |
F4026 | Part 4, Section 2.2.1 background (Document Background) | page 28, line 1 | ed | The example focuses upon a clumsy feature that should be removed (color superseded by themeColor) while it should illustrate properly the relationship between the (remote) definition of a given theme and the effect on the considered background element instance. | Rewrite the example. | |
F4027 | Part 4, Section 2.2.1 background (Document Background) | page 28, line 1 | te | The definition of the themeColor attribute references the document's Theme part without properly defining it nor providing an explicit reference to the OOXML section that defines it. | Define the Theme part of a document properly or else add an explicit reference to the section that does so. | |
F4028 | Part 4, Section 2.2.1 background (Document Background) | page 28, line 1 | te | The themeShade attribute can be specified and will be ignored when the themeColor attribute is not specified. The use of useless optional values in a given document instance should be discouraged, or even forbidden, since these only introduce clutter and ambiguity. | Subordinate the use of themeShade to the use of themeColor. | |
F4029 | Part 4, Section 2.2.1 background (Document Background) | page 28, line 1 | te | The sentence 'the color resultingfrom the use of this attribute with any appropriate themeTint and themeShade attribute value calculations applied' somewhat contradicts the first sentence of the definition for themeColor. | Clarify the definition of the themeColor attribute in respect to its relationships to the themeShade an themeTint attributes. | |
F4030 | Part 4, Section 2.2.1 background (Document Background) | page 29, line 0 | te | There are several instances of the word 'border' that are meaningless in this context (the text is supposed to describe the 'background' element at that location). | 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. | |
F4031 | Part 4, Section 2.3.3.14 lid (Language ID for Phonetic Guide) | page 256, line 4 | ed | This sentence makes no sense in English. | Rewrite the sentence in English or remove it. | |
F4035 | Part4, Section 2.15.3.6 autoSpaceLikeWord95 (Emulate Word 95 Full-Width Character Spacing) | page 1378, lines 12-17 | te | This definition is intrinsically based upon material that is not part of the OOXML submission, and that is not part of any known standard either. As such, it cannot be accepted. A proper definition must be provided for the autoSpaceLikeWord95 feature, or the feature must be removed altogether. | Define the autoSpaceLikeWord95 feature properly or drop it from the OOXML proposal. | |
F4036 | Part4, Section 2.15.3.26 footnoteLayoutLikeWW8 (Emulate Word 6.x/95/97 Footnote Placement) | page 1416, lines 14-17 | te | This definition is intrinsically based upon material that is not part of the OOXML submission, and that is not part of any known standard either. As such, it cannot be accepted. A proper definition must be provided for the footnoteLayoutLikeWW8 feature, or the feature must be removed altogether. | Define the footnoteLayoutLikeWW8 feature properly or drop it from the OOXML proposal. | |
F4037 | Part4, Section 2.15.3.31 lineWrapLikeWord6 (Emulate Word 6.0 Line Wrapping for East Asian Text) | page 1426, lines 11-16 | te | This definition is intrinsically based upon material that is not part of the OOXML submission, and that is not part of any known standard either. As such, it cannot be accepted. A proper definition must be provided for the lineWrapLikeWord6 feature, or the feature must be removed altogether. | Define the lineWrapLikeWord6 feature properly or drop it from the OOXML proposal. | |
F4038 | Part4, Section 2.15.3.32 mwSmallCaps (Emulate Word 5.x for the Macintosh Small Caps Formatting) | page 1427, lines 13-18 | te | This definition is intrinsically based upon material that is not part of the OOXML submission, and that is not part of any known standard either. As such, it cannot be accepted. A proper definition must be provided for the mwSmallCaps feature, or the feature must be removed altogether. | Define the mwSmallCaps feature properly or drop it from the OOXML proposal. | |
F4039 | Part4, Section 2.15.3.41 shapeLayoutLikeWW8 (Emulate Word 97 Text Wrapping Around Floating Objects) | page 1442, lines 13-18 | te | This definition is intrinsically based upon material that is not part of the OOXML submission, and that is not part of any known standard either. As such, it cannot be accepted. A proper definition must be provided for the shapeLayoutLikeWW8 feature, or the feature must be removed altogether. | Define the shapeLayoutLikeWW8 feature properly or drop it from the OOXML proposal. | |
F4040 | Part4, Section 2.15.3.51 suppressTopSpacingWP (Emulate WordPerfect 5.x Line Spacing) | page 1462, lines 11-16 | te | This definition is intrinsically based upon material that is not part of the OOXML submission, and that is not part of any known standard either. As such, it cannot be accepted. A proper definition must be provided for the suppressTopSpacingWP feature, or the feature must be removed altogether. | Define the suppressTopSpacingWP feature properly or drop it from the OOXML proposal. | |
F4041 | Part4, Section 2.15.3.53 truncateFontHeightsLikeWP6 (Emulate WordPerfect 6.x Font Height Calculation) | page 1467, lines 9-14 | te | This definition is intrinsically based upon material that is not part of the OOXML submission, and that is not part of any known standard either. As such, it cannot be accepted. A proper definition must be provided for the truncateFontHeightsLikeWP6 feature, or the feature must be removed altogether. | Define the truncateFontHeightsLikeWP6 feature properly or drop it from the OOXML proposal. | |
F4042 | Part4, Section 2.15.3.63 useWord2002TableStyleRules (Emulate Word 2002 Table Style Rules) | page 1481, lines 9-14 | te | This definition is intrinsically based upon material that is not part of the OOXML submission, and that is not part of any known standard either. As such, it cannot be accepted. A proper definition must be provided for the useWord2002TableStyleRules feature, or the feature must be removed altogether. | Define the useWord2002TableStyleRules feature properly or drop it from the OOXML proposal. | |
F4043 | Part4, Section 2.15.3.64 useWord97LineBreakRules (Emulate Word 97 East Asian Line Breaking) | page 1482, lines 10-15 | te | This definition is intrinsically based upon material that is not part of the OOXML submission, and that is not part of any known standard either. As such, it cannot be accepted. A proper definition must be provided for the useWord97LineBreakRules feature, or the feature must be removed altogether. | Define the useWord97LineBreakRules feature properly or drop it from the OOXML proposal. | |
F4044 | Part4, Section 2.15.3.65 wpJustification (Emulate WordPerfect 6.x Paragraph Justification) | page 1483, lines 16-21 | te | This definition is intrinsically based upon material that is not part of the OOXML submission, and that is not part of any known standard either. As such, it cannot be accepted. A proper definition must be provided for the wpJustification feature, or the feature must be removed altogether. | Define the wpJustification feature properly or drop it from the OOXML proposal. | |
F4045 | Part 4, Section 2.15.3.66 wpSpaceWidth (Space width) | - | te | This is the “wpSpaceWidth” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. | Define the intended behavior. | |
F4046 | Part 4, Section 2.16 Fields & Hyperlinks | page 1487, line 20 | te | The definition for 'field update' is confusing. Its relationship to 'field result's, applications, and the field contents should be clarified. Note that the English meaning of 'update' implies that the field itself is modified (which is in contradiction with the definition for 'field result'). In other words, the use of 'update' might be abusive, except if clarified. | Clarify the definition of 'field update'. | |
F4047 | Part 4, Section 2.16 Fields & Hyperlinks | page 1487, line 21 | te | Except if a clear definition of 'field update' would be provided that would clearly show the innocuousness of this, we would expect the exclusion of the how and when it happens from the OOXML proposal to be abusive. | Remove the notion of 'field update' or specify it extensively. | |
F4048 | Part 4, Section 2.16.1 Syntax | page 1487, line 23 to page 1489, line 17 | te | The syntax of fields 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 the needed rectitude to define the notation used. In any case, the notation used should at least be referenced without ambiguity, and the proposed definitions should be reviewed for conformance to the said notation. | Define the notation used for defining fields, either in extenso or via a proper reference to an external definition. | |
F4049 | Part 4, Section 2.16.1 Syntax | pages 1487-1490 | te | The introduction of a specific grammar for fields representation is useless. The same information could have been represented using standard XML constructs, which would have had several benefits, starting with a lower cost of entry for applications, hence greater interoperability. | Remove the fields specific grammar. Define artifacts that depend on it in terms of proper XML constructs (elements, attributes, types, etc.) throughout the OOXML text. | |
F4050 | Part 4, Section 2.16.2 XML representation | page 1490, lines 20, 23, 25 | te | The prescribed use of fldChar elements with fldCharType attributes values as begin, separate and end, introduces an unneeded level of indirection to provide a structure that could and should leverage native XML constructs. | Replace the prescribed use of generic elements by the proper definition of an XML schema for fields. | |
F4051 | Part 4, Section 2.16.4.3 General formatting | page 1500, line 7 | te | The use of different notations for the AIUEO switch argument and the aiueo ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to aiueo or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4052 | Part4, Section 2.16.4.3 General formatting | page 1501, line 0 | te | The definition for BATHTEXT references 'the given Thai format', which makes no sense in the context of that definition. | Clarify the definition of 'BATHTEXT'. | |
F4054 | Part 4, Section 2.16.4.3 General formatting | page 1501, line 0 | te | The Caps switch argument has no documented ST_NumberFormat equivalent. This shades doubt upon the value of the switch argument, or else a potential hole in ST_NumberFormat values. | Create a ST_NumberFormat value that matches the Caps switch argument or (better) suppress the need for the switch argument, either by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields, or simply by suppressing it from the OOXML proposal altogether. | |
F4055 | Part 4, Section 2.16.4.3 General formatting | page 1501, line 0 | te | The CHARFORMAT switch argument definition should be simple enough to fit in the table. Reading the discussion referenced in this table row, we understand that the CHARFORMAT behavior is inherently complex, more complex than other switch arguments. Accordingly, we question its status as a number formatting argument. | Add a proper definition for CHARFORMAT in the table or else remove all references to CHARFORMAT from the OOXML text. | |
F4056 | Part 4, Section 2.16.4.3 General formatting | page 1501, line 0 | te | The Caps switch argument does not make sense as a number formatting argument. | Clarify or suppress the Caps switch from that table. | |
F4057 | Part 4, Section 2.16.4.3 General formatting | page 1501, line 0 | te | The use of different notations for the ARABICABJAD switch argument and the arabicAbjad ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to arabicAbjad or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4058 | Part 4, Section 2.16.4.3 General formatting | page 1501, line 0 | te | The use of different notations for the CHINESENUM1 switch argument and the chineseCounting ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to chineseCounting or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4059 | Part 4, Section 2.16.4.3 General formatting | page 1501, line 0 | te | The CHARFORMAT switch argument has no documented ST_NumberFormat equivalent. This shades doubt upon the value of the switch argument, or else a potential hole in ST_NumberFormat values. | Create a ST_NumberFormat value that matches the CHARFORMAT switch argument or (better) suppress the need for the switch argument, either by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields, or simply by suppressing it from the OOXML proposal altogether. | |
F4060 | Part 4, Section 2.16.4.3 General formatting | page 1501, line 0 | te | The MERGEFORMAT switch argument definition should be simple enough to fit in the table. Reading the discussion referenced in this table row, we understand that the MERGEFORMAT behavior is inherently complex, more complex than other switch arguments. Accordingly, we question its status as a number formatting argument. | Add a proper definition for MERGEFORMAT in the table or else remove all references to MERGEFORMAT from the OOXML text. | |
F4061 | Part 4, Section 2.16.4.3 General formatting | page 1501, line 0 | te | The use of different notations for the ARABICALPHA switch argument and the arabicAlpha ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to arabicAlpha or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4062 | Part 4, Section 2.16.4.3 General formatting | page 1501, line 0 | te | The alphabetic switch argument has no documented ST_NumberFormat equivalent. This shades doubt upon the value of the switch argument, or else a potential hole in ST_NumberFormat values. | Create a ST_NumberFormat value that matches the alphabetic switch argument or (better) suppress the need for the switch argument, either by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields, or simply by suppressing it from the OOXML proposal altogether. | |
F4063 | Part 4, Section 2.16.4.3 General formatting | page 1501, line 0 | te | The use of different notations for the Arabic switch argument and the decimal ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to decimal or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4064 | Part 4, Section 2.16.4.3 General formatting | page 1501, line 0 | te | The ALPHABETIC switch argument has no documented ST_NumberFormat equivalent. This shades doubt upon the value of the switch argument, or else a potential hole in ST_NumberFormat values. | Create a ST_NumberFormat value that matches the ALPHABETIC switch argument or (better) suppress the need for the switch argument, either by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields, or simply by suppressing it from the OOXML proposal altogether. | |
F4065 | Part 4, Section 2.16.4.3 General formatting | page 1501, line 0 | te | The BAHTTEXT switch argument has no documented ST_NumberFormat equivalent. This shades doubt upon the value of the switch argument, or else a potential hole in ST_NumberFormat values. | Create a ST_NumberFormat value that matches the BAHTTEXT switch argument or (better) suppress the need for the switch argument, either by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields, or simply by suppressing it from the OOXML proposal altogether. | |
F4066 | Part 4, Section 2.16.4.3 General formatting | page 1501, line 0 | te | The use of different notations for the ArabicDash switch argument and the numberInDash ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to numberInDash or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4067 | Part 4, Section 2.16.4.3 General formatting | page 1502, line 0 | te | The use of different notations for the DBNUM2 switch argument and the koreanCounting ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to koreanCounting or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4068 | Part 4, Section 2.16.4.3 General formatting | page 1502, line 0 | te | The use of different notations for the CHINESENUM2 switch argument and the chineseLegalSimplified ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to chineseLegalSimplified or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4069 | Part 4, Section 2.16.4.3 General formatting | page 1502, line 0 | te | The use of different notations for the DBNUM1 switch argument and the ideographDigital ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to ideographDigital or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4070 | Part 4, Section 2.16.4.3 General formatting | page 1502, line 0 | te | The use of different notations for the DBCHAR switch argument and the decimalFullWidth ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to decimalFullWidth or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4071 | Part 4, Section 2.16.4.3 General formatting | page 1502, line 0 | te | The use of different notations for the CHINESENUM3 switch argument and the chineseCountingThousand ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to chineseCountingThousand or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4072 | Part 4, Section 2.16.4.3 General formatting | page 1502, line 0 | te | The use of different notations for the CHOSUNG switch argument and the chosung ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to chosung or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4073 | Part 4, Section 2.16.4.3 General formatting | page 1502, line 0 | te | The use of different notations for the DBNUM4 switch argument and the japaneseDigitalTenThousand ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to japaneseDigitalTenThousand or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4074 | Part 4, Section 2.16.4.3 General formatting | page 1502, line 0 | te | The DollarText switch argument has no documented ST_NumberFormat equivalent. This shades doubt upon the value of the switch argument, or else a potential hole in ST_NumberFormat values. | Create a ST_NumberFormat value that matches the Caps switch argument or (better) suppress the need for the switch argument, either by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields, or simply by suppressing it from the OOXML proposal altogether. | |
F4075 | Part 4, Section 2.16.4.3 General formatting | page 1502, line 0 | te | The use of different notations for the DBNUM3 switch argument and the japaneseLegal ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to japaneseLegal or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4076 | Part 4, Section 2.16.4.3 General formatting | page 1502, line 0 | te | The use of different notations for the CIRCLENUM switch argument and the decimalEnclosedCircle ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to decimalEnclosedCircle or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4077 | Part 4, Section 2.16.4.3 General formatting | page 1503, line 0 | te | The use of different notations for the GB1 switch argument and the decimalEnclosedFullstop ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to decimalEnclosedFullstop or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4078 | Part 4, Section 2.16.4.3 General formatting | page 1503, line 0 | te | The use of different notations for the HEBREW1 switch argument and the hebrew1 ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to hebrew1 or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4079 | Part 4, Section 2.16.4.3 General formatting | page 1503, line 0 | te | The use of different notations for the HEBREW2 switch argument and the hebrew2 ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to hebrew2 or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4080 | Part 4, Section 2.16.4.3 General formatting | page 1503, line 0 | te | The use of different notations for the GB2 switch argument and the decimalEnclosedParen ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to decimalEnclosedParen or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4081 | Part 4, Section 2.16.4.3 General formatting | page 1503, line 0 | te | The FirstCap switch argument does not make sense as a number formatting argument. | Clarify or suppress the FirstCap switch from that table. | |
F4082 | Part 4, Section 2.16.4.3 General formatting | page 1503, line 0 | te | The use of different notations for the HINDIARABIC switch argument and the hindiNumbers ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to hindiNumbers or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4083 | Part 4, Section 2.16.4.3 General formatting | page 1503, line 0 | te | The use of different notations for the GANADA switch argument and the ganada ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to ganada or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4084 | Part 4, Section 2.16.4.3 General formatting | page 1503, line 0 | te | The use of different notations for the Hex switch argument and the hex ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to hex or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4085 | Part 4, Section 2.16.4.3 General formatting | page 1503, line 0 | te | The use of different notations for the GB4 switch argument and the ideographEnclosedCircle ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to ideographEnclosedCircle or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4086 | Part 4, Section 2.16.4.3 General formatting | page 1503, line 0 | te | The use of different notations for the GB3 switch argument and the decimalEnclosedCircleChinese ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to decimalEnclosedCircleChinese or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4087 | Part 4, Section 2.16.4.3 General formatting | page 1503, line 0 | te | The FirstCap switch argument has no documented ST_NumberFormat equivalent. This shades doubt upon the value of the switch argument, or else a potential hole in ST_NumberFormat values. | Create a ST_NumberFormat value that matches the FirstCap switch argument or (better) suppress the need for the switch argument, either by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields, or simply by suppressing it from the OOXML proposal altogether. | |
F4088 | Part 4, Section 2.16.4.3 General formatting | page 1504, line 0 | te | The KANJINUM1 switch argument has no documented ST_NumberFormat equivalent. This shades doubt upon the value of the switch argument, or else a potential hole in ST_NumberFormat values. | Create a ST_NumberFormat value that matches the KANJINUM1 switch argument or (better) suppress the need for the switch argument, either by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields, or simply by suppressing it from the OOXML proposal altogether. | |
F4089 | Part 4, Section 2.16.4.3 General formatting | page 1504, line 0 | te | The use of different notations for the SBCHAR switch argument and the decimalHalfWidth ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to decimalHalfWidth or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4090 | Part 4, Section 2.16.4.3 General formatting | page 1504, line 0 | ed | The example for the HINDICARDTEXT switch argument includes damaged graphical characters (in the PDF file). | Fix the damaged characters. | |
F4091 | Part 4, Section 2.16.4.3 General formatting | page 1504, line 0 | te | The use of different notations for the KANJINUM2 switch argument and the japaneseCounting ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to japaneseCounting or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4092 | Part 4, Section 2.16.4.3 General formatting | page 1504, line 0 | te | The use of different notations for the OrdText switch argument and the ordinalText ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to ordinalText or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4093 | Part 4, Section 2.16.4.3 General formatting | page 1504, line 0 | te | The use of different notations for the HINDILETTER2 switch argument and the hindiConsonants ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to hindiConsonants or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4094 | Part 4, Section 2.16.4.3 General formatting | page 1504, line 0 | te | The use of different notations for the HINDILETTER1 switch argument and the hindiVowels ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to hindiVowels or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4095 | Part 4, Section 2.16.4.3 General formatting | page 1504, line 0 | te | The use of different notations for the roman switch argument and the lowerRoman ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to lowerRoman or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4096 | Part 4, Section 2.16.4.3 General formatting | page 1504, line 0 | te | The MERGEFORMAT switch argument has no documented ST_NumberFormat equivalent. This shades doubt upon the value of the switch argument, or else a potential hole in ST_NumberFormat values. | Create a ST_NumberFormat value that matches the MERGEFORMAT switch argument or (better) suppress the need for the switch argument, either by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields, or simply by suppressing it from the OOXML proposal altogether. | |
F4097 | Part 4, Section 2.16.4.3 General formatting | page 1504, line 0 | te | The use of different notations for the Roman switch argument and the upperRoman ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to upperRoman or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4098 | Part 4, Section 2.16.4.3 General formatting | page 1504, line 0 | te | The Lower switch argument has no documented ST_NumberFormat equivalent. This shades doubt upon the value of the switch argument, or else a potential hole in ST_NumberFormat values. | Create a ST_NumberFormat value that matches the Lower switch argument or (better) suppress the need for the switch argument, either by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields, or simply by suppressing it from the OOXML proposal altogether. | |
F4099 | Part 4, Section 2.16.4.3 General formatting | page 1504, line 0 | te | The use of different notations for the Ordinal switch argument and the ordinal ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to ordinal or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4100 | Part 4, Section 2.16.4.3 General formatting | page 1504, line 0 | te | The KANJINUM3 switch argument has no documented ST_NumberFormat equivalent. This shades doubt upon the value of the switch argument, or else a potential hole in ST_NumberFormat values. | Create a ST_NumberFormat value that matches the KANJINUM3 switch argument or (better) suppress the need for the switch argument, either by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields, or simply by suppressing it from the OOXML proposal altogether. | |
F4101 | Part 4, Section 2.16.4.3 General formatting | page 1504, line 0 | te | The Lower switch argument does not make sense as a number formatting argument. | Clarify or suppress the Lower switch from that table. | |
F4102 | Part 4, Section 2.16.4.3 General formatting | page 1504, line 0 | te | The use of different notations for the HINDICARDTEXT switch argument and the hindiCounting ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to hindiCounting or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4103 | Part 4, Section 2.16.4.3 General formatting | page 1504, line 0 | te | The use of different notations for the IROHA switch argument and the iroha ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to iroha or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4104 | Part 4, Section 2.16.4.3 General formatting | page 1505, line 0 | te | The Upper switch argument does not make sense as a number formatting argument. | Clarify or suppress the Upper switch from that table. | |
F4105 | Part 4, Section 2.16.4.3 General formatting | page 1505, line 0 | te | The use of different notations for the THAIARABIC switch argument and the thaiNumbers ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to thaiNumbers or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4106 | Part 4, Section 2.16.4.3 General formatting | page 1505, line 0 | te | The use of different notations for the ZODIAC1 switch argument and the ideographTraditional ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to ideographTraditional or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4107 | Part 4, Section 2.16.4.3 General formatting | page 1505, line 0 | te | The use of different notations for the ZODIAC3 switch argument and the ideographZodiacTraditional ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to ideographZodiacTraditional or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4108 | Part 4, Section 2.16.4.3 General formatting | page 1505, line 0 | te | The use of different notations for the ZODIAC2 switch argument and the ideographZodiac ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to ideographZodiac or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4109 | Part 4, Section 2.16.4.3 General formatting | page 1505, line 0 | te | The use of different notations for the THAILETTER switch argument and the thaiLetters ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to thaiLetters or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4110 | Part 4, Section 2.16.4.3 General formatting | page 1505, line 0 | te | The use of different notations for the VIETCARDTEXT switch argument and the vietnameseCounting ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to vietnameseCounting or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4111 | Part 4, Section 2.16.4.3 General formatting | page 1505, line 0 | te | The Upper switch argument has no documented ST_NumberFormat equivalent. This shades doubt upon the value of the switch argument, or else a potential hole in ST_NumberFormat values. | Create a ST_NumberFormat value that matches the Upper switch argument or (better) suppress the need for the switch argument, either by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields, or simply by suppressing it from the OOXML proposal altogether. | |
F4112 | Part 4, Section 2.16.4.3 General formatting | page 1505, line 0 | te | The use of different notations for the THAICARDTEXT switch argument and the thaiCounting ST_NumberFormat enumeration value is useless and confusing. | Align the switch argument to thaiCounting or (better) suppress the need for the switch argument by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields. | |
F4113 | Part 4, Section 2.16.4.3 General formatting | page 1505, line 2 to page 1506, line 35 | te | The CHARFORMAT switch argument is clearly a (complex) shorthand notation for something that can be described unambiguously by other OOXML notations. Moreover, it overloads those notations and is superseded by them when a conflict occurs. As such, it must be seen as an input device, not as a document storage feature, and should be removed. | Remove all references to CHARFORMAT from the OOXML text. | |
F4114 | Part 4, Section 2.16.4.3 General formatting | page 1506, line 36 to page 1507, line 28 | te | The MERGEFORMAT switch argument is clearly a (complex) shorthand notation for something that could be described unambiguously by other OOXML notations, for example by a consistent use of the r:rPr element. In the current state of its definition, it has the bizarre property to give a regular XML element (r:rPr) the status of 'consider', while the absence of MERGEFORMAT would imply that the r:rPr be ignored, which we consider as badly designed (if the r:rPr element had to be ignored, it would be better to omit it altogether). We thus tend to recommend that the a proper use of r:rPr be considered and that MERGEFORMAT be removed. | Remove all references to MERGEFORMAT from the OOXML text. | |
F4115 | Part 4, Section 2.16.4.3 General formatting | page 1506, line 37, 38 and 40 | te | The MERGEFORMAT definition, in particular in
its specifying that 'The formatting is expressed in XML using
an rPr element on the run that contains the most recently updated field result.', precludes any use of the notation provided on line 40. |
Clarify the definition, improve the example, or remove all references to MERGEFORMAT from the OOXML text. | |
F4116 | Part 4, Section 2.16.4.3 General formatting | page 1507, line 1&2 | te | The example fails to make clear how the seconds get underlined. The sole acceptable explanation we found was something along 'gets underline by the application' (with or without an interactive session with a human being). Since the reminder of the explanation makes explicit references to field updating, which is a different mechanism, the explanation should make clearer how the seconds get underlined. | Clarify the explanation using relevant terms. | |
F4117 | Part 4, Section 2.16.4.3 General formatting | page 1507, line 3 | te | The sentence 'the run that contains the most recently updated field result' makes reference to dynamic behaviors that have no specified meaning in the context of the storage of documents in XML - which are inherently static. | Clarify the explanation using relevant terms. | |
F4118 | Part 4, Section 2.16.5 Field definitions | page 1507, line 30 | te | The description for 'Document Automation' implies that all document automation fields send codes to printers, which is probably untrue. | Clarify the description of the document automation category. | |
F4119 | Part 4, Section 2.16.5 Field definitions | page 1507, line 30 | ed | In the description for 'Document Automation', 'run' does not match 'Compares'. | Replace 'run' by 'runs'. | |
F4120 | Part 4, Section 2.16.5 Field definitions | page 1508, line 0 | te | The description for 'Form Fields' is a tautology. | Clarify the description of 'Form Fields'. | |
F4121 | Part 4, Section 2.16.5 Field definitions | page 1508, line 0 | te | The description for 'Links and References' makes reference to AutoText, which has no generally accepted meaning, and which is not defined in the OOXML text either. | Clarify the description of 'Links and References'. | |
F4122 | Part 4, Section 2.16.5 Field definitions | page 1508, line 0 | te | The second part of the description of 'Numbering' makes no sense. | Clarify the description of 'Numbering'. | |
F4123 | Part 4, Section 2.16.5 Field definitions | page 1508, line 0 | te | The description for 'Index and Tables' implies that all index and tables fields generate multiple tables, which is probably untrue. | Clarify the description of the index and tables category. | |
F4124 | Part 4, Section 2.16.5 Field definitions | page 1508, line 0 | te | The description for 'Mail Merge' is a tautology. | Clarify the description of 'Mail Merge'. | |
F4125 | Part 4, Section 2.16.5 Field definitions | page 1509, line 0 | te | The definition of 'User Information' implies that the document user be known at all times and reflected in the document contents (by magic?), which is obviously not operable. There may be a hidden reference here to a particular user? | Clarify the description of 'User Information'. | |
F4126 | Part 4, Section 2.16.5.1 ADDRESSBLOCK | page 1509, line 6 | te | The definition of 'switches' given here contradicts the one given page 1489 lines 3-5. (Zero or more versus one or more.) | Align definitions. | |
F4127 | Part 4, Section 2.16.5.1 ADDRESSBLOCK | page 1509, line 6 | te | The definition of the \l switch makes two references to 'Language ID', which is an undefined concept. | Define the \l switch properly or remove it. | |
F4128 | Part 4, Section 2.16.5.1 ADDRESSBLOCK | page 1509, line 6 | te | The definition of the \f switch makes no sense at all in the context of the OOXML text. | Define the \f switch properly or remove it. | |
F4129 | Part 4, Section 2.16.5.1 ADDRESSBLOCK | page 1509, line 6 | te | The 'the language ID of the first character of the document' proposition within the '\l' switch definition is meaningless. | Define the \l switch properly or remove it. | |
F4130 | Part 4, Section 2.16.5.1 ADDRESSBLOCK | page 1509, line 6 | te | The definition of the \c switch uses numerical encoding whereas an enumeration would be better. | Consider the use of an enumeration for the possible values of the \c switch. | |
F4131 | Part 4, Section 2.16.5.1 ADDRESSBLOCK | page 1509, line 6 | te | Definitions of \c and \e are inconsistent. More specifically, the definition of \c is broken by the fact that 'the value for \e' is undefined if there are multiple \e instances provided. | Rework definitions for \c, \e or both. | |
F4132 | Part 4, Section 2.16.5.1 ADDRESSBLOCK | page 1509, line 6 | te | The definition of the \d switch refers to undefined behaviors. As such, it brings no value at all. | Define the \d switch properly or remove it. | |
F4133 | Part 4, Section 2.16.5.1 ADDRESSBLOCK | page 1509, lines 4&5 | te | The definition of 'ADDRESSBLOCK' is tautological. Nothing here defines what an address block is, neither what it contains. No reference to a remote definition is provided either. | Define ADDRESSBLOCK properly, either in extenso or by reference, or else remove all references to it from the OOXML text. | |
F4134 | Part 4, Section 2.16.5.2 ADVANCE | page 1509, line 11 | te | There is no way for text to overlap in an XML file, which makes the 'The switches used by this field can cause text to overlap' sentence meaningless. | Remove or rewrite that sentence. | |
F4135 | Part 4, Section 2.16.5.2 ADVANCE | page 1509, line 14 | te | The definition of 'switches' given here contradicts the one given page 1489 lines 3-5. (Zero or more versus one or more.) | Align definitions. | |
F4136 | Part 4, Section 2.16.5.2 ADVANCE | page 1509, lines 10-12 | te | The definition of 'ADVANCE' is tautological. The implicit page rendering model it leverages is not defined. No reference to a remote definition of it is provided either. | Define ADVANCE properly, either in extenso or by reference, or else remove all references to it from the OOXML text. | |
F4137 | Part 4, Section 2.16.5.2 ADVANCE | page 1510, line 0 | te | The \u switch arguments definition refers to 'text in this switch's field-argument' using a font that suggests that 'text' is a structural subpart of 'field-argument', whereas the most plausible intention of the OOXML text is to refer to an integral value denoted by the field-argument. | Clarify the \u switch arguments definition. | |
F4138 | Part 4, Section 2.16.5.2 ADVANCE | page 1510, line 0 | te | The \l switch arguments definition refers to 'text in this switch's field-argument' using a font that suggests that 'text' is a structural subpart of 'field-argument', whereas the most plausible intention of the OOXML text is to refer to an integral value denoted by the field-argument. | Clarify the \l switch arguments definition. | |
F4139 | Part 4, Section 2.16.5.2 ADVANCE | page 1510, line 0 | te | The \y switch arguments definition refers to 'text in this switch's field-argument' using a font that suggests that 'text' is a structural subpart of 'field-argument', whereas the most plausible intention of the OOXML text is to refer to an integral value denoted by the field-argument. | Clarify the \y switch arguments definition. | |
F4140 | Part 4, Section 2.16.5.2 ADVANCE | page 1510, line 0 | te | The \x switch arguments definition refers to 'text in this switch's field-argument' using a font that suggests that 'text' is a structural subpart of 'field-argument', whereas the most plausible intention of the OOXML text is to refer to an integral value denoted by the field-argument. | Clarify the \x switch arguments definition. | |
F4141 | Part 4, Section 2.16.5.2 ADVANCE | page 1510, line 0 | te | The \r switch arguments definition refers to 'text in this switch's field-argument' using a font that suggests that 'text' is a structural subpart of 'field-argument', whereas the most plausible intention of the OOXML text is to refer to an integral value denoted by the field-argument. | Clarify the \r switch arguments definition. | |
F4142 | Part 4, Section 2.16.5.2 ADVANCE | page 1510, line 0 | te | The \d switch arguments definition refers to 'text in this switch's field-argument' using a font that suggests that 'text' is a structural subpart of 'field-argument', whereas the most plausible intention of the OOXML text is to refer to an integral value denoted by the field-argument. | Clarify the \d switch arguments definition. | |
F4143 | Part4, Section 2.16.5.5 AUTONUM | page 1512, lines 11-12 | te | According to the text, the AUTONUM field is deprecated. A new standard should not contain deprecated parts. | Remove all references to AUTONUM from the OOXML text. | |
F4144 | Part4, Section 2.16.5.35 INDEX | page 1539, line 5 | ed | The example for the \h switch is a low-quality image capture, whereas text would be more readable. | Improve the example or remove it. | |
F4145 | Part4, Section 2.16.5.35 INDEX | page 1540, line 0 | ed | The example for the \k switch is a low-quality image capture, whereas text would be more readable. | Improve the example or remove it. | |
F4146 | Part4, Section 2.16.5.40 LISTNUM | page 1543, line 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'. | Expand or reference the definition for 'series', and/or clarify the definition for 'LISTNUM' by any appropriate means. | |
F4147 | Part4, Section 2.16.5.40 LISTNUM | page 1544, line 2 | te | The values given in the table make no sense. Most probably, 'iii' instances stand for 'i' instances. | Specify proper values. | |
F4148 | Part4, Section 2.16.5.40 LISTNUM | page 1544, line 2 | te | The results as displayed in this table contradict the definition of LISTNUM as specified page 1542 line 12 (neither 'a' nor 'iii' are numbers). | Fix the contradiction. | |
F4149 | Part 4, Section 2.18.51 ST_Lang (Language Reference) | page 1747, line 18 | te | The use of an union for the ST_Lang type only brings extra costs and confusion, and should be replaced by a single representation that leverages the appropriate standards. | Remove ST_LangCode and all references to it. | |
F4150 | Part 4, Section 2.18.51 ST_Lang (Language Reference) | page 1747, line 19 | te | OOXML relies upon ISO 639-1 for languages description. ODF 1.0, ISO/IEC 26300:2006 relies upon ISO 639, which is more complete (aka chy) for the same purpose. The use of ISO 3166 only brings a country code, which is not enough to map all existing entries of ISO 639-2 upon ISO 639-1. Moreover, ISO 639-3 was adopted as an ISO standard since 2007-02-05, making an explicit reference to ISO 639-2 problematic. | Replace/complete ISO 639-1 by ISO 639 (as a whole). Would accept two and three letters language codes (instead of two letters code only so far). | |
F4151 | Part 4, Section 3.17.4 Dates and Times | page 2522 | te | The proposed date and time system makes no reference to ISO 8601, and is markedly different from it. This is supported by no explicit and acceptable reason. Introducing brand new conventions where established standards exist is costly and brings no value to the public. Moreover, it brings confusion, and compels application implementors to add converters. | Replace the proposed date and time system by ISO 8601. | |
F4152 | Part 4, Section 3.17.4 Dates and Times | page 2522, lines 6, 7 & 9 | te | There is a contradiction between the definition of dates and times in SpreadsheetML as stated on lines 6&7 and the string representation introduced at line 9. | Clarify the exact format of dates and times. | |
F4153 | Part 4, Section 3.17.4 Dates and Times | page 2522, lines 7&8 | te | The 'As dates and times are numeric 8 values, they can take part in arithmetic operations' sentence is misleading, since arithmetics on dates and times is ill-formed except for very narrow cases (mainly duration, with restrictions though). |
Explain the relationship between dates, times and calendars and warn that dates arithmetics is misleading, or drop the sentence altogether. | |
F4154 | Part 4, Section 3.17.4.1 Date Representation | page 2522, lines 14-18 | te | The text proposes a dual date base system. There is no clear advantage to having two slightly different systems, and this brings significant costs and confusion, as illustrated by the need to specify a default base system, etc. | Choose and keep a single date system. | |
F4155 | Part 4, Section 3.17.4.1 Date Representation | page 2522, lines 16&18 | te | The proposed date system does not cope with dates posterior to 9999-12-31. | Propose a better date system. | |
F4156 | Part 4, Section 3.17.4.1 Date Representation | page 2522, lines 16&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. | Clarify the upper limits. | |
F4157 | Part 4, Section 3.17.4.1 Date Representation | page 2522, lines 19 | te | The proposed date system does not cope with dates anterior to 1900-01-01. | Propose a better date system. | |
F4158 | Part 4, Section 3.17.4.1 Date Representation | page 2523, lines 1-6 | te | The 1900 date base system is bogus, according to the OOXML text itself. A standard should not deliberately include bogus features. | Remove the 1900 date base system or reform it. | |
F4169 | Part 4 | ge | The OOXML text explicitly refuses to elaborate on some behavioral aspects of the conforming applications. For example, it refuses to cover the how and when fields are updated. In contradiction with this, many features cannot be defined without defining more precisely the very same behavioral aspects (for example, the ASK field). There is a tension here that leads us to consider that the text must either provide the appropriate definition of the behavioral context into which it frames behavioral aspects it proposes, or else, more in line with its announced scope, which is static in essence, the said behavioral aspects must be expunged from it. | Define the behavioral context of compliant applications or remove all behavioral aspects from the OOXML text. | ||
F4171 | Part 4, Section 2.3.1.8 cnfStyle (Paragraph Conditional Formatting) | - | 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 almost impossible to work with standard XML tools like XSLT which lack bit-level operations. | Rewrite this subclause to express the feature using XML constructs rather than bitmasks. | |
F4173 | Part 4, Section 2.4.7 cnfStyle (Table Cell Conditional Formatting) | - | te | This element uses a bitmask to specify various table cell formatting properties.. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. | Rewrite this subclause to express the feature using XML constructs rather than bitmasks. | |
F4174 | Part 4, Section 2.4.8 cnfStyle (Table Row Conditional Formatting) | - | te | This element uses a bitmasks to specify various table row formatting properties.. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. | Rewrite this subclause to express the feature using XML constructs rather than bitmasks. | |
F4175 | Part 4, Section 2.4.51 tblLook (Table Style Conditional Formatting Settings) | - | te | This element uses a bitmask to specify various table style formatting properties.. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. | Rewrite this subclause to express the feature using XML constructs rather than bitmasks. | |
F4176 | Part 4, Section 2.4.52 tblLook (Table Style Conditional Formatting Settings Exception) | - | te | This element uses a bitmask to specify various table style formatting exceptions. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. | Rewrite this subclause to express the feature using XML constructs rather than bitmasks. | |
F4177 | Part 4, Section 2.8.2.16 sig (Supported Unicode Subranges and Code Pages) | - | te | This element uses a set of bitmasks to specify which code pages a given font supports. The use of bitmasks rather than an XML Schema derived type makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. One of the advantages of XML is that we don't need to encode data like this any more. | Rewrite this subclause to express the feature using XML constructs rather than bitmasks. | |
F4182 | Part 4, Section 2.15.1.86 stylePaneFormatFilter (Suggested Filtering for List of Document Styles) | - | te | This element uses a bitmask to specify a style display filter. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. | Rewrite this subclause to express the feature using XML constructs rather than bitmasks. | |
F4183 | Part 4, Section 2.15.1.87 stylePaneSortMethod (Suggested Sorting for List of Document Styles) | - | te | This element uses a bitmask to specify style display sorting parameters. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. | Rewrite this subclause to express the feature using XML constructs rather than bitmasks. | |
F4184 | Part 4, Section 2.15.2.32 optimizeForBrowser (Disable Features Not Supported by Target Web Browser) | - | te | This feature has been defined in a way which ignores the existence of current browsers other than Internet Explorer. What about Firefox? What about Safari? What about Opera? None of these can be set as target browsers. This section requires that “all settings which are not compatible with the target web browser shall be disabled.” But what if I want my application to produce standards-compliant output? So yes to PNG, yes to MathML? | Ecma should rethink 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. | |
F4187 | Part 4, Section 2.15.3.54 | - | te | This is the “ uiCompat97To2003” element, which is defined as: “Disable UI functionality that is not compatible with Word97-2003”. But what use is this if I am using OOXML in OpenOffice or WordPerfect Office? What if I want 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? | 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. Such element should part of the future OOOXML Extentions part | |
F4188 | Part 4, Section 2.16.1 Syntax | Page 1489, line 17 | te | 'Latin letters' is rather lax and cannot support the proper definition of a formal language. | Rewrite this rule with a proper definition of its constituents (either by reference or in extenso). | |
F4189 | Part 4, Section 2.16.1 Syntax | page 1489, line 2 | te | We would not expect '” text' or 'text “' to be legit productions for 'field-argument'. Assuming that square brackets denote optional parts in this context, those would be accepted by the provided syntax though. | Clarify whether or not '” text' or 'text “' are legit productions for 'field-argument'. | |
F4190 | Part 4, Section 2.16.5.1 ADDRESSBLOCK | page 1509, line 5 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'ADDRESSBLOCK' must be considered as broken. | Define 'ADDRESSBLOCK' properly or else remove all references to it from the OOXML text. | |
F4191 | Part 4, Section 2.16.5.2 ADVANCE | page 1510, line 10 | te | Considering together 'text that follows the field' and the syntax given line 9, the text being referred to should be the reminder of the document? This does not make much sense, and is not consistent with the examples given page 1510 lines 2&3. The definition of ADVANCE is inconsistent or broken even. | Define ADVANCE properly or else remove all references to it from the OOXML text. | |
F4192 | Part 4, Section 2.16.5.2 ADVANCE | page 1510, line 3 | te | The example is not given in XML. Considering that its extent spans multiple fields (the syntax given pages 1488&1489 gives no means to start a field with a field-argument, which alone could account for the leading XX), it is not a proper OOXML fragment (assuming that a single field could be, for the sake of a short illustrative example, be represented by the proper extract of the value of a w:instrText element). | Propose a proper OOXML example, or remove it. | |
F4193 | Part 4, Section 2.16.5.3 ASK | page 1510, line 14 | te | The 'Prompts the user to enter information' expression explicitly references a runtime behavior, which is out of the documented scope of the OOXML proposition, and not operable as far as a document storage format is concerned. The resulting definition for 'ASK' is broken. | Define 'ASK' properly or else remove all references to it from the OOXML text. | |
F4194 | Part 4, Section 2.16.5.3 ASK | page 1510, line 16 | te | The 'The prompt is displayed each time the ASK field is updated' sentence explicitly places requirements on compliant applications with respect to their dynamic behavior related to field updates, at lest in the case of the 'ASK' field, whereas the text page 1487, line 21 explicitly excludes the how and when of field updates from the specification. | Resolve the contradiction. | |
F4195 | Part 4, Section 2.16.5.3 ASK | page 1510, line 18 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'ASK' must be considered as broken. | Define 'ASK' properly or else remove all references to it from the OOXML text. | |
F4196 | Part 4, Section 2.16.5.3 ASK | page 1510, line 9 | te | The provided syntax is not compatible with the fields syntax given pages 1488&1489. | Fix the contradiction. | |
F4197 | Part 4, Section 2.16.5.3 ASK | page 1510, lines 14 | te | The 'the bookmark designated by field-argument-1' expression refers to concepts that are not defined in the context where it occurs, neither explicitly, nor by reference. | Define the 'the bookmark designated by field-argument-1' expression either in extenso or by reference to a proper definition. | |
F4198 | Part 4, Section 2.16.5.3 ASK | page 1510, lines 15&16 | te | The 'the prompt text, which is displayed in a dialog box' expression explicitly references a runtime behavior, which is out of the documented scope of the OOXML proposition, and not operable as far as a document storage format is concerned. The resulting definition for 'ASK' is broken. | Define 'ASK' properly or else remove all references to it from the OOXML text. | |
F4199 | Part 4, Section 2.16.5.3 ASK | page 1510, lines 16&17 | te | The sentence 'A response remains assigned to the bookmark until a new response is entered' makes no sense at all in the context of an XML storage format. Any text editor or other compliant application could modify any fragment of an OOXML document at any time. The resulting definition for 'ASK' is broken. | Define 'ASK' properly or else remove all references to it from the OOXML text. | |
F4200 | Part 4, Section 2.16.5.4 AUTHOR | page 1511, line 5 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'AUTHOR' must be considered as broken. | Define 'AUTHOR' properly or else remove all references to it from the OOXML text. | |
F4201 | Part 4, Section 2.16.5.5 AUTONUM | page 1512, line 14 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'AUTONUM' must be considered as broken. | Define 'AUTONUM' properly or else remove all references to it from the OOXML text. | |
F4202 | Part 4, Section 2.16.5.6 AUTONUMLGL | page 1513, line 23 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'AUTONUMLGL' must be considered as broken. | Define 'AUTONUMLGL' properly or else remove all references to it from the OOXML text. | |
F4203 | Part 4, Section 2.16.5.7 AUTONUMOUT | page 1514, line 31 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'AUTONUMOUT' must be considered as broken. | Define 'AUTONUMOUT' properly or else remove all references to it from the OOXML text. | |
F4204 | Part 4, Section 2.16.5.8 AUTOTEXT | page 1515, line 13 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'AUTOTEXT' must be considered as broken. | Define 'AUTOTEXT' properly or else remove all references to it from the OOXML text. | |
F4205 | Part 4, Section 2.16.5.9 AUTOTEXTLIST | page 1516, line 1 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'AUTOTEXTLIST' must be considered as broken. | Define 'AUTOTEXTLIST' properly or else remove all references to it from the OOXML text. | |
F4206 | Part 4, Section 2.16.5.10 BARCODE | page 1516, line 16 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'BARCODE' must be considered as broken. | Define 'BARCODE' properly or else remove all references to it from the OOXML text. | |
F4207 | Part 4, Section 2.16.5.11 BIBLIOGRAPHY | page 1517, line 22 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'BIBLIOGRAPHY' must be considered as broken. | Define 'BIBLIOGRAPHY' properly or else remove all references to it from the OOXML text. | |
F4208 | Part 4, Section 2.16.5.12 BIDIOUTLINE | page 1518, line 22 | te | The 'A paragraph number' expression is lax. | Define what the field value, whatever field value may stand for, is in unambiguous terms. | |
F4209 | Part 4, Section 2.16.5.12 BIDIOUTLINE | page 1518, line 22 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'BIDIOUTLINE' must be considered as broken. | Define 'BIDIOUTLINE' properly or else remove all references to it from the OOXML text. | |
F4210 | Part 4, Section 2.16.5.13 CITATION | page 1519, line 5 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'CITATION' must be considered as broken. | Define 'CITATION' properly or else remove all references to it from the OOXML text. | |
F4211 | Part 4, Section 2.16.5.13 CITATION | page 1519, line 6 | te | The use of a singular in 'The following field-specific-switch' suggests that at most one of the switches provided by the table be used, which would be consistent with the rule given line 1. However, the wording of the switches descriptions suggests that more than one switch could be used for the same CITATION field. | Resolve the contradiction. | |
F4212 | Part 4, Section 2.16.5.14 COMMENTS | page 1520, line 9 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'COMMENTS' must be considered as broken. | Define 'COMMENTS' properly or else remove all references to it from the OOXML text. | |
F4213 | Part 4, Section 2.16.5.15 COMPARE | page 1520, line 23 | te | The syntax for 'COMPARE' is not compatible with the syntax of fields as provided on pages 1488&1489. | Resolve the contradiction. | |
F4214 | Part 4, Section 2.16.5.16 CREATEDATE | page 1521, line 28 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'CREATEDATE' must be considered as broken. | Define 'CREATEDATE' properly or else remove all references to it from the OOXML text. | |
F4215 | Part 4, Section 2.16.5.17 DATABASE | page 1522, line 21 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'DATABASE' must be considered as broken. | Define 'DATABASE' properly or else remove all references to it from the OOXML text. | |
F4216 | Part 4, Section 2.16.5.18 DATE | page 1524, line 1 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'DATE' must be considered as broken. | Define 'DATE' properly or else remove all references to it from the OOXML text. | |
F4217 | Part 4, Section 2.16.5.18 DATE | page 1523, line 10 | te | The 'By default, the Gregorian calendar is used' clause is not precise enough. The text should specify which values are retained for switches when none is explicited. | Remove the 'DATE' field from the OOXML text or else provide a proper definition for it. | |
F4218 | Part 4, Section 2.16.5.18 DATE | page 1523, line 10 | te | The 'By default, ... the date-and-time-formatting-switch used is implementation-defined.' clause makes no sense in English. | Remove the 'DATE' field from the OOXML text or else provide a proper definition for it. | |
F4219 | Part 4, Section 2.16.5.18 DATE | page 1523, line 10 | te | The 'Retrieves the current date and time.' clause makes reference to a concept that is not defined in the context of a storage format, and that cannot be defined without making reference to a dynamic model of applications behaviors, which the OOXML text explicitly declines to do. Accordingly, the definition of 'DATE' is broken. | Remove the 'DATE' field from the OOXML text or else provide a proper definition for it. | |
F4220 | Part 4, Section 2.16.5.18 DATE | page 1524, line 2 | te | The description provided for the '\l' switch makes reference to a concept that is not defined in the context of a storage format, and that cannot be defined without making reference to a dynamic model of applications behaviors, which the OOXML text explicitly declines to do. Accordingly, the definition of '\l' is broken. | Remove the '\l' switch or else provide a proper definition for it. | |
F4221 | Part 4, Section 2.16.5.18 DATE | page 1524, line 10 | te | The example fails to recognize that the result given line 10 for the field given line 6 is application dependent, as specified by the definition of DATE (not only locale dependent). | Fix the contradiction. | |
F4222 | Part 4, Section 2.16.5.19 DOCPROPERTY | page 1524, line 20 | te | The syntax for 'DOCPROPERTY' is not compatible with the syntax of fields as provided on pages 1488&1489. | Resolve the contradiction. | |
F4223 | Part 4, Section 2.16.5.19 DOCPROPERTY | page 1526, line 2 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'DOCPROPERTY' must be considered as broken. | Define 'DOCPROPERTY' properly or else remove all references to it from the OOXML text. | |
F4224 | Part 4, Section 2.16.5.20 DOCVARIABLE | page 1526, line 9 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'DOCVARIABLE' must be considered as broken. | Define 'DOCVARIABLE' properly or else remove all references to it from the OOXML text. | |
F4225 | Part 4, Section 2.16.5.21 EDITTIME | page 1526, line 7 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'EDITTIME' must be considered as broken. | Define 'EDITTIME' properly or else remove all references to it from the OOXML text. | |
F4226 | Part 4, Section 2.16.5.22 EQ | page 1527, line 22 | te | The syntax for 'EQ' is not compatible with the syntax of fields as provided on pages 1488&1489 (amongst other issues, 'eq-primary-switch' is neither a terminal nor a non-terminal of the fields syntax). | Resolve the contradiction. | |
F4227 | Part 4, Section 2.16.5.23 FILENAME | page 1531, line 13 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'FILENAME' must be considered as broken. | Define 'FILENAME' properly or else remove all references to it from the OOXML text. | |
F4228 | Part 4, Section 2.16.5.24 FILESIZE | page 1531, line 26 | te | The 'Retrieves' verb explicitly references a runtime behavior, which is out of the documented scope of the OOXML proposition, and not operable as far as a document storage format is concerned. The resulting definition for 'FILESIZE' is broken. | Define 'FILESIZE' properly or else remove all references to it from the OOXML text. | |
F4229 | Part 4, Section 2.16.5.24 FILESIZE | page 1531, line 26&27 | te | According to Part 1, page 7, line 1, an OOXML document is (either a stream or) a ZIP file. ZIP files are assumed to be smaller than the files they compress, especially when the latter contain text. The very meaning of FILESIZE in this context remains unclear. (Flatly: how does FILESIZE cope with compression?) | Define 'FILESIZE' unambiguously or else remove all references to it from the OOXML text. | |
F4230 | Part 4, Section 2.16.5.24 FILESIZE | page 1531, line 27 | te | This line contradicts the provisions taken in Part 1, page 7, line 2 for streams, in that it explicitly, and only, refers to file systems. The very meaning of FILESIZE in case of a document coming from a data stream remains unclear. | Resolve the contradiction. Define 'FILESIZE' properly or else remove all references to it from the OOXML text. | |
F4231 | Part 4, Section 2.16.5.24 FILESIZE | page 1531, line 28 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'FILESIZE' must be considered as broken. | Define 'FILESIZE' properly or else remove all references to it from the OOXML text. | |
F4232 | Part 4, Section 2.16.5.25 FILLIN | page 1532, line 19 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'FILLIN' must be considered as broken. | Define 'FILLIN' properly or else remove all references to it from the OOXML text. | |
F4233 | Part 4, Section 2.16.5.26 FORMCHECKBOX | page 1533, line 9 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'FORMCHECKBOX' must be considered as broken. | Define 'FORMCHECKBOX' properly or else remove all references to it from the OOXML text. | |
F4234 | Part 4, Section 2.16.5.27 FORMDROPDOWN | page 1533, line 21 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'FORMDROPDOWN' must be considered as broken. | Define 'FORMDROPDOWN' properly or else remove all references to it from the OOXML text. | |
F4235 | Part 4, Section 2.16.5.28 FORMTEXT | page 1534, line 5 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'FORMTEXT' must be considered as broken. | Define 'FORMTEXT' properly or else remove all references to it from the OOXML text. | |
F4236 | Part 4, Section 2.16.5.29 GOTOBUTTON | page 1534, line 13 | te | The provided syntax is not compatible with the fields syntax given pages 1488&1489. | Fix the contradiction. | |
F4237 | Part 4, Section 2.16.5.29 GOTOBUTTON | page 1535, line 1 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'GOTOBUTTON' must be considered as broken. | Define 'GOTOBUTTON' properly or else remove all references to it from the OOXML text. | |
F4238 | Part 4, Section 2.16.5.30 GREETINGLINE | page 1535, line 16 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'GREETINGLINE' must be considered as broken. | Define 'GREETINGLINE' properly or else remove all references to it from the OOXML text. | |
F4239 | Part 4, Section 2.16.5.31 HYPERLINK | page 1535, line 23 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'HYPERLINK' must be considered as broken. | Define 'HYPERLINK' properly or else remove all references to it from the OOXML text. | |
F4240 | Part 4, Section 2.16.5.32 IF | page 1536, line 6 | te | The syntax for 'IF' is not compatible with the syntax of fields as provided on pages 1488&1489. | Resolve the contradiction. | |
F4241 | Part 4, Section 2.16.5.32 IF | page 1537, line 1 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'IF' must be considered as broken. | Define 'IF' properly or else remove all references to it from the OOXML text. | |
F4242 | Part 4, Section 2.16.5.33 INCLUDEPICTURE | - | te | This does not define how a picture is named. Is it by a URI? By a local file system path? Either? The example given has a DOS file path, a construct which is not portable. | Define how pictures are named. | |
F4243 | Part 4, Section 2.16.5.33 INCLUDEPICTURE | - | 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. | There should be specified at least a small set of interoperable formats. | |
F4244 | Part 4, Section 2.16.5.33 INCLUDEPICTURE | - | 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? | Define what is to be done with the picture once it is retrieved. | |
F4245 | Part 4, Section 2.16.5.33 INCLUDEPICTURE | page 1537, line 15 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'INCLUDEPICTURE' must be considered as broken. | Define 'INCLUDEPICTURE' properly or else remove all references to it from the OOXML text. | |
F4246 | Part 4, Section 2.16.5.34 INCLUDETEXT | - | 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. | There should be specified at least a small set of interoperable formats. | |
F4247 | Part 4, Section 2.16.5.34 INCLUDETEXT | - | te | This does not define how a document is named. Is it by a URI? By a local file system path? Either? The example given has a DOS file path, a construct which is not portable. | Define how documents are named. | |
F4248 | Part 4, Section 2.16.5.34 INCLUDETEXT | - | te | The \t flag will apply a named XSLT transform to the input XML file and insert the resulting output. However, no proper reference is given to XSLT, so we do not know what version XSLT transform is permitted here. | Provide a proper external normative reference for the XSLT which is allowed here. | |
F4249 | Part 4, Section 2.16.5.34 INCLUDETEXT | page 1537, line 23 | te | The syntax for 'INCLUDETEXT' is not compatible with the syntax of fields as provided on pages 1488&1489. | Resolve the contradiction. | |
F4250 | Part 4, Section 2.16.5.34 INCLUDETEXT | page 1538, line 8 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'INCLUDETEXT' must be considered as broken. | Define 'INCLUDETEXT' properly or else remove all references to it from the OOXML text. | |
F4251 | Part 4, Section 2.16.5.35 INDEX | page 1539, line 4 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'INDEX' must be considered as broken. | Define 'INDEX' properly or else remove all references to it from the OOXML text. | |
F4252 | Part 4, Section 2.16.5.36 INFO | page 1541, line 7 | te | The syntax for 'INFO' is not compatible with the syntax of fields as provided on pages 1488&1489 (amongst other issues, 'info-category' is neither a terminal nor a non-terminal of the fields syntax). | Resolve the contradiction. | |
F4253 | Part 4, Section 2.16.5.36 INFO | page 1541, line 12 | te | According to 'A field of this kind is treated as if INFO was omitted and info-category was a field-type name.', this field brings no value to the proposal (its being present or not bears no influence on the document semantics, presentation or any other use of it). | Remove the 'INFO' field. | |
F4254 | Part 4, Section 2.16.5.37 KEYWORDS | page 1541, line 20 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'KEYWORDS' must be considered as broken. | Define 'KEYWORDS' properly or else remove all references to it from the OOXML text. | |
F4255 | Part 4, Section 2.16.5.38 LASTSAVEDBY | page 1542, line 7 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'LASTSAVEDBY' must be considered as broken. | Define 'LASTSAVEDBY' properly or else remove all references to it from the OOXML text. | |
F4256 | Part 4, Section 2.16.5.39 LINK | page 1542, line 19 | te | The syntax for 'LINK' is not compatible with the syntax of fields as provided on pages 1488&1489. | Resolve the contradiction. | |
F4257 | Part 4, Section 2.16.5.39 LINK | page 1542, line 31 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'LINK' must be considered as broken. | Define 'LINK' properly or else remove all references to it from the OOXML text. | |
F4258 | Part 4, Section 2.16.5.40 LISTNUM | page 1544, line 4 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'LISTNUM' must be considered as broken. | Define 'LISTNUM' properly or else remove all references to it from the OOXML text. | |
F4259 | Part 4, Section 2.16.5.41 MACROBUTTON | page 1545, line 23 | te | The syntax for 'MACROBUTTON' is not compatible with the syntax of fields as provided on pages 1488&1489. | Resolve the contradiction. | |
F4260 | Part 4, Section 2.16.5.41 MACROBUTTON | page 1545, line 31 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'MACROBUTTON' must be considered as broken. | Define 'MACROBUTTON' properly or else remove all references to it from the OOXML text. | |
F4261 | Part 4, Section 2.16.5.42 MERGEFIELD | page 1546, line 5 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'MERGEFIELD' must be considered as broken. | Define 'MERGEFIELD' properly or else remove all references to it from the OOXML text. | |
F4262 | Part 4, Section 2.16.5.43 MERGEREC | page 1546, line 16 | ed | The 'MERGEREC' word is printed in italics, whereas most other field names in syntax sections are not. | Apply a consistent font style. | |
F4263 | Part 4, Section 2.16.5.43 MERGEREC | page 1546, line 17 | te | The 'Description: Results in «MERGEREC».' sentence is meaningless or tautological in this context. | Clarify the description of 'MERGEREC'. | |
F4264 | Part 4, Section 2.16.5.43 MERGEREC | page 25, line | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'MERGEREC' must be considered as broken. | Define 'MERGEREC' properly or else remove all references to it from the OOXML text. | |
F4265 | Part 4, Section 2.16.5.44 MERGESEQ | page 1547, line 15 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'MERGESEQ' must be considered as broken. | Define 'MERGESEQ' properly or else remove all references to it from the OOXML text. | |
F4266 | Part 4, Section 2.16.5.45 NEXT | page 1547, line 25 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'NEXT' must be considered as broken. | Define 'NEXT' properly or else remove all references to it from the OOXML text. | |
F4267 | Part 4, Section 2.16.5.46 NEXTIF | page 1548, line 17 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'NEXTIF' must be considered as broken. | Define 'NEXTIF' properly or else remove all references to it from the OOXML text. | |
F4268 | Part 4, Section 2.16.5.46 NEXTIF | page 1548, line 4 | te | The syntax for 'NEXTIF' is not compatible with the syntax of fields as provided on pages 1488&1489. | Resolve the contradiction. | |
F4269 | Part 4, Section 2.16.5.47 NOTEREF | page 1548, line 24 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'NOTEREF' must be considered as broken. | Define 'NOTEREF' properly or else remove all references to it from the OOXML text. | |
F4270 | Part 4, Section 2.16.5.48 NUMCHARS | page 1549, line 11 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'NUMCHARS' must be considered as broken. | Define 'NUMCHARS' properly or else remove all references to it from the OOXML text. | |
F4271 | Part 4, Section 2.16.5.49 NUMPAGES | page 1549, line 25 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'NUMPAGES' must be considered as broken. | Define 'NUMPAGES' properly or else remove all references to it from the OOXML text. | |
F4272 | Part 4, Section 2.16.5.50 NUMWORDS | page 1550, line 10 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'NUMWORDS' must be considered as broken. | Define 'NUMWORDS' properly or else remove all references to it from the OOXML text. | |
F4273 | Part 4, Section 2.16.5.51 PAGE | page 1550, line 23 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'PAGE' must be considered as broken. | Define 'PAGE' properly or else remove all references to it from the OOXML text. | |
F4274 | Part 4, Section 2.16.5.52 PAGEREF | page 1551, line 12 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'PAGEREF' must be considered as broken. | Define 'PAGEREF' properly or else remove all references to it from the OOXML text. | |
F4275 | Part 4, Section 2.16.5.53 PRINT | page 1552, line 4 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'PRINT' must be considered as broken. | Define 'PRINT' properly or else remove all references to it from the OOXML text. | |
F4276 | Part 4, Section 2.16.5.54 PRINTDATE | page 1552, line 13 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'PRINTDATE' must be considered as broken. | Define 'PRINTDATE' properly or else remove all references to it from the OOXML text. | |
F4277 | Part 4, Section 2.16.5.55 PRIVATE | page 1553, line 14 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'PRIVATE' must be considered as broken. | Define 'PRIVATE' properly or else remove all references to it from the OOXML text. | |
F4278 | Part 4, Section 2.16.5.56 QUOTE | page 1553, line 21 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'QUOTE' must be considered as broken. | Define 'QUOTE' properly or else remove all references to it from the OOXML text. | |
F4279 | Part 4, Section 2.16.5.57 RD | page 1554, line 10 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'RD' must be considered as broken. | Define 'RD' properly or else remove all references to it from the OOXML text. | |
F4280 | Part 4, Section 2.16.5.58 REF | page 1554, line 21 | te | The syntax for 'REF' is not compatible with the syntax of fields as provided on pages 1488&1489. | Resolve the contradiction. | |
F4281 | Part 4, Section 2.16.5.58 REF | page 1554, line 26 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'REF' must be considered as broken. | Define 'REF' properly or else remove all references to it from the OOXML text. | |
F4282 | Part 4, Section 2.16.5.59 REVNUM | page 1555, line 11 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'REVNUM' must be considered as broken. | Define 'REVNUM' properly or else remove all references to it from the OOXML text. | |
F4283 | Part 4, Section 2.16.5.60 SAVEDATE | page 1556, line 13 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'SAVEDATE' must be considered as broken. | Define 'SAVEDATE' properly or else remove all references to it from the OOXML text. | |
F4284 | Part 4, Section 2.16.5.61 SECTION | page 1557, line 5 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'SECTION' must be considered as broken. | Define 'SECTION' properly or else remove all references to it from the OOXML text. | |
F4285 | Part 4, Section 2.16.5.62 SECTIONPAGES | page 1557, line 22 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'SECTIONPAGES' must be considered as broken. | Define 'SECTIONPAGES' properly or else remove all references to it from the OOXML text. | |
F4286 | Part 4, Section 2.16.5.63 SEQ | page 1558, line 21 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'SEQ' must be considered as broken. | Define 'SEQ' properly or else remove all references to it from the OOXML text. | |
F4287 | Part 4, Section 2.16.5.63 SEQ | page 1558, line 8 | te | The syntax for 'SEQ' is not compatible with the syntax of fields as provided on pages 1488&1489 ('identifier' is neither a terminal nor a non-terminal of the fields syntax). | Resolve the contradiction. | |
F4288 | Part 4, Section 2.16.5.64 SET | page 1559, line 22 | te | The syntax for 'SET' is not compatible with the syntax of fields as provided on pages 1488&1489. | Resolve the contradiction. | |
F4289 | Part 4, Section 2.16.5.64 SET | page 1559, line 29 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'SET' must be considered as broken. | Define 'SET' properly or else remove all references to it from the OOXML text. | |
F4290 | Part 4, Section 2.16.5.65 SKIPIF | page 1560, line 18 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'SKIPIF' must be considered as broken. | Define 'SKIPIF' properly or else remove all references to it from the OOXML text. | |
F4291 | Part 4, Section 2.16.5.65 SKIPIF | page 1560, line 8 | te | The syntax for 'SKIPIF' is not compatible with the syntax of fields as provided on pages 1488&1489. | Resolve the contradiction. | |
F4292 | Part 4, Section 2.16.5.65 SKIPIF | page 1560, lines 6&8 | te | The description of 'SKIPIF' is inconsistent with itself ('SKIPIF' vs 'SKIP'). | Resolve the contradiction. | |
F4293 | Part 4, Section 2.16.5.66 STYLEREF | page 1561, line 13 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'STYLEREF' must be considered as broken. | Define 'STYLEREF' properly or else remove all references to it from the OOXML text. | |
F4294 | Part 4, Section 2.16.5.67 SUBJECT | page 1562, line 7 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'SUBJECT' must be considered as broken. | Define 'SUBJECT' properly or else remove all references to it from the OOXML text. | |
F4295 | Part 4, Section 2.16.5.68 SYMBOL | page 1562, line 26 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'SYMBOL' must be considered as broken. | Define 'SYMBOL' properly or else remove all references to it from the OOXML text. | |
F4296 | Part 4, Section 2.16.5.69 TA | page 1563, line 24 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'TA' must be considered as broken. | Define 'TA' properly or else remove all references to it from the OOXML text. | |
F4297 | Part 4, Section 2.16.5.70 TC | page 1564, line 17 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'TC' must be considered as broken. | Define 'TC' properly or else remove all references to it from the OOXML text. | |
F4298 | Part 4, Section 2.16.5.71 TEMPLATE | page 1565, line 4 | te | The 'Retrieves' verb explicitly references a runtime behavior, which is out of the documented scope of the OOXML proposition, and not operable as far as a document storage format is concerned. The resulting definition for 'TEMPLATE' is broken. | Define 'TEMPLATE' properly or else remove all references to it from the OOXML text. | |
F4299 | Part 4, Section 2.16.5.71 TEMPLATE | page 1565, line 4 | te | The 'the disk file name of the template used by the current document' sentence makes no sense in the context of the OOXML text. The resulting definition for 'TEMPLATE' is broken. | Define 'TEMPLATE' properly or else remove all references to it from the OOXML text. | |
F4300 | Part 4, Section 2.16.5.71 TEMPLATE | page 1565, line 5 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'TEMPLATE' must be considered as broken. | Define 'TEMPLATE' properly or else remove all references to it from the OOXML text. | |
F4301 | Part 4, Section 2.16.5.72 TIME | page 1565, line 18 | te | The 'Retrieves' verb explicitly references a runtime behavior, which is out of the documented scope of the OOXML proposition, and not operable as far as a document storage format is concerned. The resulting definition for 'TIME' is broken. | Define 'TIME' properly or else remove all references to it from the OOXML text. | |
F4302 | Part 4, Section 2.16.5.72 TIME | page 1565, line 18 | te | The 'The Gregorian calendar is always used' sentence is too vague. | Provide a proper reference to the calendar standard used. | |
F4303 | Part 4, Section 2.16.5.72 TIME | page 1565, line 18&19 | te | The 'By default, the date-and-time-formatting-switch used is implementation-defined.' makes no sense in English. | Define 'TIME' properly or else remove all references to it from the OOXML text. | |
F4304 | Part 4, Section 2.16.5.72 TIME | page 1565, line 20 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'TIME' must be considered as broken. | Define 'TIME' properly or else remove all references to it from the OOXML text. | |
F4305 | Part 4, Section 2.16.5.73 TITLE | page 1566, line 17 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'TITLE' must be considered as broken. | Define 'TITLE' properly or else remove all references to it from the OOXML text. | |
F4306 | Part 4, Section 2.16.5.74 TOA | page 1567, line 9 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'TOA' must be considered as broken. | Define 'TOA' properly or else remove all references to it from the OOXML text. | |
F4307 | Part 4, Section 2.16.5.75 TOC | page 1568, line 8 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'TOC' must be considered as broken. | Define 'TOC' properly or else remove all references to it from the OOXML text. | |
F4308 | Part 4, Section 2.16.5.76 USERADDRESS | page 1570, line 6 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'USERADDRESS' must be considered as broken. | Define 'USERADDRESS' properly or else remove all references to it from the OOXML text. | |
F4309 | Part 4, Section 2.16.5.77 USERINITIALS | - | ed | The example that illustrates USERINITIALS section instead shows USERNAME. | Correct the example. | |
F4310 | Part 4, Section 2.16.5.77 USERINITIALS | page 1570, line 24 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'USERINITIALS' must be considered as broken. | Define 'USERINITIALS' properly or else remove all references to it from the OOXML text. | |
F4311 | Part 4, Section 2.16.5.78 USERNAME | page 1571, line 10 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'USERNAME' must be considered as broken. | Define 'USERNAME' properly or else remove all references to it from the OOXML text. | |
F4312 | Part 4, Section 2.16.5.79 XE | page 1571, line 28 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'XE' must be considered as broken. | Define 'XE' properly or else remove all references to it from the OOXML text. | |
F4313 | Part 4, Section 2.18.4 ST_Border (Border Styles) | - | te | No mechanism for expanding the set of art borders is provided. Since the specified art borders are heavily Western-oriented, it would be good to provide a way for an application to supplement these styles with graphics that provide more regional flavor. | Provide an interoperable extensibility mechanism for a document author or application to specify their own art border graphics. | |
F4314 | Part 4, Section 2.18.4 ST_Border (Border Styles) | - | te | The artwork provided here is of poor quality providing neither intended scale, spacing, color depth, etc. A small example diagram is an insufficient definition. For example, are the dimensions of the borders absolute? Or do they scale with page size? Also, some of the images, such as 'apples' or 'balloons3Colors' show copying artifacts, where extraneous lines or blotches appear. | Provide 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. | |
F4315 | Part 4, Section 2.18.45 ST_HexColorRGB (Hexadecimal Color Value) | - | te | Length is said to be “exactly 3 characters”. This is inconsistent with the example given which has a length of 6 characters. | Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters. | |
F4316 | Part 4, Section 2.18.51 | line 22 | ed | double quotes used incorrectly, with two sets of close quotes. | XML examples should be given using straight quotes | |
F4317 | Part 4, Section 2.18.52 ST_LangCode (Two Digit Hexadecimal Language Code) | - | 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. | Reconcile the description of the type with the enumerated values. | |
F4318 | Part 4, Section 2.18.57 ST_LongHexNumber (Four Digit Hexadecimal Number Value) | - | te | 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. | Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters. | |
F4319 | Part 4, Section 2.18.66 ST_NumberFormat (Numbering Format) | - | te | There is nothing in this section which is normatively defined except some enumeration values. No normative meanings to these values are given. An informative example is insufficient in all but the most trivial cases. For example, where is “Korean Legal Counting System” defined? | Give explicit definitions of these numbering styles or proper external normative references. | |
F4320 | Part 4, Section 2.18.66 ST_NumberFormat (Numbering Format) | - | 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. | Use a more flexible, extensible, generative approach to numeration, such as that used by the W3C's XSLT standard in their xsl:number support | |
F4321 | Part 4, Section 2.18.66 ST_NumberFormat (Numbering Format) | “chicago” | te | Format is defined in reference to the “Chicago Manual of Style”, but no edition or page reference is provided. | Either include the entire definition in the standard, or provide a proper external reference. | |
F4322 | Part 4, Section 2.18.66 ST_NumberFormat (Numbering Format) | “decimalEnclosedFullstop” | te | The example given does not show enclosed characters and so contradicts the normative text. | Reconcile the text and the example. | |
F4323 | Part 4, Section 2.18.66 ST_NumberFormat (Numbering Format) | “lowerLetter”, etc. | 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. | Clarify the text to explicitly cover this case. | |
F4324 | Part 4, Section 2.18.66 ST_NumberFormat (Numbering Format) | “numberInDash”, etc. | te | Format requires use of “dash” to surround the number, but no indication of which Unicode dash is intended, en-dash, em-dash, hyphen-minus, figure-dash, quotation-dash, etc. | Specify the intended dash explicitly. | |
F4325 | Part 4, Section 2.18.72 ST_Panose (Panose-1 Number) | - | te | No definition is provided for a “Panose-1 classification” of a font. | Provide a proper external normative reference for this term. | |
F4326 | Part 4, Section 2.18.72 ST_Panose (Panose-1 Number) | - | te | Length is said to be “exactly 10 characters”. This is inconsistent with the example given which has a length of 20 characters. | Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters. | |
F4327 | Part 4, Section 2.18.72 ST_Panose (Panose-1 Number) | page 1786, line 10 | te | The 'the Panose-1
classification number a font' clause does not make sense in English. |
Rephrase. | |
F4328 | Part 4, Section 2.18.85 ST_Shd (Shading Patterns) | - | 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? | Provide full normative definitions for these graphical elements. | |
F4329 | Part 4, Section 2.18.86 ST_ShortHexNumber (Two Digit Hexadecimal Number Value) | - | 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. | Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters. | |
F4330 | Part 4, Section 2.18.106 ST_UcharHexNumber (Two Digit Hexadecimal Number Value) | - | te | Length is said to be “exactly 1 character”. This is inconsistent with the earlier language and the schema fragment given which defines it as being 1 octet long or two characters. | Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters. | |
F4331 | Part 4, Section 3.2.29 workbookProtection (Workbook Protection) | - | 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. | Use a standard, FIPS-180 compliant hash algorithm as the default. Legacy hash algorithms should be supported via the described extension mechanism. | ||
F4332 | Part 4, Section 3.2.29 workbookProtection (Workbook Protection) | p. 1917-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. | 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. | |
F4333 | Part 4, Section 3.2.29 workbookProtection (Workbook Protection) | pg. 1916 | 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? | Clarify this processing, especially for passwords that use characters from more than one script. | |
F4334 | Part 4, Section 3.2.29 workbookProtection (Workbook Protection) | pg. 1916 | te | This seems to imply that if a password is entered in a script like Armenian or Ethiopic then the characters will be replaced all by a single character 0x3F, making the protection feature useless. This is unacceptable. | Remedy so password hashes can be calculated on any Unicode password. | |
F4335 | Part 4, Section 3.2.29 workbookProtection (Workbook Protection) | pg. 1916 | 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. | 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. | |
F4336 | Part 4, Section 3.3.1.61 pageSetup (Page Setup Settings) | - | te | The pageSize attribute allows a set of enumerated values which does not encompass all of the page size values permitted by ISO 216, ANSI Y14.1 and similar DIN and JIS standards. | Rather than trying to maintain a paper size registry, a more flexible approach would be to simply record the dimensions of the paper size selected. | |
F4337 | Part 4, Section 3.3.1.69 protectedRange (Protected Range) | - | 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. | 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. | |
F4338 | Part 4, Section 3.3.1.69 protectedRange (Protected Range) | - | 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. | Use a standard, FIPS-180 compliant hash algorithm as the default. Legacy hash algorithms should be supported via the described extension mechanism. | |
F4339 | Part 4, Section 3.3.1.69 protectedRange (Protected Range) | - | te | The securityDescriptor attribute, “definesuser accounts who may edit this range without providing a password to access the range”. It is a string. But no information is given as to what user accounts are referred to here, or what the delimiter is. Are these comma-delimited local machine user accounts? Or semi-colon delimited LDAP DN's? There will be no interoperability if this is not defined. | Fully define this attribute. | |
F4340 | Part 4, Section 3.10 Pivot Tables | page 2236, line 1 | ed | The provided diagram is blurred. | Replace with a clean diagram or remove it. | |
F4341 | Part 4, Section 2.16.5.2 ADVANCE | page 1509, line 13 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'ADVANCE' must be considered as broken. | Define 'ADVANCE' properly or else remove all references to it from the OOXML text. | |
F4342 | Part 4, Section 2.16.5.15 COMPARE | page 1521, line 9 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'COMPARE' must be considered as broken. | Define 'COMPARE' properly or else remove all references to it from the OOXML text. | |
F4343 | Part 4, Section 2.16.5.22 EQ | page 1527, line 27 | te | The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'EQ' must be considered as broken. | Define 'EQ' properly or else remove all references to it from the OOXML text. | |
F4344 | Part 4, Section 3.17.4.1 Date Representation | - | 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. | Allow a range of vendor-declared date bases, or explicitly allow negative date serial values to express dates prior to 1900 | |
F4345 | Part 4, Section 3.17.7.341 WEEKDAY | - | 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. | Remove the text that defines behavior that results in incorrect date calculations. | |
F4346 | Part 4, Section 3.17.7.343 WEIBULL | page 2820, line 15, and page 2821, lines 1&3 | ed | The provided equations are blurred, to the point of being almost unreadable. | Provide clean equations. | |
F4347 | Part 4, Section 3.18.86 ST_UnsignedIntHex (Hex Unsigned Integer) | - | 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. | Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters. | |
F4348 | Part 4, Section 3.18.87 ST_UnsignedShortHex (Unsigned Short Hex) | - | 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. | Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters. | |
F4349 | Part 4, Section 4.6.3 animEffect (Animate Effect) | page 3075, line 6 | ed | The description of 'transition' makes an inconsistent use of double-quotes for values ('in' vs '”in”', 'out' vs '”out”'). | Elect and apply a consistent rule for the use of double-quotes for values. | |
F4350 | Part 4, Section 5.1.3.2 audioFile (Audio from File) | - | te | No mention is made of what audio formats or codecs are permitted. | An interoperable set of formats should be specified. | |
F4351 | Part 4, Section 5.1.3.4 quickTimeFile (QuickTime from File) | - | te | This describes the attachment of a QuickTime video to a presentation object. No description of the QuickTime format is provided. Without specifying a version and supported codecs, there will be no interoperability. | Provide an external reference for the version(s) of QuickTime format intended here as well as an interoperable codec. | |
F4352 | Part 4, Section 5.1.12.28 ST_HexBinary3 (Hex Binary of Length 3) | - | 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 latter type should be used instead. | Use the ST_HexColorRGB type and remove ST_HexBinary3 | |
F4353 | Part 4, Section 5.1.12.28 ST_HexBinary3 (Hex Binary of Length 3) | - | 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. | Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters. | |
F4354 | Part 4, Section 5.1.12.37 ST_Panose (Panose Type) | - | te | No definition is provided for a “Panose setting of a font”. | Provide a proper external normative reference for this term. | |
F4355 | Part 4, Section 5.1.12.37 ST_Panose (Panose Type) | - | 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. | Describe the intended font matching procedure. | |
F4356 | Part 4, Section 5.1.12.37 ST_Panose (Panose Type) | - | 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. | Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters. | |
F4357 | Part 4, Section 5.1.12.37 ST_Panose (Panose Type) | - | ge | Why are there several different definitions for a Panose value, both in Word Processing ML as well as Drawing ML? | Since they are exactly the same they should be defined once in a shared schema. | |
F4358 | Part 4, Section 6.1.2.1 arc (Arc Segment) | page 4352, line 0 | te | According to the text itself, 'dgmlayout' attributes are not meaningful for 'arc' elements. If this is the case (which is common sense), then the 'dgmlayout' attribute should never be used for 'arc' elements. | Forbid the use of 'dgmlayout' attributes for 'arc' elements. | |
F4359 | Part 4, Section 6.1.2.1 arc (Arc Segment) | page 4352, line 0 | ed | According to the text itself, 'dgmlayout' attributes are not meaningful for 'arc' elements, but it is still described by heavyweight drawings and text. | Suppress unneeded clutter from the example. | |
F4360 | Part 4, Section 6.1.2.1 arc (Arc Segment) | page 4353, line 0 | te | The description of the 'dgmlayout' attribute contradict itself, stating that 'The possible values for this attribute are defined by the XML Schema integer datatype', while the preceeding description only assigns meanings to the 0, 1, 2 and 3 values. | Resolve the contradiction. | |
F4361 | Part 4, Section 6.1.2.1 arc (Arc Segment) | page 4353, line 0 | te | The description of the 'dgmlayout' attribute leverages a small set of integer coded values, whereas an enumeration would better reflect the functionality. | Use an enumeration to define the values of the 'dgmlayout' attribute. | |
F4362 | Part 4, Section 6.1.2.1 arc (Arc Segment) | page 4362, line 0 | te | The description of the 'style' attribute merely states that it 'uses the syntax described in [an external document]'. Either the syntax is defined by the said external document, or else the OOXML text must define it by itself. | Define properly, in extenso or by reference to a standard, the 'style' attribute. | |
F4363 | Part 4, Section 6.1.2.7 group (Shape Group) | page 4444, “tableproperties” | te | This element uses a bitmask to specify VML table properties. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. | Rewrite this subclause to express the feature using XML constructs rather than bitmasks. | |
F4364 | Part 4, Section 6.1.2.19 shape (Shape Definition) | pg. 4653 “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. | Define equations in an interoperable way. | |
F4365 | Part 4, Section 6.1.2.19 shape (Shape Definition) | pg. 4655, “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. | Define this in an interoperable way. | |
F4366 | Part 4, Section 6.2.2.14 ink (Ink) | - | 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. | Specify the “ink” format or remove the element from OOXML and make this an application extension using the extensibility mechanisms of OOXML. | |
F4367 | Part 4, Section 6.4.2.10 CF (Clipboard Format) | - | te | This element is defined as providing a, “general-use element for objects that use an image representation, such as OLE objects, embedded controls, cameras and signature lines.” However, the allowed values, EMF, WMF, etc., refer to formats for which no reference has been given. | Provide a proper external normative reference for the allowed formats containable within this element. Such reference should be part of the future OOXML Extention part | |
F4368 | Part 4, Section 6.4.3.1 ST_CF (Clipboard Format Type) | - | 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. | Several options here, but the desire is to allow cross platform interoperability. Such refernce should be part of the future OOXML Extention part | |
F4369 | Part 4, Section 7.1 Math | - | 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. | It is recommended that this section be removed from OOXML and that the proposers of OOXML work within the W3C's MathML activity, where MathML 3.0 is currently being drafted, to produce a single standard for equations that can be used later referenced by a future version of OOXML. To be taken into consideration during the convergence process proposed. | |
F4370 | Part 4, Section 7.4.2.4 bstr (Basic String) | - | te | This defines a new XML string type which allows the inclusion via an escape mechanism of Unicode characters which are otherwise impermissible in XML documents. However, any escape mechanism must also specify a mechanism for “escaping the escape”. So, how does one represent the literal example given in 7.4.2.4 in a bstr? | Complete the definition of the escape mechanism. | |
F4371 | Part 4, Section 7.4.2.4 bstr (Basic String) | - | 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.” | Remove the bstr type from OOXML | |
F4372 | Part 4, Section 7.4.2.5 cf (Clipboard Data) | - | 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. | Specify this so interoperability may be achieved. | |
F4373 | Part 4, Section 7.4.2.5 cf (Clipboard Data) | - | te | This element defines values for use on Windows and Macintosh platforms, but not for Linux or any other operating system. | Several options here, but the desire is to allow cross platform interoperability. | |
F4374 | Part 4, Section 7.4.2.5 cf (Clipboard Data) | - | 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”? | Specify this so interoperability may be achieved. | |
F4375 | Part 4, Section 7.4.2.5 cf (Clipboard Data) | - | 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. | Ecma 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 should be rewritten to express this feature in an application and platform neutral way. | |
F4376 | Part 4, Annex C. Additional Syntax Constraints | page 5205, line 3 | te | The 'the set of XML Schemas included in Annex A' sentence is abusive. Annex A merely references material, it includes none. The verbiage of this section touts that the constraints that bear upon what the OOXML text would consider as valid XML documents are defined by the OOXML text, which they are not. | Define properly, in extenso or by reference to a standard, the constraints that must be applied to an XML document to determine whether or not it is compliant with the proposed OOXML standard. | |
F4377 | Part 4, Annex C. Additional Syntax Constraints | page 5205, line 5&6 | te | The 'These additional constraints can be deduced from the normative content of this Part' proposition falls short of what is expected from a standard. Either the OOXML text defines the constraints and they can be read from it, or else the OOXML text does not define the constraints (and the reader has to 'deduce' them from the text, which would be unacceptable). The verbiage of this section touts that the constraints that bear upon what the OOXML text would consider as valid XML documents are defined by the OOXML text, which they are not. | Define properly, in extenso or by reference to a standard, the constraints that must be applied to an XML document to determine whether or not it is compliant with the proposed OOXML standard. | |
F4378 | Part 4, Section 2.18.67 ST_OnOff (On/Off Value) | page 1779, line 13 | te | The ST_OnOff simple types brings no clear value over the boolean type and has significant drawbacks: clutter in the text, awkward leverage in XSLT applications, lack of canonical literal values. | Use the boolean type instead (with needed changes at calling places). | |
F4379 | Part 4, Section 3 SpreadsheetML Reference Material | - | te | According to XML Schema Part 2: Datatypes
Second Edition W3C Recommendation 28 October 2004, section 3.2.2.1, the boolean data type can hold the literal values 0, 1, false or true. This excludes the on and off values. Many attributes definitions in Section 3 (more than 100) stipulate that they can take literal values 0, 1, false, true, off or on, and that they are of XML Schema boolean type. We contend that those definitions are broken and should be fixed. A concrete example of those is the autoLayout attribute of the customWorkbookView element, Section 3.2.3. It could be that the XML Schema used for those definitions referred to another specification, in which case the text should tell which. As far a our search could clarify the situation, Part 1 refers the specification above in the bibliography (while marking this as informative) and Part 4 gives no explicit reference to what could constitute the specification for XML Schema. Last but not least, it may be that other parts of the OOXML than Part 4 Section 3 suffer the same deficiency and must be fixed as well. |
Provide a proper definition of the attributes that wrongly pretend to be of boolean type while accepting literal values that are not of boolean type. | |
F4380 | Part 4, Section 3.2 Workbook | page 1874, line 22 | te | What is the meaning of 'This subclause describes the elements and simple types that comprise the workbook main definition'? | Clarify the sentence or remove it. | |
F4381 | Part 4, Section 3.2 Workbook | page 1874, line 23 | te | 'The sheets are the central working surface for a spreadsheet application' cannot work as a definition for sheet, for several reasons: a) it refers to a specific kind of application, whereas the definition of the OOXML storage format should be completed in the context of XML files; b) it further refers to the presentation of specific renderings of documents, whereas the OOXML text explicitly declines to address behavioral aspects of the use of OOXML artifacts (Part 1 Sections 2.4 and 2.5); c) it cannot be a part of an XML file. While we understand that making clear what 'sheet' and 'sheets' are in the context of OOXML may call for a behavioral model and explanations that leverage the said behavioral model, we contend that this behavioral model is not appropriately described in the OOXML text, and that the relationships of the OOXML artifacts being defined by the text to the artifacts that pertain to the said behavioral model are not elicited in appropriate levels of clarity and details. | Clarify the definition of sheet provided here. | |
F4382 | Part 4, Section 3.2 Workbook | page 1874, lines 23-39 | te | The terminology is inconsistent across that definition. Amongst other issues, 'book-level' vs 'workbook-level', 'sheet' vs 'worksheet', etc. The relationship of the concepts exposed to XML elements being unclear, this needs clarification beyond editorial work. | Clarify the definition of workbooks provided here. | |
F4383 | Part 4, Section 3.2 Workbook | page 1874, line 26 | te | Does 'child objects' refer to anything but XML elements? If not, the text should use 'child elements' instead. If yes, this would call for clarification of what 'workbook' stands for in the sentence (since it could not be an XML element, and could hardly be an OOXML defined concept). | Clarify the definition of workbooks. | |
F4384 | Part 4, Section 3.2 Workbook | page 1874, lines 29-32 | ed | The explanation here uses imprecise terms ('workbook properties', 'data points') where unambiguous terms could be used to express clear constraints on conformant documents. | Use XML wording to express the constraints, i.e. 'A workbook element comprises one or more...'. | |
F4385 | Part 4, Section 3.2 Workbook | page 1874, line 38 | ed | 'Sheet1 itself' would refer to the peculiar instance of sheet within a peculiar instance of workbook. We'd expect the desired meaning to be more along 'The sheet element specification is given in...' | Rephase. | |
F4386 | Part 4, Section 3.2 Workbook | page 1874, line 39 | te | The 'will be discussed in a separate section' lacks a proper reference. | Provide a proper reference to the section that defines the sheet element (or else to the explanation that is specifically introduced by that sentence). Use the present time ('is' instead of 'will'). | |
F4387 | Part 4, Section 3.2.1 bookViews (Workbook Views) | page 1875, line 2 | ed | 'Each view can specifies a window position' is not proper English. | Replace with 'Each view specifies' or 'Each view can specify' depending on the considered sub-features being compulsory or not. | |
F4388 | Part 4, Section 3.2.1 bookViews (Workbook Views) | page 1875, line 2 | te | 'the collection of workbook views' in meaningless in the current context. Must be related to a workbook, hence 'the collection of workbook views of the enclosing workbook' might do. Better, use XML terms to define the element, even if this could/should be completed by an explanation of what workbook views mean in various rendering contexts. | Clarify. | |
F4389 | Part 4, Section 3.2.3 customWorkbookView (Custom Workbook View) | - | te | The definition of customWorkbookView, both at the semantic level and for many of its attributes, has problems. A sample of those is provided in extenso here, but there are others to be found that are not detailed (more specifically, we did not contribute comments beyond the guid attribute, and we refrained from contributing all the problems found with the definition of the element in the text). We consequently contend that the proposed definition for the customWorkbookView element is broken and should be rewritten. | Provide a proper definition of the customWorkbookView element. | |
F4390 | Part 4, Section 3.2.3 customWorkbookView (Custom Workbook View) | page 1879, line 19 | ed | The 'You can create more than one view of the same workbook without saving separate copies of the workbook' sentence brings no value at all to the text. Given the multiplicity of customWorkbookView into customWorkbookView, it is an euphemism. Moreover, it makes reference to a dynamic behavioral model ('save') that is not defined by the OOXML text. | Remove that sentence. | |
F4391 | Part 4, Section 3.2.3 customWorkbookView (Custom Workbook View) | page 1879, line 20 | te | The 'Custom workbook views are created by the end-user via tools in the application user interface.' is plain wrong. What would prevent a user to create a custom workbook view by means of editing an OOXML document's customWorkbookView elements contents with a simple, non OOXML aware editor, to generate such contents with a conformant batch OOXML producer, etc.? This attempts to define customWorkbookView by use of an unspecified behavioral model, arbitrarily and implicitly singled out from the set of potential conformant applications' behaviors, and falls short of a proper definition by far. | Provide a proper definition of custom workbook view. | |
F4392 | Part 4, Section 3.2.3 customWorkbookView (Custom Workbook View) | page 1880, line 2 | te | The 'shared workbook' concept is not defined here, and non trivial. Unless a definition is given for it, the definition of the 'autoUpdate' attribute is broken. | Provide a definition of what a shared workbook is, either in extenso or by reference, or else provide a proper definition of the autoUpdate attribute by other means, or else remove the autoUpdate attribute from the OOXML text. | |
F4393 | Part 4, Section 3.2.3 customWorkbookView (Custom Workbook View) | page 1880, line 2 | te | According to XML Schema Part 2: Datatypes Second EditionW3C Recommendation 28 October 2004, section 3.2.2.1, the boolean data type can hold the literal values 0, 1, false or true. This excludes the on and off values. Consequently, either the definition of the autoUpdate uses another reference specification for XML Schemas, in which case that other reference specification should be properly identified in the definition, and the said specification authorizes the on and off values for the boolean type, or else the definition of autoUpdate is simply broken.Note: it seems that the use of on and off as boolean values for attributes is specified in many places throughout the OOXML text. A separate comment will be made to take this into account. | Provide a proper definition of the autoUpdate attribute or else remove it from the OOXML text altogether. | |
F4394 | Part 4, Section 3.2.3 customWorkbookView (Custom Workbook View) | page 1880, line 2 | te | The 'when conflicts are found, the changes
being saved always take precedence.' proposition in the definition for the changesSavedWin attribute makes no sense in the context of an XML document storage format. It draws upon a behavioral model that is not properly defined in the text. Accordingly, that definition is broken. |
Provide a proper definition for the changesSavedWin attribute or else remove it from the OOXML text. | |
F4395 | Part 4, Section 3.2.3 customWorkbookView (Custom Workbook View) | page 1880, line 2 | te | The definition for the 'guid' attribute obviously makes reference to mechanisms that are not defined by the OOXML text (especially the Globally word - is that a universal concept of some sort? how the is the uniqueness of the instances ensured?) Reading the definition of the associated ST_Guid simple type does not help. This must be clarified. | Provide a proper definition for the guid attribute or else remove it from the OOXML text. | |
F4396 | Part 4, Section 3.2.3 customWorkbookView (Custom Workbook View) | page 1880, line 2 | ed | 'Correpsonds' is not English. | Replace with 'Corresponds'. | |
F4397 | Part 4, Section 3.2.3 customWorkbookView (Custom Workbook View) | page 1880, line 2 | te | The 'activeSheetId [:]Specifies the sheetId of a sheet in the workbook that is the active sheet in this book view.' proposed definition is a tautology. Moreover, the 'active' word suggests a time related context that cannot be accepted without further elaboration in the context of the OOXML text which focuses on a storage format, hence something static. | Provide a proper definition of the activeSheetId attribute or else remove it from the OOXML text altogether. | |
F4398 | Part 4, Section 3.2.3 customWorkbookView (Custom Workbook View) | page 1880, line 2 | te | The 'Specifies a boolean value that indicates
that this application will automatically update changes at the interval specified by the mergeInterval attribute.' is meaningless in the context of an XML storage format specification. What does 'this application' stand for? |
Provide a proper definition of the autoUpdate attribute or else remove it from the OOXML text altogether. | |
F4399 | Part 4, Section 3.2.4 customWorkbookViews (Custom Workbook Views) | page 1885, lines 32-35 | te | The contrast between customWorkbookViews and bookViews (Section 3.2.1) is insufficiently explained. Moreover, the 'Users create custom views when there is more than one way of viewing the workbook.' seems to assign a secondary role to bookViews, which may not be the text authors intent. | Clarify the relative positioning of bookViews and workbookCustomViews, either in extenso or by reference to an explanation provided elsewhere in the text. | |
F4400 | Part 4, Section 3.2.4 customWorkbookViews (Custom Workbook Views) | page 1885, lines 33-35 | te | The 'Users create custom views when there is
more than one way of viewing the workbook.' and 'enables the user to switch between the views easily' proposition define custom views in the context of a behavioral model that the OOXML does not define. |
Provide a proper definition of customWorkbookViews. | |
F4401 | Part 4, Section 3.2.27 workbook (Workbook) | page 1908, line 11 | te | 'This element is the root part of the workbook in SpreadsheetML' mixes XML and non-XML concepts into something that does not sum up to a proper definition of the workbook element. Should define the workbook element properly, and complete this as needed with an explanation of semantics relating to selected rendering contexts or to a proper behavioral model of conformant applications. | Use XML proper terms and concepts to define the workbook element. | |
F4402 | Part 4, Section 3.2.27 workbook (Workbook) | page 1908, lines 11-20 | te | The definition proposed for the workbook structure does not match at all the detailed contents specified by the schema extract provided page 1910 lines 2-25. If the provided definition is only an explanation meant to illustrate some aspects of the workbook element, this should be made explicit in the text. At face value, this constitutes a self-contradicting definition for the workbook element. | Resolve the contradiction and provide a proper definition for the workbook element. | |
F4403 | Part 4, Section 3.2.27 workbook (Workbook) | page 1908, line 12 | te | 'document' in 'The worksheet is the primary document that you use to store and work with data' does not match the definition for an OOXML document. Since OOXML explicitely precludes the association of other meanings to terms it defines than the definition it gives for them, the definition for worksheet provided here is broken. | Provide a proper definition of worksheet. | |
F4404 | Part 4, Section 3.2.27 workbook (Workbook) | page 1910, lines 8 & 15 | te | The 'bookViews' and 'customWorkbookViews' are used as sibling elements into the 'workbook' element, with the same cardinalities. This reinforces the view that, for nomenclature consistency, except if there is specific meanings in OOXML that would drive a need for singling out 'bookViews', this one should be called 'workbookViews' instead. The same stand for the associated types. This is reinforced by the fact that the included element is called 'workbookView' (as opposed to 'bookView'). | Rename 'bookViews', 'CT_BookViews', etc. to resp. 'workbookViews', 'CT_WorkbookViews', etc. | |
F4405 | Part 4, Section 3.17.7.295 STANDARDIZE | page 2782, line 26 | ed | The provided mathematical formula is blurred. | Provide a clean mathematical formula. | |
F4406 | Part 4, Section 3.17.7.295 STANDARDIZE | page 2782, line 26 | te | The provided mathematical formula uses arguments that are not specified, breaking the definition for the STANDARDIZE function. | Document the match between the mathematical formula arguments and the function arguments. The same for the results. | |
F4407 | Part 4, Section 3.18.95 ST_XmlDataType (XML Data Types) | page 2939, line 0 | ed | All referenced links lack the ':' character after 'http'. | Replace all instances of 'http//' by 'http://'. | |
F4408 | Part 4 | - | ge | This part includes many tables, especially to
describe elements (parent elements, attributes). A very high proportion of
these tables lack the upper border. A sampling done between page 430 and
page 530 gave us a total of 135 tables, of which 49 (36%) exhibited that
defect. Worryingly enough, there seems to be no consistent pattern that
would easily sort of the reason why some tables lack the upper border
while others do not, which suggests that a manual change will be needed
for each faulty table. We suspect that this symptom extends to the whole of Part 4, and even maybe to the full documents set, resulting into hundreds of needed changes. While each of these changes is a small editorial change in nature, we contend that the scale of the issue promotes this comment to a general one. |
Pursue a thorough review of the whole OOXML text and apply a consistent style to tables, especially regarding the upper border. | |
F4409 | Part 4 | - | ge | This part includes many pictures. A very high
proportion of these pictures are blurred, with various degrees of
fuzzyness. A sampling done between page 1 and page 1500 gave us a total of
268 pictures, of which 245 (91%) exhibited that defect. We suspect that this symptom extends to the whole of Part 4, and even maybe to the full documents set, resulting into hundreds of needed changes. While each of these changes is a small editorial change in nature, we contend that the scale of the issue promotes this comment to a general one. It would simply not be acceptable that a published standard had more than 90 % of its pictures blurred, and we do not see the fixing of the current OOXML text as easy. A further analysis of the problem suggests that: - the tools used to edit the OOXML text where not appropriate for the task at hand; - many pictures resulted from the copy as a picture of a result that could (and hence should) have been obtained by the use of textual features of the tooling (e.g. numerous examples of text layout); - many pictures that had a true picture nature were copied with insufficient care; - most cases will have to be addressed separately, which will generate a considerable workload. |
Pursue a thorough review of the whole OOXML text and fix the pictures. Use text instead wherever appropriate. | |
F4410 | Part 4, Section 2.8.2.2 charset (Character Set Supported By Font) | page 740, line 0 | te | The '0xEE' value is said to signify “an Eastern European character set”. There is no such thing. First, “Eastern Europe” is not unambiguously delineated. Second, this region uses many character scripts, including Roman, Cyrillic, Arabic, Armenian, etc. | Explain what is meant by, “an Eastern European character set”. | |
F4411 | Part 4, Section 2.8.2.2 charset (Character Set Supported By Font) | page 740, line 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. | Provide normative reference for “the ANSI character set”. | |
F4412 | Part 4, Section 2.15.3.7 balanceSingleByteDoubleByteWidth (Balance Single Byte and Double Byte Characters) | page 1380, line 22 | ed | The table header is repeated. We did not investigate to see whether this is a frequent issue with the text. | Fix the table. Review the full text for such issues. | |
F4413 | Part 4, Section 3 SpreadsheetML Reference Material | - | ge | A single concept should bear the same name across the text, and the OOXML text should choose between 'array formula', 'array-entered formula' and 'array entered formula' to designate f elements which t attribute is valued to array. There are many instances of use of each of these terms across section 3, and a thourough review is needed.While editorial at first sight, this comment was promoted to general because of the number of occurrences of the different terms, and because of the inherent complexity of the underlying concept. Would the concept have been simpler, the risk of confusion would have been lower (and the acceptability of a lax use of similar but different terms for a single concept slightly higher). | Choose one term for 'array formulas' and apply it consistently throughout the OOXML text. | |
F4414 | Part 4, Section 3.3.1.37 f (Formula) | page 1967, lines 6-25 | te | The definition of the t attribute of the f element is tautological. The definition of its type (ST_CellFormulaType) does not help. While an (inconsistent) attempt is made to describe its dataTable value, nothing tangible is said for the array, normal and shared values. | Provide a proper definition for the t attribute, either in extenso or by reference. | |
F4415 | Part 4, Section 3.3.1.37 f (Formula) | page 1967, line 18 | te | The 'Data tables shall be recalculated whenever a worksheet is recalculated.' sentence defines the f element in the context of a dynamic behavioral model, whereas the OOXML text refuses to define any. Consequently, the definition of the f element is broken. | Provide a proper definition for the f element. | |
F4416 | Part 4, Section 3.3.1.37 f (Formula) | page 1967, line 27 | te | The definition for the aca attribute states that 'true indicates that this formula is an array formula and...' which indicates a dependency between the aca and the t attributes, dependency that is not further clarified. What would be the semantics of an element which opening tag would be '<f aca=”true” t=”normal”>'? Would it be conformant or not? What about '<f aca=”false” t=”normal”>'? | Clarify the definition of the f element. | |
F4417 | Part 4, Section 3.6.1 c (Cell) | page 2086, line 5 | te | The definition for the the a attribute is self-inconsistent (does the property denote an array formula or else an array entered formula?). | Fix the contradiction. | |
F4418 | Part 4, Section 3.6.1 c (Cell) | page 2086, line 5 | te | The definition for the a attribute fails to specify what happens if the formula of the cell referenced by the c element is not of type array. The possible choices are c/a overrides f/whatever, f/whatever overrides c/a, or a conflict occurs and the document is not conformant. Moreover, the other combinations should be described as well. Unless this is specified, the definition of the a attribute of the c element is broken. It may turn out that the a attribute is not needed. | Provide a proper definition for the a attribute or else remove it from the OOXML text. | |
F4419 | Part 4, Section 3.17 Formulas | - | ge | 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. | Provide a full definition of “day count basis”, in particular with respect to treatment of leap years and leap days. | |
F4420 | Part 4, Section 3.17 Formulas | page 2508, line 28 | ge | The 'All arithmetic terms in an expression are
real numbers.' must be untrue. It is at least inconsistent with the
definition given for PI() (page 2745 line 15), which allows conformant
implementations to truncate the value of the pi number to 15 significant
digits, hence suggesting that the arithmetics are not performed according
to the rules of pure real mathematics. It is also contradicting section
3.17.5.2 Precision, page 2524, which describes how applications are
expected to cope with finite binary representations of real numbers, while
failing though to fully explicit the impact of the said representation on
computations (it limits itself to the projection of lexically valid number
representations onto the value space). Operating according to the rules of pure real mathematics is an interesting topic in applied computer science, but can hardly be seen as a requirement for current applications. If it is, then we would contend that the OOXML text is placing exaggerated demands upon compliant applications. If it is not (which section 3.17.5.2 seems to indicate), then we must emphasize that most if not all definitions of OOXML functions are broken, since they rely upon real arithmetics for their semantics. |
Clarify the relationship of the OOXML text
understanding of arithmetics to mathematical real arithmetics (in other
words, state which of section 3.17.2 or section 3.17.5.2 wins, and rewrite
the other). Depending on the conclusions on this topic, review all functions and provide a proper definition for each of them. |
|
F4421 | Part 4, Section 3.17.1 Introduction | page 2507, line 12 | te | The 'equation that performs a calculation' proposition is non-sense. (Equations do not perform calculations.) The resulting definition for formulas is broken. | Fix the definition of formulas. | |
F4422 | Part 4, Section 3.17.1 Introduction | page 2507, lines 12 & 14 | te | The definition for formulas is self-contradicting. Line 12 says they are equations, whereas line 14 says they are expressions. These terms refer to markedly different mathematical concepts, and the text should be clear about which of those applies. | Fix the definition of formulas. | |
F4423 | Part 4, Section 3.17.1 Introduction | page 2507, line 17 | te | The provided example contradicts the definition given for PI() (page 2745 line 15). | Fix the contradiction. | |
F4424 | Part 4, Section 3.17.2 Syntax | page 2508, line 16 | te | The reference to the definition of operators is broken ('§0'). | Fix the reference. | |
F4425 | Part 4, Section 3.17.2 Syntax | page 2508, line 27 | te | The reference to the definition of the space operator is broken ('§0'). | Fix the reference. | |
F4426 | Part 4, Section 3.17.2 Syntax | page 2508, line 32 | te | The 'The way in which formula return values
are returned into the worksheet' proposition rely upon a dynamic
behavioral model to define formulas. However, the OOXML text refuses to
provide such a model. Accordingly, the definition of formulas is
broken. This sentence is only one of the symptoms of the issue. Like for fields, the OOXML text fails to describe how and when computations that are central to the semantics of the things it attempts to define are performed. |
Define a proper dynamic behavioral model for formulas. Define formulas in the context of the said behavioral model. | |
F4427 | Part 4, Section 3.17.2 Syntax | page 2509, line 19 | te | 'multiple cells in a contiguous column' is meaningless. Most probable interpretation is 'multiple contiguous cells in a single column', but could also be 'multiple cells in contiguous columns'. | Clarify. | |
F4428 | Part 4, Section 3.17.2.1 Constants | page 2509, line 22 | te | The 'a predefined value that is not calculated, and, therefore, does not change' proposition makes no sense in the context of the OOXML text. A user could edit any OOXML compliant file with a text editor and change any constant value. As a result, what constants are in the context of the OOXML text is not properly defined. | Provide a proper definition for constants as constitutive parts of the formulas syntax in the context of the OOXML text. | |
F4429 | Part 4, Section 3.17.2.1 Constants | page 2509, line 24 to page 2510, line 20 | te | The syntax of contants 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 the
needed rectitude to define the notation used. In any case, the notation
used should at least be referenced without ambiguity, and the proposed
definitions should be reviewed for conformance to the said
notation. Note that other parts of the syntax for formulas are similarly afflicted from a lack of a proper grammar notation, but that the fragment presented for constants has been seen as prototypical of the issue. |
Provide a proper lexico-syntactic notation, either in extenso or by reference, and apply it to the syntax definition of formulas and their parts. | |
F4430 | Part 4, Section 3.17.2.2 Operators | page 2512, line 0 | te | The 'COUNT((B1:C1) (C1:D1)), which results in a reference to C1' example contradicts the definition of the COUNT function (see page 2578 line 20), which is supposed to return a number. | Fix the contradiction. | |
F4431 | Part 4, Section 3.17.3 Error values | page 2521, line 20 | te | The “note” for the '#DIV/0!' error value appears to define required behavior, not informative remarks | Make the contents of the note be part of the main text, not as a note. | |
F4432 | Part 4, Section 3.17.6.7 Dates and Times | page 2529, line 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. | State the minimum precision required. | |
F4433 | Part 4, Section 3.17.7.4 ACOS | page 2536, line 16 | te | It is not indicated whether the returned value shall be in radians or degrees. | Specify the angular units that should be returned. | |
F4434 | Part 4, Section 3.17.7.9 AND | page 2541, line 12 | 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. | Specify whether this function allows short-circuit evaluation. | |
F4435 | Part 4, Section 3.17.7.9 AND | page 2541, line 15 | te | This 'if no logical values are found, the return value is unspecified.' proposition contradicts page 2513, lines 7&8 that stipulate that 'An expression with value 0 tests logically false while one with any non-zero value tests true.' | Resolve the contradiction. | |
F4436 | Part 4, Section 3.17.7.11 ASC | page 2542, line 15 | 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? | Provide a fuller definition of this function. | |
F4437 | Part 4, Section 3.17.7.12 ASIN | page 2543, line 5 | te | It is not indicated whether the returned value shall be in radians or degrees. | Specify the angular units that should be returned. | |
F4438 | Part 4, Section 3.17.7.14 ATAN | page 2544, line 7 | te | It is not indicated whether the returned value shall be in radians or degrees. | Specify the angular units that should be returned. | |
F4439 | Part 4, Section 3.17.7.15 ATAN2 | page 2544, line 23 | te | It is not indicated whether the returned value shall be in radians or degrees. | Specify the angular units that should be returned. | |
F4440 | Part 4, Section 3.17.7.249 PI | page 2745, line 13 | ed | The text says 'significant figures' whereas we would expect it to say 'significant digits'. | Replace 'significant figures' by 'significant digits'. | |
F4441 | Part 4, Section 3.17.7.249 PI | page 2745, lines 15 & 18 | te | The provided example contradicts the definition, since it displays 9 significant digits in its fractional part instead of the (minimum) 15 significant digits required. | Fix the contradiction. | |
F4442 | Part 4, Section 3.17.5 Limits and Precision | pages 2524-2525 | te | The proposed number definition is close to but different from the XML Schema double datatype (contrast page 2525 line 35 with XML Schema Part 2: Datatypes Second Edition Section 3.2.5 for one of the differences: not the same rule for the determination of the correct representation in the value space of a value that is too precise). This deliberate departure, apparently not supported by compelling reasons, is due to bring confusion. | Use the double datatype as defined by XML Schema Part 2: Datatypes Second Edition instead of a custom number definition. | |
F4443 | Part 4, Section 3.17.5.2 Precision | page 2525, line 6 | te | The 'shall be loaded' proposition makes explicit reference to a dynamic behavioral model that the OOXML text deliberately declines to define. As such, the explanation it is meant to support is broken, and the proposed number definition is broken as well. | Define the needed behavioral model or else explain the number definition without using behavioral concepts. | |
F4444 | Part 4, Section 3.17.5.2 Precision | page 2525, line 6 | ed | The 'numbers of higher precision than available in the value space, and numbers that lie outside the range representable in the value space shall be loaded as numbers in the value space or otherwise handled according to the prescription in §3.17.5.4' proposition is ambiguous. It can be read as 'numbers of higher precision than available in the value space, and numbers that lie outside the range representable in the value space shall be loaded as numbers in the value space, or otherwise handled according to the prescription in §3.17.5.4' or as 'numbers of higher precision than available in the value space, and numbers that lie outside the range representable in the value space shall be loaded as numbers in the value space or otherwise handled, according to the prescription in §3.17.5.4'. From the contents of the referenced section, it finally appears that the desired meaning would be that numbers that do not fit be treated as prescribed by the referenced section; the said section prescribes that numbers of higher precision than available be projected onto the value space according to rules the section specifies, and that numbers that are outside the representable range be treated as the #NUM! error value - that is, the second proposition, which is the least natural reading of the sentence in English. | Replace with a non-ambiguous formulation, that could be 'numbers of higher precision than available in the value space, and numbers that lie outside the range representable in the value space shall be loaded as numbers in the value space or otherwise handled, according to the prescription in §3.17.5.4' or even better 'numbers of higher precision than available in the value space, and numbers that lie outside the range representable in the value space shall be handled as prescribed in §3.17.5.4'. | |
F4445 | Part 4, Section 3.17.7 Predefined Function Definitions | - | ge | The mathematical formula given in many places borders on unreadable and compares very poorly with the clarity of the rest of the text. | Provide better quality mathematical formula. | |
F4446 | Part 4, Section 3.17.7 Predefined Function Definitions | - | ge | In many function definitions, the relationship of the provided mathematical formula symbols to the function parameters and return value calls for quite a bit of guessing. While what is needed in some of these cases is of editorial nature, some cases are really challenging. Moreover, the repetition of such mismatches in such volumes is unacceptable. | Review all provided mathematical formulas to better link them to the functions they are meant to define. | |
F4447 | Part 4, Section 3.17.7.101 DURATION | page 2623, line 22 | te | The function is defined in terms of $100 par value, but there is nothing about the bond calculations that is inherently tied to the US Dollar. | Recommend the use of the generic currency sign here (U+00A4) | |
F4448 | Part 4, Section 3.17.7.111 EXACT | page 2631, line 28 | 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. | Clarify what defines two strings as having identical content. | |
F4449 | Part 4, Section 3.17.7.116 FALSE | page 2635, line 10 | te | The added value of that function is dubious at best. Since we already have a notation for the very same thing (FALSE), that function is unneeded, and only clutters the specification. | Remove all references to the FALSE() function from the OOXML text. | |
F4450 | Part 4, Section 3.17.7.118 FIND | page 2636, line 15 | te | Similar issue to EXACT. Is this a lexical comparison or collation-based? | Clarify the basis for finding substrings | |
F4451 | Part 4, Section 3.17.7.119 FINDB | page 2637, line 13 | te | Similar issue to EXACT. Is this a lexical comparison or collation-based? | Clarify the basis for finding substrings | |
F4452 | Part 4, Section 3.17.7.120 FINV | page 2638, line 9 | 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. | Keep the suggestions, but put them in informative Notes or Guidance. | |
F4453 | Part 4, Section 3.17.7.123 FIXED | page 2640, line 10 | te | The rounding algorithm is not specified. How for example, do we calculate FIXED(0.5,0)? | State what the rounding conventions are. | |
F4454 | Part 4, Section 3.17.7.125 FORECAST | page 2641, line 26 | 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 | |
F4455 | Part 4, Section 3.17.7.131 GAMMAINV | page 2646, line 22 | te | This function says, “GAMMAINV uses an iterative search technique”. This is specifying an implementation, not a testable performance criterion. Other approaches should be permitted. | Keep the suggestions, but put them in informative Notes or Guidance. | |
F4456 | Part 4, Section 3.17.7.143 HOUR | page 2658, line 11 | 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? | Correct the text | |
F4457 | Part 4, Section 3.17.7.144 HYPERLINK | page 2659, line 1 | 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. | Provide a normative definition or reference for a UNC path. | |
F4458 | Part 4, Section 3.17.7.169 INTERCEPT | page 2679, line 27 | 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 | |
F4459 | Part 4, Section 3.17.7.17 AVEDEV | page 2545, line 27 | te | The mathematical formula given is incorrect. It is a formula for calculating the number of combinations of n things taken k at a time. This does not concern absolute deviation. | Provide a correct formula. | |
F4460 | Part 4, Section 3.17.7.17 AVEDEV | page 2546, line 0 | ed | The function description has a typo/duplication: “cells with the value 0value 0” | Fix the typographical error | |
F4461 | Part 4, Section 3.17.7.172 IRR | page 2682, line 19 | 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. | Keep the suggestions, but put them in informative Notes or Guidance. | |
F4462 | Part 4, Section 3.17.7.186 KURT | page 2690, line 24 | 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” | Provide the complete definition. | |
F4463 | Part 4, Section 3.17.7.193 LINEST | page 2696, line 3 | 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 | |
F4464 | Part 4, Section 3.17.7.201 LOWER | page 2704, line 4 | 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. | Clarify what it means to convert to lower case. | |
F4465 | Part 4, Section 3.17.7.206 MDURATION | page 2708, line 8 | te | The function is defined in terms of $100 par value, but there is nothing about the bond calculations that is inherently tied to the US Dollar. | Recommend the use of the generic currency sign here (U+00A4) | |
F4466 | Part 4, Section 3.17.7.207 MEDIAN | page 2709, line 18 | te | According to the definition, 'Logical values ... entered directly into the list of arguments are included.'. But what could be the value of MEDIAN(FALSE, TRUE)? The definition of MEDIAN is clearly broken. | Provide a proper definition for MEDIAN or remove it from the OOXML text. | |
F4467 | Part 4, Section 3.17.7.207 MEDIAN | page 2709, line 18 | 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...” | Clarify the definition. | |
F4468 | Part 4, Section 3.17.7.227 NORMINV | page 2724, line 18 | te | This text says, “NORMINV uses an iterative search technique”. This is specifying an implementation, not a testable performance criterion. Other approaches should be permitted. | Keep the suggestions, but put them in informative Notes or Guidance. | |
F4469 | Part 4, Section 3.17.7.229 NORMSINV | page 2726, line 7 | te | This text says, “NORMSINV uses an iterative search technique”. This is specifying an implementation, not a testable performance criterion. Other approaches should be permitted. | Keep the suggestions, but put them in informative Notes or Guidance. | |
F4470 | Part 4, Section 3.17.7.243 OR | page 2741, line 10 | 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. | Specify whether this function allows short-circuit evaluation. | |
F4471 | Part 4, Section 3.17.7.244 PEARSON | page 2742, line 3 | 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 | |
F4472 | Part 4, Section 3.17.7.280 RSQ | page 2771, line 21 | 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 | |
F4473 | Part 4, Section 3.17.7.282 SEARCH | page 2773, line 17 | te | Is this a lexical comparison or collation-based search? | Clarify the basis for string comparisons | |
F4474 | Part 4, Section 3.17.7.283 SEARCHB | page 2774, line 16 | te | Is this a lexical comparison or collation-based search? | Clarify the basis for string comparisons | |
F4475 | Part 4, Section 3.17.7.287 SIN | page 2777, line 18 | te | It is not indicated whether the parameter is in radians or degrees | Specify the angular units that this parameter is in | |
F4476 | Part 4, Section 3.17.7.291 SLOPE | page 2780, line 9 | 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 | |
F4477 | Part 4, Section 3.17.7.296 STDEV | page 2783, line 18 | 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 | |
F4478 | Part 4, Section 3.17.7.297 STDEVA | page 2784, line 16 | 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 | |
F4479 | Part 4, Section 3.17.7.298 STDEVP | page 2785, line 10 | 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 | |
F4480 | Part 4, Section 3.17.7.299 STDEVPA | page 2786, line 5 | 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 | |
F4481 | Part 4, Section 3.17.7.300 STEYX | page 2787, line 2 | 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 | |
F4482 | Part 4, Section 3.17.7.312 T | page 2797, line 13 | te | The definition for the T function is not self-consistent. The 'The value to be encoded in text.' says that the value will be encoded, which would yield to T(1) returning 1 (typed as text), whereas line 15 explicitly states that T(1) returns the empty string “”. | Provide a proper definition for T or remove it from the OOXML text. | |
F4483 | Part 4, Section 3.17.7.313 TAN | page 2798, line 1 | te | It is not indicated whether the parameter is in radians or degrees | Specify the angular units that this parameter is in | |
F4484 | Part 4, Section 3.17.7.335 VAR | page 2813, line 10 | 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 | |
F4485 | Part 4, Section 3.17.7.336 VARA | page 2814, line 3 | 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 | |
F4486 | Part 4, Section 3.17.7.337 VARP | page 2814, line 21 | 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 | |
F4487 | Part 4, Section 3.17.7.338 VARPA | page 2815, line 18 | 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 | |
F4488 | Part 4, Section 3.17.7.34 CELL | page 2561, line 1 | 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? | Specify what happens in this case. | |
F4489 | Part 4, Section 3.17.7.344 WORKDAY | page 2821, line 21 | 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. | Define this function unambiguously and preferably in a way which provides for cultural adaptability in the definition of a weekend. | |
F4490 | Part 4, Section 3.17.7.348 YEARFRAC | page 2826, line 6 | te | The definition for function YEARFRAC is not self-consistent. The parameters table lists one more parameter than the function syntax line 3. | Fix the contradiction. | |
F4491 | Part 4, Section 3.17.7.348 YEARFRAC | page 2826, line 6 | te | This function is ambiguous. Specifically it does not treat the calculation in the presence of leap years. In the Actual/Actual basis, do we ever divide by 366? Or only by 365? Would we divide by 366 only if the leap day is between start-date and end-date? Of either start-date or end-date are in the leap year? If both start-date and end-date are in a leap year? | Clarify the definition of the function when involving leap years. | |
F4492 | Part 4, Section 3.17.7.35 CHAR | page 2563, line 9 | te | This function maps between numbers and characters. But this mapping must be defined b y a character set and none is defined here. | Specify what character set is used for this mapping. | |
F4493 | Part 4, Section 3.17.7.37 CHIINV | page 2564, line 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. | Keep the suggestions, but put them in informative Notes or Guidance. | |
F4494 | Part 4, Section 3.17.7.38 CHITEST | page 2565, line 22 | 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 that should be returned? | Specify the required results for the case where the two ranges are of unequal size. | |
F4495 | Part 4, Section 3.17.7.47 CONFIDENCE | page 2571, line 30 | 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? | Make the distribution assumptions explicit. | |
F4496 | Part 4, Section 3.17.7.48 CONVERT | pages 2572-2575 | 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. | Refine the definition of this function, especially with respect to pre-metric measures so as to remove ambiguity. | |
F4497 | Part 4, Section 3.17.7.49 CORREL | page 2576, line 25 | 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 | |
F4498 | Part 4, Section 3.17.7.50 COS | page 2577, line 15 | te | It is not indicated whether the parameter is in radians or degrees | Specify the angular units that this parameter is in | |
F4499 | Part 4, Section 3.17.7.63 COVAR | page 2589, line 6 | 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 | |
F4500 | Part 4, Section 3.17.7.65 CUBEKPIMEMBER | page 2590, line 17 | 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? | Provide a vendor-neutral definition of this function. | |
F4501 | Part 4, Section 3.17.7.65 CUBEKPIMEMBER | page 2590, line 21 | 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 be interoperability in the use of this function, semantics in additional to syntax will need to be specified. | Provide the semantics for this function | |
F4502 | Part 4, Section 3.17.7.66 CUBEMEMBER | page 2591, line 19 | 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? | Provide a vendor-neutral definition of this function. | |
F4503 | Part 4, Section 3.17.7.66 CUBEMEMBER | page 2592, line 0 | te | This function refers to, “A multidimensional expression (MDX) that evaluates to a unique member in the cube”. But MDX is undefined. | Define the syntax and semantics of an MDX | |
F4504 | Part 4, Section 3.17.7.76 DATEVALUE | page 2603, line 6 | 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? | Resolve the ambiguity in the definition when a string with time format is passed in. | |
F4505 | Part 4, Section 3.17.7.77 DAVERAGE | page 2603, line 24 | 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. | Rework the note into the normative description of this function. | |
F4506 | Part 4, Section 3.17.7.77 DAVERAGE | page 2604, line 0 | te | From the provided definition for criteria, it results that there would be no easy means to select '=XX', '=XX1', '=XX12', '=XX234' etc. (that is all strings starting with '=XX') without also selecting 'XXX'. More generally, the full consequences of the consideration of logical operators as overriding the more general mechanism of leading part matching are not exposed. Looking further to those consequences, while admitting that the convention could be a convenient shortcut in a user-interface, we contend that it brings unneeded confusion where clearer conventions (aka using an escape sequence for literal '=' etc. or conversely using an explicit notation for comparison operators) would provide a more robust storage format. | Expand the explanation of the consequences of the design choice further, or (preferred) come up with a cleaner design. | |
F4507 | Part 4, Section 3.17.7.78 DAY | page 2606, line 1 | 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? | Define fully what this function returns. | |
F4508 | Part 4, Section 3.17.7.89 DEVSQ | page 2615, line 4 | ed | The function description has a typo/duplication: “cells with the value 0value 0” | Fix the typographical error | |
F4509 | Part 4, Section 3.17.7.91 DISC | page 2616, line 21 | te | The function is defined in terms of $100 face value, but there is nothing about the security discounting that is intrinsically tied to the US Dollar. | Recommend the use of the generic currency sign here (U+00A4) | |
F4510 | Part 4, Section 3.17.7.94 DOLLAR | page 2618, line 27 | te | Cannot see how the format could be both locale-specific, and looking like '$...'. The format referred to here is not anything that would look like the proposed string, but implicitly refers to a specific codification of how strings may represent numbers that is not properly defined. | Provide a proper definition of what format is in this context, either by reference or in extenso, or else define DOLLAR by other means, or else remove the DOLLAR function from the OOXML text. | |
F4511 | Part 4, Section 3.17.7.94 DOLLAR | page 2619, line 12 | te | At the current exchange rate, $ 1234.567 is approximately worth 916,667 €. Not 1234,567 €. The name of the function is much confusing, since it presents in the current locale an amount that is specified in the current locale, but is named DOLLAR, which is a peculiar currency. | Rename the function or remove it. | |
F4512 | Part 4, Section 3.17.7.95 DOLLARDE | page 2619, line 28 | 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 amount 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 number interpreted as a fraction”. | Clarify how this function works | |
F4513 | Part 4, Section 3.17.7.96 DOLLARFR | page 2620, line 20 | te | This function is ambiguously defined. Specifically, what would DOLLARFR(1.5,3) return? There is no number d that could satisfy d/3 = 0.5? Also, 1 + 2/16 = 1+ 02/16 = 1 + 002/16 = 1.125. The provided definition does not say why 1.02 gets selected over 1.2, 1.002. | Clarify how this function works | |
F4514 | Part 4, Section 3.17.7.224 NETWORKDAYS | page 2722, line 12 | te | The definition of NETWORKDAYS relies upon what a weekend is. For some cultures, the weekend is Saturday and Sunday. For others, the days of rest are either Thursday/Friday or Friday/Saturday. OOXML does not define “weekend” and does not provide a way for the user to define it either. The definition for NETWORKDAYS is therefore broken. | Provide a proper definition for NETWORKDAYS: the current NETWORKDAY function should transferred to the future OOXML Extention part while a new function should be conceived for the future OOXML Core. | |
F4515 | Part 4, Section 4.7 Slide Synchronization Data | page 3163, line 4 | te | 'The sldSyncPr element lives in the slideUpdateInfo directory of the PowerPoint file container.' cannot properly define any part of the OOXML specification, in that it refers to a specific software product, on the one hand, and uses terms that are alien to the description of the structure of the artefacts being defined, i. e. XML documents. This is reinforced by the parent element specification given line 7, which is unrelated to any acceptable root element for OOXML documents. | Reconsider section 4.7 as a whole. Either describe in proper ways features that would be relevant to spreadsheet documents XML storage, or else remove it from the OOXML text. | |
F4516 | Part 4, Section 4.7.1 sldSyncPr (Slide Synchronization Properties) | page 3163, line 9 | te | The definitions of the clientInsertedTime and serverSldModifiedTime attributes pretend that their values 'are stored in ISO 8061 format' and 'are defined by the XML Schema dateTime datatype'. However, XML Schema Part 2: Datatypes Second EditionW3C Recommendation 28 October 2004, which we believe is the appropriate version of XML Schema Datatypes to consider at the time of writing, goes at lengths to explain the nuances between ISO 8061 and the dateTime datatype. The reference to ISO 8061 in the OOXML text is therefore confusing at best, and inconsistent with the prescribed datatype. | Remove references to ISO 8061, or else, assuming that the said attributes really have dateTime datatype, explain the real relationships between their type and ISO 8061. | |
F4517 | Part 4, Section 2.16.4.3 General formatting | page 1501, line 0 | te | The CHARFORMAT switch argument has no documented raw XML equivalent (such as those ST_NumberFormat provides for number formatting switch arguments). This shades doubt upon the value of the CHARFORMAT switch argument, or else a potential hole in the XML notations proposed in other parts of the OOXML text. | Create a raw XML notation that matches the CHARFORMAT switch argument or (better) suppress the need for the switch argument, either by using a proper XML notation for text formats in the context of fields, or simply by suppressing it from the OOXML proposal altogether. | |
F4518 | Part 4, Section 2.16.4.3 General formatting | page 1501, line 0 | te | The Caps switch argument has no documented raw XML equivalent (such as those ST_NumberFormat provides for number formatting switch arguments). This shades doubt upon the value of the Caps switch argument, or else a potential hole in the XML notations proposed in other parts of the OOXML text. | Create a raw XML notation that matches the Caps switch argument or (better) suppress the need for the switch argument, either by using a proper XML notation for text formats in the context of fields, or simply by suppressing it from the OOXML proposal altogether. | |
F4519 | Part 4, Section 2.16.4.3 General formatting | page 1504, line 0 | te | The Lower switch argument has no documented raw XML equivalent (such as those ST_NumberFormat provides for number formatting switch arguments). This shades doubt upon the value of the Lower switch argument, or else a potential hole in the XML notations proposed in other parts of the OOXML text. | Create a raw XML notation that matches the Lower switch argument or (better) suppress the need for the switch argument, either by using a proper XML notation for text formats in the context of fields, or simply by suppressing it from the OOXML proposal altogether. | |
F4520 | Part 4, Section 2.16.4.3 General formatting | page 1504, line 0 | te | The MERGEFORMAT switch argument has no documented raw XML equivalent (such as those ST_NumberFormat provides for number formatting switch arguments). This shades doubt upon the value of the MERGEFORMAT switch argument, or else a potential hole in the XML notations proposed in other parts of the OOXML text. | Create a raw XML notation that matches the MERGEFORMAT switch argument or (better) suppress the need for the switch argument, either by using a proper XML notation for text formats in the context of fields, or simply by suppressing it from the OOXML proposal altogether. | |
F4521 | Part 4, Section 2.16.4.3 General formatting | page 1505, line 0 | te | The Upper switch argument has no documented raw XML equivalent (such as those ST_NumberFormat provides for number formatting switch arguments). This shades doubt upon the value of the Upper switch argument, or else a potential hole in the XML notations proposed in other parts of the OOXML text. | Create a raw XML notation that matches the Upper switch argument or (better) suppress the need for the switch argument, either by using a proper XML notation for text formats in the context of fields, or simply by suppressing it from the OOXML proposal altogether. | |
F4522 | Part 4, Section 3.17.4.1 Date Representation | page 2522, lines 16&18 | ed | The documented upper limits for the date part of serial date times match 9999-12-31 00:00:00, which is correct, but could be supplemented for the sake of extensive clarity by a mention of the absolute upper limits for serial date times, that would match 9999-12-31 23:59:59. | Add a mention, possibly in an informative note, that the upper limit on date time serial numbers match 9999-12-31 23:59:59, and precise the corresponding serial numbers as appropriate (depending on the date base). | |
F4523 | Part 4, Section 3.17.4.2 Time Representation | page 2523, lines 22-23 | te | Page 2523 lines 22&23 state that 'The time component of a serial value ranges in value from 0–0.99999999, and represents times from 0:00:00 (12:00:00 AM) to 23:59:59 (11:59:59 P.M.), respectively.', while line 32 states that 'TIMEVALUE("23:59:59") results in the serial value 0.9999884…'. This leaves us with a contradiction relative to the representation of 23:59:59, unless serial values and times are not related by a bijection, which would have important consequences on the time representation for OOXML, and would deserve further clarification. | Resolve the contradiction and clarify the time representation in OOXML. | |
F4524 | Part 4, Section 2.16.4.3 General formatting | page 1505, line 0 | te | The FirstCap switch argument has no documented raw XML equivalent (such as those ST_NumberFormat provides for number formatting switch arguments). This shades doubt upon the value of the FirstCap switch argument, or else a potential hole in the XML notations proposed in other parts of the OOXML text. | Create a raw XML notation that matches the FirstCap switch argument or (better) suppress the need for the switch argument, either by using a proper XML notation for text formats in the context of fields, or simply by suppressing it from the OOXML proposal altogether. | |
F5001 | Part 5, Section 1 Scope | page 1, line 3 | ed | The 'that facilitate future enhancement and extension of Office Open XML' proposition is a judgment call (in other words, an unsupported assertion). It may be that the intent of the OOXML text be to deliver on that promise, but that promise is fundamentally, by its having measurable results in future time only, not delivered yet. | Rephase in accordance with the general proposal to split the present int two parts and the future revision of ODF | |
F5003 | Part 5, Section 3 Definitions | page 3, line 4 | te | The note brings no value here, since it fails to tell which terms are defined in Part 2 that must be understood as defined in Part 2 within Part 5. Contrast this with the precautions taken above to clearly explain how Part 5 defines terms (that is in extenso in section 3 or else as they are met in italics in the text), and how these terms must be interpreted. Depending on the further contents of Part 5, the writer might prefer to drop the note if each needed term borrowed from Part 2 is defined in Part 5 by writing it in italics and referring to Part 2, or else promote the note to normative text and complete it with the extensive list of terms that stand in Part 5 for the semantics defined for them in Part 2. | Refine the contents of the note and promote them to normative text or else delete it altogether, depending on the remainder of Part 5 text. | |
F5004 | Part 5, Section 3 Definitions | page 3, lines 9-11 & lines 17-18 | te | The definitions of 'alternate content' and
'markup consumer' do not hold together. If a markup consumer is defined as
'a tool that can read and parse a markup document and further conforms to
the requirements of a markup specification' then the total contents of a
submitted markup document must conform to the markup specification that
the said markup consumer has to understand, the alternate content in such
a document cannot have any meta-status that would contrast it from the
other contents of the said document, the markup consumer has to read and
parse it - implying it processes it at least as needed for the parsing,
and the constraint on the said markup consumer to apply specific
processing to the alternate content, be it a choice or whatever other
processing, is a further specialization of the said markup consumer.
Moreover, the said constraint is ill-defined, in that the markup consumer has to understand the markup specification of alternate content, which may imply a specific namespace, and fails to define the expected behavior of markup consumers that would understand many namespaces but should still, per the definition of alternate content, select at most one alternative. Moreover, there exists no concept of markup alternative in XML specification. If the definition for 'alternate content' attempts to draw from common sense to define itself, it should still clarify the relationship of markup here to the definition of markup by the XML specification (especially, it would follow from the use of the XML specification definition of markup that character data is unaffected by the required choice of a single alternative amongst several, which is unlikely). It follows from this that the definition for alternate content is broken, and that the definition for markup specification may be broken as well (in that it could contradict a fixed definition of altenate content, depending on the degree of similarity of the fixed definition to the current, broken definition). |
Provide proper definitions for 'alternate content' and 'markup consumer'. | |
F5005 | Part 5, Section 3 Definitions | page 3, line 25 | ed | Extraneous trailing full stop at the end of the line. | Remove the extraneous full stop. | |
F5006 | Part 5, Section 3 Definitions | page 3, line 27 | te | The definition for 'markup specification' is tautological. | Provide a proper definition for 'markup specification'. | |
F5007 | Part 5, Section 3 Definitions | page 3, line 27 | ed | 'all of the requirement' lacks the plural. | Replace with 'all of the requirements'. | |
F5008 | Part 5, Section 3 Definitions | page 4, line 3 | te | The definition for 'recognize' draws upon
parts of the OOXML text that are deemed as irrelevant to conformance
determination (specifically, 'have the knowledge of' is in the realm of
semantics, which is not considered for conformance determination,
according to Part 1, Section 2). If that knowledge was to be limited to
the one needed to fulfill the requirements set in Part 1, Section 2.3,
page 3, lines 11-13, then the definition of 'namespace, understood', page
4, line 1 would encompass the namespace elements and attributes needed for
Part 5 only (in other terms, exclude all WordprocessingML, etc. elements
and attributes), which seems unlikely, and the definition of 'namespace,
ignorable', page 3 line 29 would be broken. The net result is that several key terms defined in section 3 have no bearing on the conformance of OOXML documents and applications, or else that their definition is broken. |
Clarify. | |
F5009 | Part 5, Section 4 Notational Conventions | page 5, line 5 | te | Section 4 is not marked as informative, hence it is normative. However, the 'The name of an XML element is written using an Element style.' sentence fails to give the reader any real information about what distinguishes XML element names from the surrounding text. (Note that according to Part 1 Section 7 page 10 line 18 the text enclosed between [Example: and ] is informative.) | Provide a proper description of the style used for XML element names. | |
F5010 | Part 5, Section 4 Notational Conventions | page 5, line 5 | te | The 'A term defined as a basic definition' expression makes no sense in English. | Clarify or remove. | |
F5011 | Part 5, Section 4 Notational Conventions | page 5, line 8 | te | Section 4 is not marked as informative, hence it is normative. However, the 'The name of an XML element attribute is written using an Attribute style.' sentence fails to give the reader any real information about what distinguishes XML element attribute names from the surrounding text. (Note that according to Part 1 Section 7 page 10 line 18 the text enclosed between [Example: and ] is informative.) | Provide a proper description of the style used for XML element attribute names. | |
F5012 | Part 5, Section 4 Notational Conventions | page 5, line 12 | te | Section 4 is not marked as informative, hence it is normative. However, the 'An XML element type name is written using a Type style.' sentence fails to give the reader any real information about what distinguishes XML element type names from the surrounding text. (Note that according to Part 1 Section 7 page 10 line 18 the text enclosed between [Example: and ] is informative.) | Provide a proper description of the style used for XML element type names. | |
F5013 | Part 5, Section 6 General Description | page 7, line 8 | te | Part 5 has no section 13. There seems to be
another mismatch line 7 in that section 7 is named Overview (not section
8). The reference pointed to by line 20 does not explain how informative
text is embedded into normative text... Section 6, which is meant to be normative according to line 13, defines normative parts of the document based upon flawed section numbers and relies upon broken references. This must be fixed, or else there is no means to assert which subparts of Part 5 are normative and which are informative. |
Fix Section 6, or else put in place other means to mark normative and informative parts, or else declare the whole of Part 5 as normative, or else declare the whole of Part 5 as informative, or else suppress Part 5 from the OOXML text. | |
F5014 | Part 5, Section 7 Overview | page 8 | ed | Section 7 makes a series of judgment calls
(like 'enable producers to explicitly guide consumers') and presents them
as objective properties of the contents of Part 5. We contend that these
are unsupported assertions, and that the text should make clear that the
properties described, and rightfully deemed desirable, were amongst the
design objectives of the OOXML text writers, instead of claiming that
those objectives have been reached. Since section 7 is informative, we refrained from analyzing further its contents flaws (for example, the fragment cited above makes reference to an undefined behavioral model), and we tagged this comment as editorial. |
Rewrite section 7 in such a way that the authors' intents and objectives are not presented as achievements, or else fully demonstrate that these objectives are fulfilled by Part 5. | |
F5015 | Part 5, Section 8.1 Terminology | page 9 | ge | We have strong and pervasive reservations on
the contents of section 8.1. We have submitted several technical comments
that illustrate some of the most salient issues with the current state of
the text in that section, but these only illustrate the more general fact
that section 8.1 fails to define properly the terms it aims to define.
Moreover, it does not properly links the said concepts to the underlying
XML specification, or even to other parts of the OOXML text. The net result is that section 8.1 makes a failed attempt to conceptualize the subject, purpose and contents of Part 5. Interestingly enough, this might be of no essential consequence on the relevance of the remainder of Part 5. It may be that the desired structure of the OOXML storage format, and the desired semantics attached to it, could be explained without building a full-blown theory over and beyond the conceptual stage provided by the XML and XML Namespaces specifications and other parts of the OOXML text that precede Part 5, and that section 3 could be radically simplified, only defining a few extra terms that would much less stretch the common-sense or XML semantics of their own defining terms. |
Rebuild a sound conceptualization of the matters covered by Part 5 and rebuild section 8.1 based upon it, or else (preferred) prefer the systematic use of the concepts defined by the relevant XML-related specifications (including other parts of the OOXML text) and limit the list of needed extra terms (and therefore needed definitions) to a much smaller shorter one, comprising of simpler terms with proper definitions. | |
F5016 | Part 5, Section 8.1 Terminology | page 9, line 2 | ed | Section 8.1 and section 3 overlap significantly in purpose and contents. | Reorganize the text. | |
F5017 | Part 5, Section 8.1 Terminology | page 9, line 3 | te | The 'Any XML-based document specification' is way too imprecise. Is that a document specification provided in an XML format (could be ODF or OOXML for example)? Or a specification of an XML-based format for documents? Contrast this with Part 1, Section 1: 'This Standard defines Office Open XML's vocabularies and document representation and packaging.', which uses precise terms. | Use more precise and relevant terms. See also our general comments about the failed conceptualization in Part 5. | |
F5018 | Part 5, Section 8.1 Terminology | page 9, line 10 | te | 'markup consumer' is pleonastic, and redundant with 'consumer' as defined in Part 1, Section 8.2. The introduction of an unneeded layer of (ill-defined) concepts over XML and other parts of OOXML must be avoided. | Remove unneeded terms. See also our general comments about the failed conceptualization in Part 5. | |
F5019 | Part 5, Section 8.1 Terminology | page 9, line 14 | te | 'recognize' is assimilated here to 'process', whereas the reading and parsing of the text contents *is* a processing of the such text contents. Therefore, all concepts in Part 5 that rely upon the 'recognize' concept are ill-defined, the way lines 15-17 place a requirement on concepts which definitions lines 13-15 is void and broken, whereas the contents of the said constraints might have provided the basis of acceptable definitions, the reference to 'an unrecognized element or attribute from the Markup Compatibility namespace' on line 19 whereas recognized - hence unrecognized - elements are not defined on the Markup Compatibility namespace unless this namespace would explicitly be required to be an understood namespace for all conformant consumers, etc. | Provide a proper definition for 'recognize' or else remove all references to it from Part 5 of the OOXML text. See also our general comments about the failed conceptualization in Part 5. | |
F5020 | Part 5, Section 8.1 Terminology | page 9, line 15 | te | Lines 15-17 place a requirement on concepts which definitions as provided by lines 13-15 are void and broken, whereas the contents of the said constraints might have provided the basis of acceptable definitions, the reference to 'an unrecognized element or attribute from the Markup Compatibility namespace' on line 19 whereas recognized - hence unrecognized - elements are not defined on the Markup Compatibility namespace unless this namespace would explicitly be required to be an understood namespace for all conformant consumers, etc. | Provide proper definitions for 'recognize' and 'understood namespaces' or else remove all references to them from Part 5 of the OOXML text. See also our general comments about the failed conceptualization in Part 5. | |
F5021 | Part 5, Section 8.1 Terminology | page 9, line 19 | te | The reference to 'an unrecognized element or attribute from the Markup Compatibility namespace' is meaningless since recognized - hence unrecognized - elements are not defined on the Markup Compatibility namespace. (Their being defined would - at least - demand that the Markup Compatibility namespace be explicitly required to be an understood namespace for all conformant consumers - which is not the case.) | Reconsider the whole sentence. See also our general comments about the failed conceptualization in Part 5. | |
F5022 | Part 5, Section 8.1 Terminology | page 9, lines 20-23 | te | The chosen default behavior - error on unrecognized parts unless these are explicitly marked as ignorable - is due to maximize the number of compatibility errors raised, hence forfeits the interoperability objectives of the markup compatibility part of the OOXML specification, hence adversely impacts the general interoperability objectives of the OOXML specification as a whole. | Retain the opposite default and treat elements and attributes of non-understood namespaces as ignored unless otherwise stated. (That recommandation may prove simplistic. However, the 'error by default' is problematic because of the exposed griefs. More precisely, the text might consider degrees of validation - in the XML sense of validation - and other refinements here.) | |
F5023 | Part 5, Section 8.1 Terminology | page 9, lines 26-27 | te | According to section 3, the fact that 'ignore' is in italics means that it is defined in the surrounding text. However, the remainder of the sentence does not explain what ignore would mean. (The second part of the sentence adds a constraint on conformant consumers, it does not define the ignore term; if it were to be considered to define the ignore term, then the meaning of the ignore term would literaly be 'do not raise errors upon', which makes no sense.) | Define ignore properly, or rewrite the whole explanation. See also our general comments about the failed conceptualization in Part 5. | |
F5024 | Part 5, Section 8.1 Terminology | page 9, line 28 | te | According to 'the content should be processed
as if it were the content of the ignored element’s parent', assuming that
ns1 be an ignorable namespace and that consumers that do not understand it
are told to process the contents of its elements as if they were the
contents of the ignored elements parents, the following
fragment: <a> <ns1:ign> ignorable text </ns1:ign> <b> important text </b> </a> would have to be interpreted as: <a> ignorable text </a> We believe that this is highly undesirable. Moreover, it is confusing, and therefore, if this is the intended semantics, the OOXML text should explain it more thoroughly. Else, the text should be fixed to reflect the real intents of the OOXML specification. |
Clarify. | |
F5025 | Part 5, Section 8.1 Terminology | page 9, line 30 | ed | Extraneous line break. | Remove the extraneous line break. | |
F5026 | Part 5, Section 8.1 Terminology | page 9, line 32 | te | The 'The markup editor can attempt to persist these ignored elements and attributes when a saving markup document, despite the editor’s inability to recognize the purpose of these ignored elements and attributes.' requirement is dangerously too lax. It paves the way to information erasure from documents by some conformant applications, giving little chances, and no warranty at all, to users of two different conformant editors E1 and E2 to safely round-trip their documents. As such, it is a major setback for the interoperability objectives of the OOXML specification.We understand that some classes of conformant applications, and especially of consumers that are not producers, must be relaxed on many constraints on their output (the first of which being to produce OOXML documents). However, as far as 'editor' in the OOXML text refers to what is generally understood to be an editor (note that no explicit definition has been provided), editors should not be authorized to erase any part of the underlying documents, beyond the erasures (and other modifications) that could be directly traced to a user edition. | Put more constraints on compliant editors, so as to fulfill the announced objectives of first-class interoperability. Specifically in this case, do not allow conformant editors to erase information from OOXML documents, even from parts of the said documents that the said editors are not able to interpret, unless this can be traced to an explicit user edition action. | |
F5027 | Part 5, Section 8.1 Terminology | page 10, line 9 | te | The 'A new understood namespace subsumes a
previously-understood namespace if it includes all of the elements,
attributes, and attribute values of the previously-understood namespace.'
definition for 'subsumes' has a significant drawback: it introduces a
subsuming relationship between any two namespaces that are only related by
an inclusion relationship. This is damageable to the clarity of the
specification (unless this implication is wanted - but that would need
further explanation). This will damage interoperability whenever two
alternative namespaces meant to extend the specification will happen to be
bound by an inclusion relationship. This is difficult to check as stated
(without an indication by the specification that one namespace is
'included' into the other, the verification of the property is tedious at
best). This fails to convey the intent of the specification authors to
explicitly replace such or such part of the understood namespaces by
others. This fails to define what 'includes all of the elements,
attribures, and attribute values of [a] namespace' may be (the XML-based
first-level answer, that would be that elements and attributes of the same
local names exist, is obviously not enough). All in all, the 'subsume' concept is not properly defined by the OOXML text, and at least of its possible interpretations conveys undesireable semantics. |
Provide a proper and acceptable (in terms of semantics) definition for what it means for a namespace to subsume another one, or else drop it from the OOXML text. Any acceptable definition would, in our opininion, tolerate that a namespace that is 'included' (term to be further defined by the spec) into another namespace not be subsumed by the said namespace. | |
F5028 | Part 5, Section 8.1 Terminology | page 10, line 15 | te | 'This specification can be implemented using a
pipelined, preprocessing architecture in the form of a software module
called a markup preprocessor. A markup preprocessor can use the Markup
Compatibility elements and attributes to produce output that is free of
all ignorable non-understood content, all Markup Compatibility elements
and attributes, and all elements and attributes in subsumed namespaces.'
No. Bluntly untrue. While some consumers may be implemented using that
technique, a conformant consumer/producer which is asked to store the
contents it does not understand won't be able to do so if the preprocessor
handles it data that is free of non-understood content. Note the
'pipelined' word above, which precludes the use of the preprocessor on a
derived data-flow. We understand that the preprocessing analogy will make it easier for some readers to grasp the intents of the specification, and that it may help some implementors to develop peculiar conformant consumers. However, the formulation in the text is logically broken, must therefore be refined or removed, and is due, unless improved, to bring much confusion. |
If the preprocessor is an analogy to help understand the concepts, clearly say so in the text, and acknowledge that, while mapping the said analogy into an implementation can deliver a conforming application provided some conditions are met, it is not able to account for the totality of the specification without changes (namely, the pipeline design is critical). | |
F5029 | Part 5, Section 8.2 Markup Compatibility Namespace | page 3, line 4 | te | TEMPLATE | ||
F5029 | Part 5, Section 8.2 Markup Compatibility Namespace | page 3, line 4 | te | TEMPLATE | ||
F5030 | Part 5, Section 8.2 Markup Compatibility Namespace | page 10, line 21 | te | Per Namespaces in XML 1.0 (Second Edition) W3C
Recommendation 16 August 2006,
'http://schemas.openxmlformats.org/markup-compatibility/2006' is not
a namespace, but a namespace name, which is far from being enough to
describe a namespace at the needed level for an XML format specification.
The 'The following is the Markup Compatibility namespace:' expression of
the OOXML text still pretends that
'http://schemas.openxmlformats.org/markup-compatibility/2006' is the
Markup Compatibility namespace. This is at best bad writing. This may come from the facts that the authors included a (broken) link to a web page - this is not recognizable on a printed page, but the PDF file of the package submitted to our examination - and that will make reference for our vote - has it. This might lead to the observation that the intent of the author was in fact to define the namespace by the contents of a remote web page, which is not acceptable. (And is the reason why we insist that this comment be of technical nature). |
Clarify. | |
F5031 | Part 5, Section 8.2 Markup Compatibility Namespace | page 10, line 24 | ed | The 'The elements and attributes described in this specification are contained in the Markup Compatibility namespace.' sentence is far too lax a formulation in the context of a specification. defined should be preferred to described, and the formulation suggests that the namespace may include other elements and attributes that Part 5 would not define, which is probably not the intent of the writer. | State squarely that the elements and attributes defined by Part 5 of the OOXML text are (exactly) those of the Markup Compatibility namespace. | |
F5032 | Part 5, Section 8.2 Markup Compatibility Namespace | page 10, line 24 | te | Does 'markup in non-understood namespaces' refer to markup definitions in namespaces met while validating parsers read namespace definitions, or else to markup which elements, attributes, entities, etc. are defined by specific namespaces, deemed as 'non-understood' by the specification? | Clarify. | |
F5033 | Part 5, Section 9 Markup Compatibility Attributes and Elements | page 11, line 8 | te | 'Whitespace characters' in the normative text is left undefined by the non-normative note of lines 4-7. | Integrate the content of the note into the normative text. | |
F5034 | Part 5, Section 9 Markup Compatibility Attributes and Elements | page 11, line 8 | te | The 'shall be normalized by markup consumers before processing' proposition is non-sensical, since normalization is a processing. | Clarify. | |
F5035 | Part 5, Section 9 Markup Compatibility Attributes and Elements | page 11, line 14 | ed | The current formulation states that tables 9.1 and 9.2 'are further described in the sub-clauses that follow', whereas what is most probably meant is that the attributes and elements are further described in the said sub-clauses. | Reword. | |
F5036 | Part 5, Section 9 Markup Compatibility Attributes and Elements | page 11, line 15 | te | The OOXML text defines nothing as an 'element-qualified name[s]', neither does the XML specification, nor the the XML Schema specification. The definition for the ProcessContent attribute is consequently broken. | Define 'element-qualified name' or else fix the definition of the ProcessContent attribute by other means. | |
F5037 | Part 5, Section 9.1.2 ProcessContent Attribute | page 15, line 13 | te | The OOXML text defines nothing as an 'element-qualified name[s]', neither does the XML specification, nor the the XML Schema specification. The definition for the ProcessContent attribute is consequently broken. | Define 'element-qualified name' or else fix the definition of the ProcessContent attribute by other means. | |
F5038 | Part 5, Section 9.1.2 ProcessContent Attribute | page 15, line 16 | ed | Missing of in 'that the content all elements in the namespace shall be processed'. | Replace with 'that the content of all elements in the namespace shall be processed'. | |
F5039 | Part 5, Section 9.1.2 ProcessContent Attribute | page 15, lines 17-20 | te | The 'A markup consumer that encounters an ignored element whose expanded name matches the expanded name of an element identified in the ProcessContent attribute value, the markup consumer shall consider that element to be a processed element, regardless of whether or not the element’s qualified name matches the qualified name specified in the ProcessContent attribute value.' sentence is non-sensical. The definition for the ProcessContent attribute is consequently broken. | Provide a proper definition for the ProcessContent attribute. | |
F5040 | Part 5, Section 9.1.2 ProcessContent Attribute | page 15, line 25 | te | Empty ProcessContent attributes only add clutter in conformant documents (since there processing is neutral). They should be precluded by the specification, or at least discouraged (canonicity). | Forbid (preferred) or discourage the use of empty ProcessContent attributes. | |
F5041 | Part 5, Section 9.1.2 ProcessContent Attribute | page 15, lines 27-31 | te | The refinement consisting in allowing
conforming consumers to stay silent (at their will) in front of documents
produced by non-conforming producers (that would violate the rule that no
element should be identified by a ProcessContent attribute and have an
xml:lang or xml:space attribute) only complexifies the specification, for
dubious (and undocumented) benefits. It would be much clearer and simpler to state that conformant documents should not include elements that are identified by a ProcessContent attribute and have an xml:lang or xml:space attribute. |
Replace by a clear statement about conformant documents, or else provide a rationale for the unneeded sophistication introduced here. | |
F5042 | Part 5, Section 9.1.4 MustUnderstand Attribute | page 18, line 19 | ed | Missing white space in 'containsa'. | Replace with 'contains a'. | |
F5043 | Part 5, Section 9.1.4 MustUnderstand Attribute | page 18, line 22 | te | Those two lines seem to provide, under the disguise of a contraint, the true formal definition of what an understood namespace is meant to be in the text. They show that the notion of understood workspace is to be defined for each conformant consumer, and that the way a consumer defines which namespaces it understands is by not raising any kind of 'non-understood' error on MustUnderstand attributes that reference the said namespaces. Contrast this with the fuzzy, unacceptable way understood namespaces are defined page 4, line 1. The latter draws upon ill-undefined, lax terms like 'recognize', whereas the former, while still lacking the proper behavioral model several comments ask for, makes a clear formal, measurable and unambiguous statement of what a consumer should do when presented given contents. | Rework the formal definition of understood namespaces from the information given here as a constraint. (Would start by defining non-understood namespaces, then define understood namespaces by difference with the set of currently available namespaces.) Leverage the resulting definition consistently throughout the OOXML text. | |
F6000 | 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 | 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 | |
F6001 | 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 | Clarify the status of this annex | |
F6002 | 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 | Clarify the status of this annex | |
F6003 | 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 | Clarify the status of this annex | |
F6004 | 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 | Clarify the status of this annex | |
F6005 | 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 | 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 | |
F6006 | 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 | 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 | |
F6007 | 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 | Clarify the status of this annex | |
F6008 | 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 | Clarify the status of this annex | |
F6009 | 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 | Clarify the status of this annex | |
F6010 | 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 | Clarify the status of this annex | |
F6011 | OfficeOpenXML-XMLSchema.zip | - | ge | This annex was not provided in a humanly-readable format as required by JTC1 Directives 8.3.5 and Annex H | 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 | |
F6012 | OpenPackagingConventions-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 | Clarify the status of this annex | |
F6013 | OpenPackagingConventions-RELAXNG.zip | - | ge | This annex was not provided in a humanly-readable format as required by JTC1 Directives 8.3.5 and Annex H | 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 | |
F6014 | OpenPackagingConventions-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 | Clarify the status of this annex | |
F6015 | OpenPackagingConventions-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 | Clarify the status of this annex | |
F6016 | OpenPackagingConventions-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 | Clarify the status of this annex | |
F6017 | OpenPackagingConventions-XMLSchema.zip | - | ge | This annex was not provided in a humanly-readable format as required by JTC1 Directives 8.3.5 and Annex H | 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 |
Annex - Suggested Factorization for submitted Comments Analysis
Relates to the following comments: 4002, 5013, 6000, 6001, 60022, 6003, 60043, 6005, 6006, 6007, 60084, 6009, 60105, 6011, 6012, 6013, 60146, 6015, 60167, 6017
Relates to the following comments: 1006, 1007, 1008, 1009, 1010, 1011, 1012, 1015, 1032, 2002, 4004, 4005, 4046, 4047, 4124, 4133, 4136, 4382, 4383, 4388, 4389, 4391, 4392, 4394, 4395, 4397, 4398, 4400, 4401, 4402, 4403, 4404, 4414, 4415, 4416, 4417, 4418, 4421, 4422, 5003, 5004, 5006, 5008, 5009, 5010, 5011, 5012, 5017, 5018, 5019, 5020, 5021, 5022, 5023, 5024, 5026, 5027, 5028,
Relates to the following comment: 4336
Relates to the following comments: 4149, 4150
Relates to the following comments: 4151, 4154, 4155, 4156, 4157, 4158, 4302, 4317, 4344, 4345 (WEEKDAY), 4419, 4491 (YEARFRAC), 4504 (DATEVALUE), 4507 (DAY), 4516
See also 4514 (NETWORKDAYS)
Relates to the following comments: 4331, 4332, 4333, 4335, 4337, 4338
Relates to the following comment: 1028
Relates to the following comments: 4035 (autoSpaceLikeWord95, Emulate Word 97 Text Wrapping Around Floating Objects), 4036 (footnoteLayoutLikeWW8, Emulate Word 6.x/95/97 Footnote Placement), 4037 (lineWrapLikeWord6, Emulate Word 6.x/95/97 Footnote Placement), 4038 (mwSmallCaps, Emulate Word 5.x for the Macintosh Small Caps Formatting), 4039 (shapeLayoutLikeWW8, Emulate Word 97 Text Wrapping Around Floating Objects), 4040 (suppressTopSpacingWP, Emulate WordPerfect 5.x Line Spacing), 4041 (suppressTopSpacingWP , Emulate WordPerfect 5.x Line Spacing), 4042 (useWord2002TableStyleRules, Emulate Word 2002 Table Style Rules), 4043 (useWord97LineBreakRules, Emulate Word 97 East Asian Line Breaking), 4044 (wpJustification, Emulate WordPerfect 6.x Paragraph Justification), 4045 (wpSpaceWidth, Space width
Relates to the following comments: 1019, 1020
In addition to grouped comments hereafter, relates to the following comments: 4379, 4393, 4442
Relates to the following comment: 4369
In addition to grouped comments hereafter, relates to the following comments: 4049, 4050
Relates to the following comments: 4171 (cnfStyle, Paragraph Conditional Formatting), 4173 (cnfStyle, Table Cell Conditional Formatting), 4174 (cnfStyle, Table Row Conditional Formatting), 4175 (cnfStyle, Table Row Conditional Formatting), 4176 (tblLook, Table Style Conditional Formatting Settings Exception), 4177 (sig, Supported Unicode Subranges and Code Pages), 4182 (stylePaneFormatFilter, Suggested Filtering for List of Document Styles), 4183 (stylePaneSortMethod, Suggested Sorting for List of Document Styles), 4363 (group , Shape Group)
Relates to the following comment: 1024
Relates to the following comments: 4433 (ACOS), 4434 (AND), 4435 (AND), 4436 (ASC), 4437 (ASIN), 4438 (ATAN), 4439 (ATAN2), 4440 (PI), 4441 (PI), 4445, 4446, 4447 (DURATION), 4448 (EXACT), 4449 (FALSE), 4450 (FALSE), 4451 (FINDB), 4452 (FINV),4453 (FIXED), 4455 (GAMMAINV), 4456 (HOUR), 4457 (HYPERLINK), 4459 (AVEDEV), 4460 (AVEDEV), 4461 (IRR), 4462 (KURT), 4464 (LOWER), 4465 (MDURATION), 4466 (MEDIAN), 4467 (MEDIAN), 4468 (NORMINV), 4469 (NORMSINV), 4470 (OR), 4473 (SEARCH), 4474 (SEARCHDB), 4475 (SIN), 4482 (T), 4483 (TAN), 4488 (CELL), 4489 (WORKDAY), 4490 (YEARFRAC), 4493 (CHIINV), 4494 (CHITEST), 4495 (CONFIDENCE), 4496 (CONVERT), 4498 (COS), 4500 (CUBEKPIMEMBER), 4501 (CUBEKPIMEMBER), 4502 (CUBEKPIMEMBER), 4503 (CUBEKPIMEMBER), 4505 (DAVERAGE), 4506 (DAVERAGE), 4508 (DEVSQ), 4509 (DISC), 4510 (DOLLAR), 4511 (DOLLAR), 4512 (DOLLARDE), 4513 (DOLLARFR), 4514 (NETWORKDAYS)
Relates to the following comments: 4454 (FORECAST), 4458 (INTERCEPT), 4463 (LINEST), 4471 (PEARSON), 4472 (RSQ), 4476 (SLOPE), 4477 (STDEV), 4478 (STDEVA), 4479 (STDEVP), 4480 (STDEVPA), 4481 (STEYX), 4484 (VAR), 4486 (VARP), 4487 (VARPA), 4497 (CORREL), 4499 (COVAR)
Relates to the following comments: 4368 (ST_CF), 4372, 4373, 4374, 4375
Relates to the following comments: 4313, 4314
Relates to the following comments: 4319, 4320, 4321, 4322, 4323, 4324
Relates to the following comments: 4051 (AIUEO, aiueo), 4057 (ARABICABJAD, arabicAbjad), 4058 (CHINESENUM1, chineseCounting), 4061 (ARABICALPHA, arabicAlpha), 4063 (ARABIC, decimal), 4066 (ArabicDash, numberInDash), 4067 (DBNUM2, koreanCounting), 4068 (CHINESENUM2, chineseLegalSimplified), 4069 (DBNUM1, ideographDigital), 4070 (DBCHAR, decimalFullWidth), 4071 (CHINESENUM3, chineseCountingThousand), 4072 (CHOSUNG, chosung), 4073 (DBNUM4, japaneseDigitalTenThousand), 4075 (DBNUM3, japaneseLegal), 4076 (CIRCLENUM, decimalEnclosedCircle), 4077 (GB1, decimalEnclosedFullstop), 4078 (HEBREW1, hebrew1), 4079 (HEBREW2, hebrew2), 4080 (GB2, decimalEnclosedParen), 4082 (HINDIARABIC, hindiNumbers), 4083 (GRANADA, granada), 4084 (Hex, hex), 4085 (GB4, ideographEnclosedCircle), 4086 (GB3, decimalEnclosedCircleChinese), 4089 (SBCHAR, decimalHalfWidth), 4091 (KANJINUM2, japaneseCounting), 4092 (OrdText, ordinalText), 4093 (HINDILETTER2, hindiConsonants), 4094 (HINDILETTER1, hindiVowels), 4095 (Roman, lowerRoman), 4097 (Roman, upperRoman), 4099 (Ordinaln ordinal), 4102 (HINDICARDTEXT, hindiCounting), 4103 (IROHA, iroha), 4105 (THAIARABIC, thaiNumbers), 4106 (ZODIAC1, ideographTraditional), 4107 (ZODIAC3, ideographZodiacTraditional), 4108 (ZODIAC2, ideographZodiac), 4109 (THAILETTER, thaiLetters), 4110 (VIETCARDTEXT, vietnameseCounting), 4112 (THAICARDTEXT, thaiCounting)
Relates to the following comments: 4054 (Caps), 4059 (CHARFORMAT), 4065 (BATHTEXT), 4074 (DollarText), 4087 (FirstCap), 4088 (KANJINUM1), 4096 (MERGEFORMAT), 4098 (Lower), 4100 (KANJINUM3), 4111 (Upper)
Relates also to the following comments: 4137, 4138, 4139, 4140, 4141, 4142
Relates to the following comments: 4190 (ADDRESSBLOCK), 4195 (ASK), 4200 (AUTHOR), 4201 (AUTONUM), 4202 (AUTONUMLGL), 4203 (AUTONUMOUT), 4204 (AUTOTEXT), 4205 (AUTOTEXTLIST), 4206 (BARCODE), 4207 (BIBLIOGRAPHY), 4209 (BIDIOUTLINE), 4210 (CITATION), 4212 (COMMENTS), 4214 (CREATEDATE), 4215 (DATABASE), 4216 (DATE), 4223 (DOCPROPERTY), 4224 (DOCVARIABLE), 4225 (EDITTIME), 4227 (FILENAME), 4231 (FILESIZE), 4232 (FILLIN), 4233 (FORMCHECKBOX), 4234 (FORMDROPDOWN), 4235 (FORMTEXT), 4237 (GOTOBUTTON), 4238 (GREETINGLINE), 4239 (HYPERLINK), 4241 (IF), 4245 (INCLUDEPICTURE), 4250 (INCLUDETEXT), 4251 (INDEX), 4254 (KEYWORDS), 4255 (LASTSAVEDBY), 4257 (LINK), 4258 (LISTNUM), 4260 (MACROBUTTON), 4261 (MERGEFIELD) , 4264 (MERGEREC), 4265 (MERGESEQ), 4266 (NEXT), 4267 (NEXTIF), 4269 (NOTEREF), 4270 (NUMPAGES), 4272 (NUMWORDS), 4273 (PAGE), 4274 (PAGEREF), 4275 (PRINT), 4276 (PRINTDATE), 4277 (PRIVATE), 4278 (QUOTE), 4279 (RD), 4281 (REF), 4282 (REVNUM), 4283 (SAVEDATE), 4284 (SECTION), 4285 (SECTIONPAGES), 4286 (SEQ), 4289 (SET), 4290 (SKIPIF), 4293 (STYLEREF), 4294 (SUBJECT), 4295 (SYMBOL), 4296 (TA), 4297 (TC), 4300 (TEMPLATE), 4304 (TIME), 4305 (TITLE), 4306 (TOA), 4307 (TOC), 4308 (USERADDRESS), 4310 (USERINITIALS), 4311 (USERNAME), 4312 (XE), 4341 (ADVANCE), 4342 (COMPARE), 4343 (EQ)
Relates to the following comments: 4213
(COMPARE), 4222 (DOCPROPERTY), 4226 (EQ), 4240
(IF), 4249 (INCLUDETEXT), 4252 (INFO),
4256 (LINK), 4259 (MACROBUTTON), 4268 (NEXTIF),
4280 (REF), 4287 (SEQ), 4288 (SET), 4291
(SKIPIF)
*) In accordance with the intent of JTC 1 SWG Directives to introduce this kind of deliverable already used in ISO and IEC
8 This category refers to section 2.5 of the Ecma document entitled “Response Document – National Body Comments from 30-Day Review of the Fast Track Ballot for ISO/IEC DIS 29500 (ECMA-376) Office Open XML File Format”.
9 This sub-category refers to section 2.5.1 of the Ecma document entitled “Response Document – National Body Comments from 30-Day Review of the Fast Track Ballot for ISO/IEC DIS 29500 (ECMA-376) Office Open XML File Format”.
10 This sub-category refers to section 2.5.2 of the Ecma document entitled “Response Document – National Body Comments from 30-Day Review of the Fast Track Ballot for ISO/IEC DIS 29500 (ECMA-376) Office Open XML File Format”
11 This sub-category refers to section 2.5.3 of the Ecma document entitled “Response Document – National Body Comments from 30-Day Review of the Fast Track Ballot for ISO/IEC DIS 29500 (ECMA-376) Office Open XML File Format”
12 This sub-category refers to section 2.5.6 of the Ecma document entitled “Response Document – National Body Comments from 30-Day Review of the Fast Track Ballot for ISO/IEC DIS 29500 (ECMA-376) Office Open XML File Format”
13 This sub-category refers to section 2.5.7 of the Ecma document entitled “Response Document – National Body Comments from 30-Day Review of the Fast Track Ballot for ISO/IEC DIS 29500 (ECMA-376) Office Open XML File Format”
14 This category refers to section 2.6 of the Ecma document entitled “Response Document – National Body Comments from 30-Day Review of the Fast Track Ballot for ISO/IEC DIS 29500 (ECMA-376) Office Open XML File Format”
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 122
ISO electronic balloting commenting template/version 2001-10
|
![]() |
|