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.


 

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image


 

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

1 Delivery form

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

2 Terminology

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,

3Consistency with Existing ISO and ISO/IEC Standards8 (to be addressed as the OOXML Core requirements)

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

4 Legacy Features (To be addressed as OOXML Extensions requirements)

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

5 Others

Relates to the following comments: 1019, 1020

6 Taking into account existing documented standards (to be addressed as the OOXML Core requirements)

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

7 Formula definition – Part 4, Section 3. 17.7 (to be addressed as both OOXML Core and OOXXML Extensions requirements depending upon the context i.e. NETWORKDAYS)

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)

8 Miscellaneous

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


2 Duplicate of 6001


3 Duplicate of 6003


4 Duplicate of 6007


5 Duplicate of 6009


6 Duplicate of 6012


7 Duplicate of 6015


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


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


Top