oMath stands out as being treated differently in the standard compared to the other topics. It is much lighter-there is less narrative, fewer examples. Some of the comments on the Primer also apply in this Part. In the following, usually one example is given to illustrate each point, but there are others.
Some of the issues stem from the fact that the xml alone is not sufficient to display a mathematical expression. Use is made of implicit semantic knowledge of the characters that form an expression, i.e. which are operators, which are special characters that need to be handled in specific ways and how they behave.
In maths, an expression is not always an equation. If anything, an equation is a maths expression that includes an equal sign, for example. It would be better to use "expression" or "mathematical expression" throughout.
There is no association between maths and the xml being used in oMath. For example, a maths expression is composed of subexpressions but there is no description of how to go from the mathematical structure to the xml (cf presentation markup in MathML).
There is no description of what an operator is and how it is displayed differently to other objects. References are made to such things as "the alignment and manual break properties of operators" but these are not explained.
Inside text, it appears that each character is examined to see which category it belongs to before deciding how it should be displayed. Some characters are recognised as operators or equal signs, for example. Reference is made to the "usual" ones. These need to be listed and defined. For example, "∫" is recognised as the integral sign, , and so satisfies the default for the positioning of its limits. Although "=" is a binary operator, it behaves differently to other binary operators.
How are line breaks determined Is order of precedence considered when deciding
No mention is made of unary operators, for which conventionally, spacing is different to that for binary operators.
No mention is made of invisible operators e.g. Unicode Invisible Times (x2062) and Function Application (x2061). How are they handled
The text mixes the use of "function" and "object". For example, eqArr (Equation-Array Function) "specifies the Equation-Array function, an object …" whereas f (Fraction Function) "specifies the fraction object …". The standard needs to be consistent. In fact, in both cases, the xml element is a constructor for an object comprised of the child elements e.g. f constructs a fraction from a numerator and a denominator. Maybe better names would be "Equation-Array Constructor" and "Fraction Constructor".
Namespaces were designed to remove ambiguity and could have been used effectively for this purpose throughout this standard. For example, to distinguish m:r and w:r, m:ST_OnOff and w:ST_OnOff in lists of parents and children rather than relying on recognising that the section number reference was for a different part of the standard.
Following from this, types, particularly simple types could have been defined the same. m:ST_OnOff is defined as "on" or "off" whereas w:ST_OnOff also allows "1", "0", "true", "false". This type of difference seems to indicate that the "standard" is simply a specification for the currently allowed values used within Office 2007.
Some definitions are given in the Primer which is not normative, but are not in the Language Reference which is normative. These definitions should be included in the Language Reference. For example, the definition of column gap is given in the Primer along with a diagram which makes it precise. Topics in the Language Reference other than Math use diagrams.
Some of the subclauses simply repeat what is in the schema with no other narrative. For example, the description of eqArrPr is one sentence repeating its name and naming two examples of its children. For the topics of the Language Reference other than Math, there is at least one paragraph, an example in the narrative and an example for each attribute in the attribute table.
One of the problems that arises from the structure of this standard, is that elements are dealt with separately. But some elements are related and interact, for example, cGp and cSp which specify the gap between columns and the spacing for columns in an array. There is no infomation on how they should interact.
In some cases the element names are badly chosen. For example, chr is called "Accent Character" whereas it is also used for specifying the character used to group items and for specifying the character used in an n-ary object. A better name would have been "Character".
The n-ary Operator Function is not n-ary, it is ternary. The operator specified by a character such as an integral sign, takes three parameters: a subscript, a superscript and a base expression.
The same description of the val attribute is copied throughout. This leads to some inappropriate examples, e.g. the example for chr shows begChr and EndChr but not chr. The description and example should depend on the context. Similarly for when val is of type ST_OnOff which usually just says "… specifies that the property shall be explicitly applied …".
The examples are sometimes repeated for the same element, first in the narrative and then again in the attributes table, e.g. for begChr.
Some concepts need defining such as alignment points, linear form, professional form, twips, two-dimensional output. What is the syntax for linear form and where can it be used
Defaults are not always specified. Whenever something is optional, the standard should specify what happens when it is omitted. For example, naryPr is optional in nary, so it is not necessary to specify what the operator is. What happens when it is omitted
For completeness, an informative table of the Unicode characters used in the examples would be very helpful.
The standard says that some restrictions are left to Office 2007. For example, trying to have a sum from i=1 to n so that the limits come below and above the sigma, , is acceptable to Word 2007 when it is in its own paragraph, but not when it is inline. When inline, Word 2007 forces them to be subscript and superscript, which isn’t what was required. How is it possible to tell whether this is a bug in Word 2007 or part of the standard
Sometimes table headings are on their own at the bottom of a page and then repeated at the top of the next page. The headings at the bottom of a page need to be deleted.
Unicode characters are given throughout as U+0302, for example. The character that this represents should be identified and displayed.
Some of the issues stem from the fact that the xml alone is not sufficient to display a mathematical expression. Use is made of implicit semantic knowledge of the characters that form an expression, i.e. which are operators, which are special characters that need to be handled in specific ways and how they behave.
In maths, an expression is not always an equation. If anything, an equation is a maths expression that includes an equal sign, for example. It would be better to use "expression" or "mathematical expression" throughout.
There is no association between maths and the xml being used in oMath. For example, a maths expression is composed of subexpressions but there is no description of how to go from the mathematical structure to the xml (cf presentation markup in MathML).
There is no description of what an operator is and how it is displayed differently to other objects. References are made to such things as "the alignment and manual break properties of operators" but these are not explained.
Inside text, it appears that each character is examined to see which category it belongs to before deciding how it should be displayed. Some characters are recognised as operators or equal signs, for example. Reference is made to the "usual" ones. These need to be listed and defined. For example, "∫" is recognised as the integral sign, , and so satisfies the default for the positioning of its limits. Although "=" is a binary operator, it behaves differently to other binary operators.
How are line breaks determined Is order of precedence considered when deciding
No mention is made of unary operators, for which conventionally, spacing is different to that for binary operators.
No mention is made of invisible operators e.g. Unicode Invisible Times (x2062) and Function Application (x2061). How are they handled
The text mixes the use of "function" and "object". For example, eqArr (Equation-Array Function) "specifies the Equation-Array function, an object …" whereas f (Fraction Function) "specifies the fraction object …". The standard needs to be consistent. In fact, in both cases, the xml element is a constructor for an object comprised of the child elements e.g. f constructs a fraction from a numerator and a denominator. Maybe better names would be "Equation-Array Constructor" and "Fraction Constructor".
Namespaces were designed to remove ambiguity and could have been used effectively for this purpose throughout this standard. For example, to distinguish m:r and w:r, m:ST_OnOff and w:ST_OnOff in lists of parents and children rather than relying on recognising that the section number reference was for a different part of the standard.
Following from this, types, particularly simple types could have been defined the same. m:ST_OnOff is defined as "on" or "off" whereas w:ST_OnOff also allows "1", "0", "true", "false". This type of difference seems to indicate that the "standard" is simply a specification for the currently allowed values used within Office 2007.
Some definitions are given in the Primer which is not normative, but are not in the Language Reference which is normative. These definitions should be included in the Language Reference. For example, the definition of column gap is given in the Primer along with a diagram which makes it precise. Topics in the Language Reference other than Math use diagrams.
Some of the subclauses simply repeat what is in the schema with no other narrative. For example, the description of eqArrPr is one sentence repeating its name and naming two examples of its children. For the topics of the Language Reference other than Math, there is at least one paragraph, an example in the narrative and an example for each attribute in the attribute table.
One of the problems that arises from the structure of this standard, is that elements are dealt with separately. But some elements are related and interact, for example, cGp and cSp which specify the gap between columns and the spacing for columns in an array. There is no infomation on how they should interact.
In some cases the element names are badly chosen. For example, chr is called "Accent Character" whereas it is also used for specifying the character used to group items and for specifying the character used in an n-ary object. A better name would have been "Character".
The n-ary Operator Function is not n-ary, it is ternary. The operator specified by a character such as an integral sign, takes three parameters: a subscript, a superscript and a base expression.
The same description of the val attribute is copied throughout. This leads to some inappropriate examples, e.g. the example for chr shows begChr and EndChr but not chr. The description and example should depend on the context. Similarly for when val is of type ST_OnOff which usually just says "… specifies that the property shall be explicitly applied …".
The examples are sometimes repeated for the same element, first in the narrative and then again in the attributes table, e.g. for begChr.
Some concepts need defining such as alignment points, linear form, professional form, twips, two-dimensional output. What is the syntax for linear form and where can it be used
Defaults are not always specified. Whenever something is optional, the standard should specify what happens when it is omitted. For example, naryPr is optional in nary, so it is not necessary to specify what the operator is. What happens when it is omitted
For completeness, an informative table of the Unicode characters used in the examples would be very helpful.
The standard says that some restrictions are left to Office 2007. For example, trying to have a sum from i=1 to n so that the limits come below and above the sigma, , is acceptable to Word 2007 when it is in its own paragraph, but not when it is inline. When inline, Word 2007 forces them to be subscript and superscript, which isn’t what was required. How is it possible to tell whether this is a bug in Word 2007 or part of the standard
Sometimes table headings are on their own at the bottom of a page and then repeated at the top of the next page. The headings at the bottom of a page need to be deleted.
Unicode characters are given throughout as U+0302, for example. The character that this represents should be identified and displayed.
Revise the text to address these comments
7.1
ge
Proposed Disposition of DIS 29500 Comment GB-0495 (Modified: 2008-01-10) Agreed; the following changes will be made: In response to GB-0495, Point 1: There are situations where “expression” is more appropriate than “equation”, such as when describing “b+c”. Conversely, there are also situations where “equation” is more appropriate than “expression”, such as when describing “a=b+c”. An “equation” is not an “expression” and neither is an “expression” an “equation”. This specification originally chose to use the term “equation” universally throughout the Office Open XML specification for any mathematical text even if it were an expression. However, to be clearer, the Math primer in Part 3 now uses the term equation only when appropriate. This is done for Part 3 in the disposition for GB-0113 and CO-0065. We will go through Part 4 and ensure “equation” is used only when appropriate. We will also ensure that “expression”, “formula”, and other mathematical labels are used when they are most appropriate. Here is one example of the changes we will make to Part 4, §7.1, page 4,961, lines 36: The following documentation describes the XML representation of equations , expressions, formulas, and all other strings of mathematical text . T For display equations, t he outermost element is oMathPara, a paragraph of one or more equations strings of mathematical text . Each equation , expression, formula, or other string inside the math paragraph is represented as a single oMath. Inline equations do not use oMathPara elements. They use oMath as their outermost math element. Inside each oMath is a combination of runs (r) and objects or functions (such as accents, acc, or fractions, (f). In response to GB-0495, Point 2: We will add XML examples throughout the Office Open XML Math elements defined in Part 4, §7.1 in order to facilitate the understanding of this text, and to better demonstrate the math’s structure. To illustrate, an example of one such change is as follows, in Part 4, §7.1.2.78, page 5,051, line 8: This element specifies a math paragraph, one or more display equations within a single paragraph. [Example: A math paragraph with two equations: = + = + Example XML: <m:oMathPara> <m:oMath> <m:r> <m:t>a=b+c</m:t> </m:r> <m:r> <w:br /> </m:r> </m:oMath> <m:oMath> <m:r> <m:t>c=d+e</m:t> </m:r> </m:oMath> </m:oMathPara> end example] In response to GB-0495, Points 3, 4, and 5: Descriptions of alignment points have been added in the dispositions for the following issues: GB-0113 GB-0545 Descriptions of line break points have been added in the dispositions for the following issues: GB-0113 GB-0513 Other descriptions of properties have been added in the dispositions for the following issues: GB-0113 GB-0583 In addition, the following change will be made to Part 4, §7.1.2.15, page 4,979, lines 1316: This element specifies whether there is a line break at the start of a run, or at the start of the Box function object , such that the line wraps at the start of the run or function object. These user-defined line breaks occur when the XML tag <m:brk/> is encountered and does not follow a mathematical “order of precedence”. If this element is omitted, a manual break is not inserted. The line may happen to wrap at this point if the equation exceeds the column width. OMML does not specify behaviour for any kind of automatic line breaking. Instead it delegates this functionality to the underlying rendering engine similarly to how it does with the choice of operator spacing and the determination of whether an operator is unary or binary. [Example: The following example includes a manual user-defined line break at the operator emulator: In response to GB-0495, Point 6: The spacing shown around unary operators is not something that is specified in the Office Math Markup Language specification. The spacing around unary operators is specific to the individual math renderer that is rendering the OMML. The definition of spacing around specific operators, unless explicitly specified, is to be implementation-specific. In response to GB-0495, Point 7: OMML does not specify behaviour for the character Unicode Invisible Times (U+2062). For the Function Application character, the following changes will be made to Part 4, §7.1.2.39, page 5,010, lines 13: 7.1.2.39 func (Function Apply Function Object ) This element specifies the Function-Apply function object , which consists of a function name and an argument acted upon. It can be applied, in linear format, by inserting the Function Application character (U+2061). This will build up into a Function Apply Object. [Example: Examples of Function-Apply objects include: sin , tan -1 2 , and max 01 - 2 . In response to GB-0495, Point 8: The term “function” will replaced by the term “object” throughout section 7.1 of part 4 when appropriate. Three examples of this change are shown below. Part 4, §7.1.2.11, page 4,975, lines 1920: borderBox (Border-Box Function Object ) This element specifies the Border Box function object , consisting of a border drawn around an equation, as in 2 + 2 = 2 . Part 4, §7.1.2.13, page 4,977, lines 1516: box (Box Function Object ) This element specifies the box function object , which is used to group components of an equation. Part 4, §7.1.3.18, page 5,1015,102: Enumeration Value Description center (Center) Centers the argument in the containing function object . left (Left Justification) Aligns the argument to the left of the containing function object . right (Right) Aligns the argument to the right of the containing function object . In response to GB-0495, Point 9: We agree that there are editorial improvements which could be made to the parent/child reference format, but based on the submission of several (sometimes conflicting) national body comments on the use of namespace prefixes to disambiguate in this manner, it is unclear that this is the best option. We believe that this an excellent point for discussion and improvement in maintenance, as it does not affect the normative content of the specification and therefore does not need to be immediately addressed. In response to GB-0495, Point 10: Part 4, §7.1 (Math), currently defines the ST_OnOff simple type which is used by a number of attributes. This simple type only allows for “on” and “off”. To be consistent with the rest of the standard, the ST_OnOff simple type will be modified to simply reference the xsd:boolean datatype and provide no additional extensions. For a more detailed description of this change, refer to the disposition for GB-0630. In response to GB-0495, Point 11: Any definitions made in the 7.1 Primer of Part 3 that are intended to be normative will be added to a new Definitions section in Part 4. Any definitions made for the sake of explanation in Part 3, including in the disposition for comments GB-0113 ad CO-0065, that are not reiterated in the normative text of Part 4, after the aforementioned changes are made, are not intended to be normative. In response to GB-0495, Point 12: We will add examples throughout 7.1.2 in order to improve the readability of that content. Refer to the response to Point 2 above for one such example. In response to GB-0495, Point 13 When elements interact with other elements in specifically defined ways, the descriptions for all elements involved will be changed to describe their interactions. Here is an example set of changes for cGp and cSp: cSp is used to set the minimum allowable column width for a matrix. cGpRule and cGp are used to set the minimum column gap. The following changes will be made to explain their interaction: Part 4, §7.1.2.18, page 4,982, line 8: The additional (custom) column gap spacing information; the default is’0′. The cGp gap spacing (also referred to as “Column Gap” or “Gap Width”) is added to the cSp (Minimum Matrix Column Width) to determine the total Matrix Column Spacing (distance between the same edges of different columns). The following image depicts how cGp and cSp work together to define matrix column spacing in a 2×2 matrix: Part 4, §7.1.2.22, page 4,986, line 58: cSp ( Minimum Matrix Column Spacing Width ) This element specifies the minimum spacing between the edge of one column and the corresponding edge of the adjacent column column width of a matrix . The actual column width of a matrix will be the greater of either the width of the column’s widest argument or cSp. This a A dditional spacing can be added to enhance appearance. If this element is omitted, the default is column spacing width is ‘0′. The cGp gap spacing (also referred to as “Column Gap” or “Gap Width”) is added to the cSp (Minimum Matrix Column Width) to determine the total Matrix Column Spacing (distance between the same edges of different columns). The following image depicts how cGp and cSp work together to define matrix column spacing in a 2×2 matrix: In response to GB-0495, Point 14: Element names will be changed to make them more appropriate. For chr specifically, the disposition for comment GB-0522 changes the element name exactly as the commenter has suggested. In response to GB-0495, Point 15: N-ary operators are “n-ary” not because of the limits and base, but because n-ary objects involve n terms when expanded. Specifically the term comes from equations like: =1 1 + 2 + + which has terms. Since the actual number of terms can vary, one simply calls them n-ary. For instance, the above example uses the Unicode (ISO 10646) summation sign (U+2211) which has the official name “N-ARY SUMMATION”. In response to GB-0495, Point 16: The descriptions for the “val” attributes of elements will be changed to be appropriate and specific to their parent element. One such change for chr will be made as follows in Part 4, §7.1.2.20, page 4,985, line 2: Attributes Description val (value) Specifies the character used by the parent element. When it is omitted, the parent uses its assigned default. [Example: delimiter object Accent character {a} : <m:accPr> <m:chr m:val="̃"/> </m:accPr> <m:dPr> <m:begChr m:val="{"/> <m:endChr m:val="}"/> </m:dPr> The possible values for this attribute are defined by the ST_Char simple type (§7.1.3.3). In response to GB-0495, Point 17: Examples will be changed in Section 7.1 of Part 4 such that they are always unique and informative. Refer to the response to Point 16 above for one such change. In response to GB-0495, Point 18: Definitions and references to definitive documentation for alignment points, linear form, professional form, twips, and other terms used in Part 4 have been added in multiple dispositions. Alignment points were defined (both in normative and non-normative context) more in the dispositions for GB-0113 and GB-0545. “Linear form” and “professional form” were discussed and externally referenced in the disposition for GB-0535. Twips were defined in the disposition for GB-0534. The syntax for “linear form” is not defined in the OpenXML spec. It is defined in Unicode Technical Article #28 ( http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v2.pdf ). The spec will be further modified to refer to this article when needed. In addition, normative definitions will be added to the new Definitions section in Part 4. In response to GB-0495, Point 19: The defaults for all elements will be added. See the disposition for GB-0547 for an example of this change. In response to GB-0495, Points 20 and 23: We will add parenthetical labelling to all Unicode characters used in examples which are new to Unicode 5.0. This labelling will look like: U+0302 (COMBINING CIRCUMFLEX ACCENT) This exact labelling can be seen in the disposition for GB-0499. In response to GB-0495, Point 21: If “Word 2007″ deviates from the behaviours described in Section 7.1 of Part 4 of this standard then “Word 2007″ is not implementing that behaviour properly (read: in a valid way). If this was an unintentional deviation then this would likely be regarded as a bug in that application. Also, it is an industry standard convention that inline n-ary limits are displayed as subscripts and superscripts. In response to GB-0495, Point 22: Lone table headings at the bottom of the page will be removed. One such example is shown in the disposition for GB-0539.
