Fr
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 amp; 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 78 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 2427 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 2728 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 12 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 821 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 aconsumer 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 anrPr 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 12 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 45 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 1213 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 67 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 78 te The 'As dates and times are numeric8 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 1618 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 1618 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 23. 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 14881489 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 14881489. 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 1516 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 1617 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 14881489. 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 14881489. 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 14881489 (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 2627 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 14881489. 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 14881489. 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 14881489. 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 14881489 (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 14881489. 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 14881489. 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 14881489. 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.