[NOTE: This records dispositions of comments received during the Last Call period ending 11 November 2009. The dispositions of comments received during the Second Last Call from 10 June 2010 to 1 July 2010 are noted in a separate document.]
27 comments of which 26 fully resolved, 1 resolved but not yet formally accepted and 0 unresolved.
The MathML 3.0 Specification Last Call draft has received a number of comments. Most are not controversial, and we have done our best to accomodate them. Some involved more substantive issues, and provoked a good deal of discussion between the Math WG and the originators of the comments. In most cases, a consensus opinion has emerged, but what differences remain is made plain below.
We itemize the comments received and the Math WG responses. This is presently a dynamic page and will remain so until the end of dealing with all the Last Call comments received during the announced period ending on 11 November 2009.
The dispensation of non-controversial comments and suggestions is noted briefly in this document, with references to email detailing the changes to the MathML 3 WD. In the case of more substantive issues, a discussion is given below describing the background and the resolution proposed by the Math WG.
| Schema |
|
| Summary: | The math element explicitly lists "dir" as an attribute. |
| Submitted: | Neil Soiffer,
http://lists.w3.org/Archives/Public/www-math/2009Sep/0019.html |
| Response: | Bruce R. Miller,
http://lists.w3.org/Archives/Public/www-math/2009Nov/0016.html |
| Discussion: |
Nail says: The math element explicitly lists "dir" as an attribute. However, the math element also accepts everything accepted by mstyle. Because mstyle also lists 'dir', 'dir' is effectively listed twice in the schema for the math element. I think the explicit listing on the math element should be removed. The dir attribute has been removed from the list of attributes specific to the <math> element, but since it is particularly useful on this element, (moreso than on mstyle, from which it is inherited) it is explicitly mentioned in the introductory sentence. |
| Resolution: | Remove dir from math element attributes in Chapter 2 in the table
in 2.2.1. It was included twice in schema because it was there (and thus an inherited attribute)
and on mstyle. The text has been reworded above the table.
Checking in spec/xml/fundamentals.xml; /w3ccvs/WWW/Math/Group/spec/xml/fundamentals.xml,v <-- fundamentals.xml new revision: 1.126; previous revision: 1.125 |
| Summary: | altimg-valign missing "top", etc in schema |
| Submitted: | Neil Soiffer ,
http://lists.w3.org/Archives/Public/www-math/2009Sep/0027.html |
| Response: | David Carlisle,
http://lists.w3.org/Archives/Public/www-math/2009Sep/0029.html |
| Discussion: | Thanks, fixed.
|
| Resolution: | Resolved
$ cvs commit -m "altimg-valign attribute " mathml3-common.rnc Checking in mathml3-common.rnc; /w3ccvs/WWW/Math/Group/RelaxNG/mathml3/mathml3-common.rnc,v <-- mathml3-common.rnc new revision: 1.31; previous revision: 1.30 |
| Summary: | Break out deprecated token attrs from mstyle in schema |
| Submitted: | Neil Soiffer ,
http://lists.w3.org/Archives/Public/www-math/2009Sep/0026.html |
| Response: | David Carlisle,
http://lists.w3.org/Archives/Public/www-math/2009Sep/0030.html |
| Discussion: | Fixed.
|
| Resolution: | I've updated the editors draft at
http://monet.nag.co.uk/~dpc/draft-spec/appendixa.html#parsing_mstyle
$ cvs commit -m mstyle.deprecatedattributes schema.xsl Checking in schema.xsl; /w3ccvs/WWW/Math/Group/spec/xml/schema.xsl,v <-- schema.xsl new revision: 1.62; previous revision: 1.61 done |
| Presentation |
|
| Summary: | In section 3.2.5.8.2 "Vertical Stretching Rules", it is indicated that ∑ and ∫ stretch vertically by default. |
| Submitted: | Frédéric Wang,
http://lists.w3.org/Archives/Public/www-math/2009Sep/0020.html |
| Response: | Neil Soiffer,
http://lists.w3.org/Archives/Public/www-math/2009Sep/0023.html Neil Soiffer, http://lists.w3.org/Archives/Public/www-math/2009Sep/0026.html |
| Discussion: |
Frédéric says: In section 3.2.5.8.2 "Vertical Stretching Rules", it is indicated that ∑ and ∫ stretch vertically by default. However, the operator dictionary does not define these symbols as stretchy. Hence I suggest to remove from Chapter 3 the requirement that sum and int stretch vertically. Answer: Thank you for your comment. This has been resolved by changing "Most common opening and closing fences are defined in the operator dictionary to stretch by default; and they stretch vertically. Also, operators such as ∑, ∫, /, and vertical arrows stretch vertically by default. " to say: "By default, most vertical arrows, along with most opening and closing fences are defined in the operator dictionary to stretch by default." |
| Resolution: | /w3ccvs/WWW/Math/Group/spec/xml/presentation-markup.xml,v revision: 1.272 |
| Summary: | Add a notion of "natural" direction for operators to prevent weird stretching. [Section 3.2.5.8] |
| Submitted: | Frédéric Wang,
http://lists.w3.org/Archives/Public/www-math/2009Sep/0021.html |
| Response: | Neil Soiffer,
http://lists.w3.org/Archives/Public/www-math/2009Nov/0066.html Frédéric Wang, http://lists.w3.org/Archives/Public/www-math/2009Nov/0067.html |
| Discussion: | There is often a natural direction in which to stretch a character, for
instance for an arrow. The querier suggested that this be in the operator dictonary.
There is no consensus on how stretching works. Thus the stretchy attribute is
intentionally underspecified. Note stretching is not the same as scaling.
|
| Resolution: |
The WG discussed your ideas and agreed with you that the text could use some clarification that stretchy="true" does not require stretching a character in all possible directions. The new language is: "There is no provision in MathML for specifying in which direction (horizontal or vertical) to stretch a specific character or operator; rather, when stretchy="true" it should be stretched in each direction for which stretching is possible and reasonable for that character. It is up to the renderer to know in which directions it is reasonable to stretch a character, if it can stretch the character." /w3ccvs/WWW/Math/Group/spec/xml/presentation-markup.xml,v <-- presentation-markup.xml new revision: 1.306; previous revision: 1.305 |
| Summary: | Content model of mlabeldtr. [Sections 3.1.3.2, 3.5.3.1 and 3.5.2] |
| Submitted: | David Carlisle,
http://lists.w3.org/Archives/Public/www-math/2009Sep/0022.html |
| Response: | David Carlisle,
http://lists.w3.org/Archives/Public/www-math/2009Sep/0025.html |
| Discussion: |
The content model of mlabeldtr has been fixed in the schema It now allows the attributes of mtr to match the text of chapter 3 the extracted schema now shows:
mlabeledtr = element mlabeledtr {mlabeledtr.attributes, TableCellExpression+}
mlabeledtr.attributes = mtr.attributes
I've updated the schema at /Math/RelaxNG/mathml3/mathml3-presentation.rnc |
| Resolution: | $ cvs commit -m "mlabeledtr attributes" schema.xsl Checking in schema.xsl; /w3ccvs/WWW/Math/Group/spec/xml/schema.xsl,v <-- schema.xsl new revision: 1.60; previous revision: 1.59 done |
| Summary: | Philosophy behind the paragraph on @mathvariant. [http://www.w3.org/TR/MathML3/chapter3.html#presm.commatt] |
| Submitted: | Jacques Distler,
http://lists.w3.org/Archives/Public/www-math/2009Sep/0024.html |
| Response: | Sam Dooley,
http://lists.w3.org/Archives/Public/www-math/2009Oct/0019.html Karl Tomlinson, http://lists.w3.org/Archives/Public/www-math/2009Nov/0073.html David Carlisle, http://lists.w3.org/Archives/Public/www-math/2009Nov/0074.html |
| Discussion: | Karl Tomlinson,
http://lists.w3.org/Archives/Public/www-math/2009Sep/0034.html Sam Dooley, http://lists.w3.org/Archives/Public/www-math/2009Sep/0037.html Jacques Distler, http://lists.w3.org/Archives/Public/www-math/2009Oct/0000.html Jacques Distler, http://lists.w3.org/Archives/Public/www-math/2009Oct/0010.html Karl Tomlinson, http://lists.w3.org/Archives/Public/www-math/2009Oct/0020.html William F. Hammond, http://lists.w3.org/Archives/Public/www-math/2009Oct/0021.html Sam Dooley, http://lists.w3.org/Archives/Public/www-math/2009Oct/0023.html Sam Dooley, http://lists.w3.org/Archives/Public/www-math/2009Oct/0024.html http://www.w3.org/TR/MathML3/chapter7.html#chars.BMP-SMP |
| Resolution: | Sam Dooley,
http://lists.w3.org/Archives/Public/www-math/2009Nov/0068.html Changed the text in sections 3.2.2 and 7.5 that describes mathvariant to be more inclusive of other combinations, including bold italic dotless i/j and Greek digammas, without mandating which combinations a renderer should visually distinguish. Changed the text to be more specific about when certain combinations of character data and mathvariant values are equivalent to assigned Unicode code points that encode mathematical alphanumeric symbols. Section 7.5 has been fixed to enumerate the characters that represent holes in the plane 1 alphabetic sequences. In principle, any mathvariant value may be used with any character data to define a specific symbolic token. In practice, only certain combinations of character data and mathvariant values will be visually distinguished by a given renderer. The references in section 7.5 to Unicode 3.1 have been changed to ensure that the definition of mathvariant does not depend on a specific version of Unicode. Partially resolved with improved wording for section 3.2.2. Checking in presentation-markup.xml; /w3ccvs/WWW/Math/Group/spec/xml/presentation-markup.xml new revision: 1.281; previous revision: 1.280 Section 7.5 gets updated to track changes in section 3.2.2. Checking in character-set.xsl; /w3ccvs/WWW/Math/Group/spec/xml/character-set.xml,v <-- character-set.xml new revision: 1.106; previous revision: 1.105 done |
| Summary: | Image of the actuarial example does not match up the MathML source [Section 3.3.9.3] |
| Submitted: | Frédéric Wang,
|
| Response: | David Carlisle,
http://lists.w3.org/Archives/Public/www-math/2009Sep/0033.html Neil Soiffer, http://lists.w3.org/Archives/Public/www-math/2009Sep/0036.html |
| Discussion: | Thanks for catching that. As David said, that's been there since MathML 2.
The image has been updated (see attached).
|
| Resolution: | Checking in presentation-markup.xml; /w3ccvs/WWW/Math/Group/spec/xml/presentation-markup.xml,v <-- presentation-markup.xml new revision: 1.273; previous revision: 1.272 RCS file: /w3ccvs/WWW/Math/Group/draft-spec/image/actuarial.eps,v done Checking in image/actuarial.eps; /w3ccvs/WWW/Math/Group/draft-spec/image/actuarial.eps,v <-- actuarial.eps initial revision: 1.1 done RCS file: /w3ccvs/WWW/Math/Group/draft-spec/image/actuarial.png,v done Checking in image/actuarial.png; /w3ccvs/WWW/Math/Group/draft-spec/image/actuarial.png,v <-- actuarial.png initial revision: 1.1 |
| Summary: | Last mpadded example is wrong |
| Submitted: | Neil Soiffer,
http://lists.w3.org/Archives/Public/www-math/2009Sep/0038.html |
| Response: | Neil Soiffer,
http://lists.w3.org/Archives/Public/www-math/2009Oct/0009.html |
| Discussion: |
The last mpadded example: <mrow> <mi>x</mi> <mpadded lspace="0.3em" width="+0.6em"> <mi>y</mi> </mpadded> <mi>z</mi> </mrow>should have lspace="+0.3em" to be in sync with the picture above it. There was some disagreement/confusion as to the meanings of bounding box and "visual positioning point". The consensus conclusion was to make those more clear so that lspace='+.3em' is the same as '.3em' and so no change is necessary to the example. Some rewriting to the description of the attributes was done. The new section reads: 3.3.6.3 Meanings of size and position attributes See Appendix D Glossary<file:///C:/Soiffer/MathML3%20Spec/WWW/Math/Group/draft-spec/appendixd.html>for definitions of some of the typesetting terms used here. The content of an mpadded element defines a fragment of mathematical notation, such as a character, fraction, or expression, that can be regarded as a single typographical element with a natural positioning point relative to its natural bounding box. The size of the bounding box of an mpadded element is defined as the size of the bounding box of its content, except as modified by its height, depth, and width attributes. The natural positioning point of the child content of the mpadded element is located to coincide with the natural positioning point of the mpadded element, except as modified by the lspace and voffsetattributes. Thus, the size attributes of mpadded can be used to expand or shrink the apparent bounding box of its content, and the position attributes of mpadded can be used to move the content relative to the bounding box (and hence also neighboring elements). Note that MathML doesn't define the precise relationship between "ink", bounding boxes and positioning points, which are implementation specific. Thus, absolute values for mpadded attributes may not be portable between implementations. The height attribute specifies the vertical extent of the bounding box of the mpadded element above its baseline. Increasing the height increases the space between the baseline of the mpadded element and the content above it, and introduces padding above the rendering of the child content. Decreasing the height reduces the space between the baseline of the mpadded element and the content above it, and removes space above the rendering of the child content. Decreasing the height may cause content above the mpadded element to overlap the rendering of the child content, and should generally be avoided. The depth attribute specifies the vertical extent of the bounding box of the mpadded element below its baseline. Increasing the depth increases the space between the baseline of the mpadded element and the content below it, and introduces padding below the rendering of the child content. Decreasing the depth reduces the space between the baseline of the mpadded element and the content below it, and removes space below the rendering of the child content. Decreasing the depth may cause content below the mpadded element to overlap the rendering of the child content, and should generally be avoided. The width attribute specifies the horizontal distance between the positioning point of the mpadded element and the positioning of point of the following content. Increasing the width increases the space between the positioning point of the mpadded element and the content that follows it, and introduces padding after the rendering of the child content. Decreasing the width reduces the space between the positioning point of the mpaddedelement and the content that follows it, and removes space after the rendering of the child content. Setting the width to zero causes following content to be positioned at the positioning point of the mpadded element. Decreasing the width should generally be avoided, as it may cause overprinting of the following content. The lspace attribute specifies the horizontal location of the positioning point of the child content with respect to the positioning point of the mpadded element. By default they coincide, and therefore absolute values for lspace have the same effect as relative values. Positive values for the lspace attribute increase the space between the preceding content and the child content, and introduce padding before the rendering of the child content. Negative values for the lspace attributes reduce the space between the preceding content and the child content, and may cause overprinting of the preceding content, and should generally be avoided. Note that the lspaceattribute does not affect the width of the mpadded element, and so the lspace attribute will also affect the space between the child content and following content, and may cause overprinting of the following content, unless the width is adjusted accordingly. The voffset attribute specifies the vertical location of the positioning point of the child content with respect to the positioning point of the mpadded element. Positive values for the voffset attribute raise the rendering of the child content above the baseline. Negative values for the voffset attribute lower the rendering of the child content below the baseline. In either case, the voffset attribute may cause overprinting of neighboring content, which should generally be avoided. Note that the voffset attribute does not affect the height or depth of the mpaddedelement, and so the voffset attribute will also affect the space between the child content and neighboring content, and may cause overprinting of the neighboring content, unless the height or depth is adjusted accordingly. MathML renderers should ensure that, except for the effects of the attributes, the relative spacing between the contents of the mpadded element and surrounding MathML elements would not be modified by replacing an mpadded element with an mrow element with the same content, even if linebreaking occurs within the mpadded element. MathML does not define how non-default attribute values of an mpadded element interact with the linebreaking algorithm. |
| Resolution: |
Resolved by changing the text and not the example: /w3ccvs/WWW/Math/Group/spec/xml/presentation-markup.xml,v revisions 1.278 & 1.279 |
| Summary: | Clarification of inline math |
| Submitted: | Bruce Miller,
http://lists.w3.org/Archives/Public/www-math/2009Oct/0031.html |
| Response: | Bruce Miller,
http://lists.w3.org/Archives/Public/www-math/2009Oct/0033.html |
| Discussion: | Seemingly uncontroversial; I've adapted the above to
the discussion of math's display attribute. Also added was a link to Chapter 2 from the MathML+XHTML
discussion in Chapter 6.
|
| Resolution: | Checking in spec/xml/fundamentals.xml; /w3ccvs/WWW/Math/Group/spec/xml/fundamentals.xml,v <-- fundamentals.xml new revision: 1.125; previous revision: 1.124 Checking in spec/xml/world-interaction.xml; /w3ccvs/WWW/Math/Group/spec/xml/world-interaction.xml,v <-- world-interaction.xml new revision: 1.58; previous revision: 1.57 |
| Summary: | mlongdiv example has a mistake [Section 3.6.8.3] |
| Submitted: | Neil Soiffer,
http://lists.w3.org/Archives/Public/www-math/2009Sep/0040.html |
| Response: | Neil Soiffer,
http://lists.w3.org/Archives/Public/www-math/2009Oct/0001.html |
| Discussion: | Fixed |
| Resolution: | Checking in presentation-markup.xml; /w3ccvs/WWW/Math/Group/spec/xml/presentation-markup.xml,v <-- presentation-markup.xml new revision: 1.274; previous revision: 1.273 |
| Summary: | Clarify how a missing divisor or result are given for mlongdiv |
| Submitted: | Neil Soiffer,
http://lists.w3.org/Archives/Public/www-math/2009Oct/0007.html |
| Response: | Neil Soiffer,
http://lists.w3.org/Archives/Public/www-math/2009Nov/0046.html |
| Discussion: |
The spec is silent on what should happen if the last row of an mstack is an mscarries that has 'location' not equal to 'n' (ie, that wants to display as an adornment to to the following row). A similar problem happens when 'crossout' is not equal to 'none' (nothing to cross out). I propose adding the following paragraph to the end of 3.6.5.2: If mscarries is the last row in an mstack or mlongdiv, then any carries or crossouts that would normally be drawn on the following line are ignored and not should not be drawn. |
| Resolution: | The working group agreed that these should be consistent and so the text and
examples were changed.
/w3ccvs/WWW/Math/Group/spec/xml/presentation-markup.xml,v <-- presentation-markup.xml new revision: 1.300; previous revision: 1.299 |
| Summary: | mpadded attr example has a space it shouldn't |
| Submitted: | Neil Soiffer,
http://lists.w3.org/Archives/Public/www-math/2009Sep/0041.html |
| Response: | Neil Soiffer,
http://lists.w3.org/Archives/Public/www-math/2009Oct/0008.html |
| Discussion: |
The second mpadded example is:
The width value "+90% width" has a space in it. The spec earlier says, "Formally, spaces are not allowed within these values, but implementers may wish to ignore such spaces to maximize backward compatibility." It should go from the example. |
| Resolution: | This has been resolved by fixing the example.
/w3ccvs/WWW/Math/Group/spec/xml/presentation-markup.xml,v revision: 1.277 |
| Summary: | RTL and mlabelledtr |
| Submitted: | Neil Soiffer,
http://lists.w3.org/Archives/Public/www-math/2009Oct/0030.html |
| Response: | Bruce Miller,
http://lists.w3.org/Archives/Public/www-math/2009Oct/0032.html Bruce Miller, http://lists.w3.org/Archives/Public/www-math/2009Nov/0031.html |
| Discussion: |
The label itself is positioned left or right according to the mtable's side attribute. I think we been consistent with the interpretation that "left" always means "left", even in an RTL context, so that we shouldn't need to reinforce that. The only exceptions are things like lspace, rspace where we could (and had to) fudge the interpretation to "leading space"; and of course things we've inherited from elsewhere (eg. "LEFT PARENTHESIS"). For the remaining children, the 1st paragraph of mlabeledtr says: "The rest of the children represent the contents of the row and are identical to those used for mtr;..." |
| Resolution: |
I've clarified that the children of mlabeledtr (after the first) are treated identically to the children of mtr. I've also split out a paragraph in the bidi section to make clear from the outset what leading and trailing mean, and that otherwise, left means left, etc. In trying to be explicit without being repetitive, it became clear that the menclose cases updiagonalstrike and downdiagonalstrike could suggest a dependence on directionality. Discussions within the group decided that they should not have such dependence and so I have added clarifying text there, as well. Checking in spec/xml/presentation-markup.xml; /w3ccvs/WWW/Math/Group/spec/xml/presentation-markup.xml,v <-- presentation-markup.xml new revision: 1.295; previous revision: 1.294 done |
| Summary: | Inherited attributes and default values |
| Submitted: | Sam Dooley,
http://lists.w3.org/Archives/Public/www-math/2009Nov/0029.html |
| Response: | Sam Dooley,
http://lists.w3.org/Archives/Public/www-math/2009Nov/0064.html |
| Discussion: |
The mstyle element (section 3.3.4.1) specifies that an attribute that is not normally inherited, such as linethickness on mfrac, may have a default value that may be changed by an attribute on mstyle. Some clarification is needed for cases of inherited attributes that are given default values on other elements. The troublesome attributes are displaystyle and scriptsizemultiplier. If the default value should override the inherited value, then mstyle cannot be used to change the default value, as it is described to do for other attributes. If the inherited value should override the default value, then the default value for these attributes has no meaningful effect. |
| Resolution: |
Fixed, as follows.
Added text to describe that mscarries changes the default value of the inherited scriptsizemultiplier to 0.6. The effect is that the inherited value should override the default value, but the default value, inside mscarries, should be 0.6. Checking in presentation-markup.xml; /w3ccvs/WWW/Math/Group/spec/xml/presentation-markup.xml,v <-- presentation-markup.xml new revision: 1.304; previous revision: 1.303 done |
| Summary: | mscarry should inherit its values, not have defaults |
| Submitted: | Neil Soiffer,
http://lists.w3.org/Archives/Public/www-math/2009Nov/0039.html |
| Response: | Neil Soiffer,
http://lists.w3.org/Archives/Public/www-math/2009Nov/0040.html |
| Discussion: |
This was missed from being officially logged: mscarry currently defaults the location and crossout values. One part of the spec says that the children of mscarries should implicitly be wrapped with mscarry. Because mscarry defaults its values, that means that the crossout and location on mscarries would be ignored. The fix is to make mscarry inherit those values instead. In addition to changing the values in the table, some of the examples that use mscarry need changing. |
| Resolution: | /w3ccvs/WWW/Math/Group/spec/xml/presentation-markup.xml,v <-- presentation-markup.xml new revision: 1.299; previous revision: 1.298 |
| Operator Dictionary |
|
| Summary: | Clarify how "symmetric" should be set by the Operator Dictionary |
| Submitted: | Frédéric Wang,
http://lists.w3.org/Archives/Public/www-math/2009Sep/0035.html |
| Response: | Neil Soiffer,
http://lists.w3.org/Archives/Public/www-math/2009Sep/0039.html Neil Soiffer, http://lists.w3.org/Archives/Public/www-math/2009Oct/0010.html Frédéric Wang, http://lists.w3.org/Archives/Public/www-math/2009Sep/0014.html |
| Discussion: |
Thank you for your comment. This has been resolved by changing "Most common opening and closing fences are defined in the operator dictionary to stretch by default; and they stretch vertically. Also, operators such as sum;, int;, /, and vertical arrows stretch vertically by default. " to say: "By default, most vertical arrows, along with most opening and closing fences are defined in the operator dictionary to stretch by default." BUT see the second message http://lists.w3.org/Archives/Public/www-math/2009Sep/0039.html |
| Resolution: | Resolved |
| HTML WG comments |
|
| Summary: | Several comments were made in a message from Shelley Powers and Joe Williams. |
| Submitted: | Shelley Powers,
|
| Response: | David Carlisle,
http://lists.w3.org/Archives/Public/www-math/2009Nov/0063.html Shelley Powers, http://lists.w3.org/Archives/Public/www-math/2009Nov/0075.html Patrick Ion, http://lists.w3.org/Archives/Public/www-math/2009Nov/0076.html David Carlisle, http://lists.w3.org/Archives/Public/www-math/2009Nov/0077.html |
| Discussion: | Other oppoprtunities for feedback resulted from the face-to-face meetings at the TPAC2009 in Sanat Clara. |
| Resolution: |
Shelley, HTML WG,
> Following are some general comments about the MathML 3.0 draft from > the HTML WG, particularly as the MathML specification relates to > current effort with HTML5. First, though, we wish to extend to the > Math WG congratulations for reaching this important milestone. > > Related to the addition of the new href attribute[1]: > > 1. The attribute href has been added for use with several MathML > elements, rather than using xlink:href, from MathML 2.0. However, the > document states that because of compound document requirements, > xlink:href can still be used. This could cause confusion when viewing > the documentation for MathML as foreign object in HTML5. In the HTML5 > specification, if the href attribute is associated with the XLink > namespace, it must be given as xlink:href in the document. > Foreign namespaced attributes are allowed in MathML3, as they are in earlier versions of MathML, so syntactically xlink attributes are allowed by general principles, but the MathML3 spec is quite explict that href is the preferred form for use as a hyperlink. We have adjusted the text in section 6 to make this clearer and to give advice to existing mathml2+xlink applications. RCS file: /w3ccvs/WWW/Math/Group/spec/xml/world-interactions.xml,v revision 1.59 date: 2009/11/18 04:08:00; author: rminer; state: Exp; lines: +19 -14 linking rewrites > The MathML href attribute is now, by default, associated with the > MathML namespace. But this isn't specifically stated in the document, Like all unprefixed attributes it is in no namespace. It is not associated with the MathML namespace, thus we do not know what statement you expected to see here, we are assuming no change is required to the document. If you feel some clarification is needed, please respond further on this point. > and someone reading both may become confused, and assume they have to > use xlink:href with MathML embedded in HTML5. xlink:href was only mentioned in passing in one or two places, discussing differences with MathML2 so we were not sure why you thought someone would have to use xlink, but as noted above we have adjusted the wording in section 6.4.2 Linking to try to make this clearer. > The document may want to > demonstrate how href can be used with embedded MathML in the document > section detailing MathML embedded in HTML. This section has been rewritten, href should not really need an example, it takes a URI (LEIRI) as value and is used exctly the same way as a href in html for example. > > 2. Is the plan to drop support for xlink:href in MathML UAs at some > point? If not, we're curious as to why the Math WG introduced the new > attribute? xlink was not widely supported amongst MathML2 UAs in any case, for example as far as we can tell it doesn't work in any current browser implementation of MathML (although it has worked in FireFox) xlink is a separate specification which user agents may or may not wish to implement, the MathML spec can not say what other specifications should be implemented by applications. We have revised the text in 6.4.2 to give advice on what an application supporting both xlink and native mathml linking should do. The issue here though is just the same as in xhtml, if an application supports xlink and xhtml there is the possibility of having both href and xlink:href on the same element. > > 3. If the UA supports both, what should happen when both are specified > on one element? Formally this is out of scope for MathML, however we have given some advice that href be preferred in the revised linking section. > > 4. We're also curious as to why the new href attribute takes a URI > rather than IRI? Thanks for catching this, we will add some clarifying text.
Most XML related specifications (including XML itself and XSD) as well
as MathML use "URI" (or "URL" in older specs such as XML or MathML1) to
mean essentially what is now known as an IRI (or differing in some edge
cases, a LEIRI). The MathML attributes that are described as type URI
are actually XSD schema typed as xs:anyURI which means that they have a
lexical space of any string and the system is supposed to %-encode any
characters not allowed in URI. Effectively this means that they take an
IRI. We have added wording to the table of common attribute types in
2.1.5 where this attribute type is introduced.
$ cvs commit -m IRI fundamentals.xml references.xml Checking in fundamentals.xml; /w3ccvs/WWW/Math/Group/spec/xml/fundamentals.xml,v <-- fundamentals.xml new revision: 1.127; previous revision: 1.126 done Checking in references.xml; /w3ccvs/WWW/Math/Group/spec/xml/references.xml,v <-- references.xml new revision: 1.90; previous revision: 1.89 done > > > Related to the Chapter 6.4, Combining MathML and Other Formats, and > specific to 6.4.1, Mixing MathML and HTML: > > 5. The specification includes a section discussing MathML and HTML. > However, the section only references MathML in XHTML. With HTML5, > MathML can be used in HTML, and there are additional constraints on > using MathML in HTML, including the fact that the outer math element > is specified without a prefix (such as m:math, as shown in the > example), though the use of a namespace and prefix can work with > XHTML. > > There are other constraints associated with MathML in HTML. Could this > one section be split in two, with one section detailing MathML in > XHTML, and one in HTML? > > In particular, HTML allows unquoted attributes, and elements without > closing tags (if such are given in the list of allowed elements > without closing tags). These looser specifications also apply to > foreign > objects such as SVG and MathML (though user agents are encouraged to > provide an export facility providing properly formatted XML). However, > people can paste properly formatted XML into HTML, and it will be > supported. The existing MathML+HTML section in chapter 6 has been split into two, one for XHTML and one for non-xml syntaxes, specifically HTML5. Note however the MathML specification defines MathML as an XML application, if other specifications define mathml variants with different syntax then it is that specification that must specify the differences. (HTML5 effectively does that by specifying how the html-like syntax is parsed to an xml dom). $ cvs commit -m html5 references.xml world-interactions.xml Checking in references.xml; /w3ccvs/WWW/Math/Group/spec/xml/references.xml,v <-- references.xml new revision: 1.91; previous revision: 1.90 done Checking in world-interactions.xml; /w3ccvs/WWW/Math/Group/spec/xml/world-interactions.xml,v <-- world-interactions.xml new revision: 1.62; previous revision: 1.61 done > > Pasting MathML into HTML does lead to another issue: the use of > namespaced attributes. Namespaced attributes can be included in > MathML, but, currently, the validator does provide a warning for > namespaced attributes in SVG or MathML when embedded in HTML. The same > applies to properly formatted XML entities and attributes that might > be included within the MathML annotation-xml > element. The behaviour of namespaced attributes is entirely implementation defined, they are allowed but no particular behaviour is mandated, so if for example they were just ignored by HTML systems that would be conformant, doing more would be helpful to the user, but not mandated. > > In addition, there are also, currently, DOM namespace handling > differences associated with MathML pasted into HTML, as compared to > MathML pasted into XHTML. > The MathML3 spec does not discuss the DOM at all, so while this might be true it does not affect the MathML3 specification. If we decide later to update the MathML2 DOM to a separate MathML3 DOM specification, this might become an issue. > Both the DOM differences and the validator warnings, in addition to > the syntax differences, such as unquoted attribute values, might be > surprising and confusing to folks who expect properly formatted XML in > HTML. > As noted above, the MathML specification only defines the XML syntax. If other specifications introduce syntactic variants, then any issues must be addressed in those specifications. However as HTML is an important special case, a mention of unquoted attributes in html is given as an example in the new html-specific section in chapter 6. > 6. The section contains the following passage: > > "To fully integrate MathML into XHTML, it should be possible not only > to embed MathML in XHTML, as described in Section 6.2.1 Recognizing > MathML in XML, but also to embed XHTML in MathML. However, the problem > of supporting XHTML in MathML presents many difficulties. Therefore, > at present, the MathML specification does not allow XHTML elements > within a MathML expression, although this situation may be subject to > change in a future revision of MathML." > > What are the difficulties referenced in the document? > > In particular, the HTML5 parser supports HTML and SVG in <mi>, <mo>, > <mn>, <ms>, <mtext> and SVG in <annotation-xml>. XHTML and SVG in > MathML in these places works fine in Firefox and Opera today when > using application/xhtml+xml. We're curious as to why MathML doesn't > allow what is, at a minimum, expressible in text/html? > the quoted section has been rewritten as that section has been split in two, as noted above so that HTML and XHTML can be discussed separately.
Also, please refer to the reply given to the I18n group on a similar question. It would be entirely wrong for the normative MathML schema to say that (X)HTML elements are by default allowed inside mtext. MathML as used by computer algebra systems (for example) probably can not deal with structured text at all, and docbook+MathML or XSL-FO+MathML (for example) would typically be processed by systems that could handle embedded docbook (or XSL-FO) elements in mtext but not HTML. This is why it needs to be the decision of the person defining the compound document format (XHTML+MathML or HTML+MathML) whether to allow nested HTML inside mtext. Even in a purely HTML+MathML application it isn't always possible to support nested HTML elements and mandating it would make some highly used systems non compliant. In a component architecture such as used by IE, if a different component is being used to render the MathML, it can not (given current API) easily call back to the host browser to render nested instances of HTML. > > Other, general comments: > > 7. In the element listing [2] you show an element labelled td, but the > link associated with it leads to a section describing an element > labeled mtd. Possible typo? Thanks for catching this. That list is automatically generated from the xmlspec markup and it is highlighting a typo in 3.5.4.2 Attributes where td was used for mtd. This has been fixed in our sources. $ cvs commit -m "td to mtd" presentation-markup.xml Checking in presentation-markup.xml; /w3ccvs/WWW/Math/Group/spec/xml/presentation-markup.xml,v <-- presentation-markup.xml new revision: 1.292; previous revision: 1.291 done > > 8. In the section describing color[3] you reference color names from > HTML4. Is there a reason MathML doesn't use css3-color SVG color > keywords instead of HTML4 color keywords? Initially (MathML1) there was no css3-color or svg. We did look briefly at extending this list but it wasn't clear that this would be useful: it doesn't really add any new functionality (since hex colours are supported) and typically isn't currently supported by MathML2 systems. HTML5 has these extended color names but introduces them as
"Some obsolete legacy attributes parse colors in a more
complicated manner,"
which doesn't really encourage these colours to be added as a new feature to other specs such as MathML3 Adding the long list of X11/SVG colour names to MathML3 at this time would hurt interoperability with existing MathML systems that do not support them, and offers no real extra features (as the colours may be specified using the hex rgb syntax). Supporting the extended list imposes a non negligable implementation cost on any implementation that is not hosted in a CSS environment that already supports these colours. > > 9. The index lists two values, my:background and my:color, which are > also demonstrated in the section to which they're linked. These would > seem to be from demonstrations of bringing in color or background from > another namespace. Including them in the index could generate > confusion. The index (which is automatically generated) indexes the use of these attributes. Why do you think it confusing to index an example that is there? Perhaps you mean that the example is confusing, but if so could you give some indication of what in particular causes confusion or what could be changed to lessen the confusion. |
| Media Types |
|
| Summary: | Our examples of annotations using media types are wrong. |
| Submitted: | Paul Libbrecht,
http://lists.w3.org/Archives/Public/www-math/2009Oct/0006.html |
| Response: | Robert Miner,
http://lists.w3.org/Archives/Public/www-math/2009Nov/0072.html |
| Discussion: |
Paul:
Since MathML3, the annotation and annotation-xml elements carry the
encoding attribute with the following recommended content:
1.- MathML-Presentation If you look at the specification we have the following example values; I note that there are spurious occurrences of versions of 1, 2, and 3 with a different casing which we should clean. Aside of 1, 2, and 3 there are:
|
| Resolution: |
This message records the resolution of the last call comment quoted below. The changes were:
CVS logs: presentation-markup.xml revision 1.307 date: 2009/11/22 19:05:12; author: rminer; state: Exp; lines: +2 -2 corrected casing of encoding values mixing.xml revision 1.127 date: 2009/11/03 22:22:17; author: rminer; state: Exp; lines: +2 -2 Checking in mixing.xml; /w3ccvs/WWW/Math/Group/spec/xml/mixing.xml,v <-- mixing.xml new revision: 1.128; previous revision: 1.127 done world-interactions.xml revision 1.67 date: 2009/11/22 19:05:13; author: rminer; state: Exp; lines: +3 -3 corrected casing of encoding values |
| Summary: | Comment on media-type registrations for MathML |
| Submitted: | Paul Libbrecht, on behalf of Bjoern Hoehrmann,
http://lists.w3.org/Archives/Public/www-math/2009Nov/0034.html |
| Response: | Paul Libbrecht (quoted inline),
http://lists.w3.org/Archives/Public/www-math/2009Nov/0034.html Robert Miner, http://lists.w3.org/Archives/Public/www-math/2009Nov/0078.html |
| Discussion: |
The first problem I have with this is that there is no word on what exactly the various types are for, like if there are any restrictions on what should be in a mathml-content+xml vs a mathml-presentation+xml document, or if the types can be used with MathML 2.0. As per RFC 3023, the charset definition and encoding considerations should be referenced as follows, which the proposals fails to do: Registrations for new XML-based media types under top-level types other than "text" SHOULD, in specifying the charset parameter and encoding considerations, define them as: "Same as [charset parameter / encoding considerations] of application/xml as specified in RFC 3023." The security considerations are missing (in fact the specification as a whole does not have a security considerations section either). I believe the text you have under "interoperability considerations" is misplaced there in all three cases. I note that under "Applications that use this media type" you have "(todo)". Going to Last Call with "todo" markers left is not a good practise. I note that the purpose of this field is to give a general idea of what kind of applications use it, not to list individual software products. Under "Person & email address to contact for further information" the proposal fails to properly separate name and email address, use something like "Name <address>" instead. I do not think having a generic W3C / W3C Webmaster combination there is a good practise. |
| Resolution: | I am writing in response to your comments on the media-type registrations for MathML given in Appendix B of the Last Call draft of the MathML 3 Specification. Your original comments are recorded at http://www.alvestrand.no/pipermail/ietf-types/2009-October/ 002268.html. We have modified Appendix B, and believe we have addressed the issues you noted. The changes are explained below, and you can see the draft changes in an editor's draft of the spec located at http://monet.nag.co.uk/~dpc/draft-spec/appendixb.html Since we need to record the resolution of all Last Call comments, could we ask you to let us know whether you accept these changes as addressing your comments? Thanks in advance. The specific actions taken are: > The first problem I have with this is that there is no word on what > exactly the various types are for, like if there are any restrictions > on what should be in a mathml-content+xml vs a mathml-presentation+xml > document, or if the types can be used with MathML 2.0. A new introductory section entitled "Selection of Media Types for MathML Instances" was added to specifically address this issue. The related text in section 6.2.3 of the spec is essentially summary in nature, and was therefore left unchanged. It already referred to appendix B for detailed information on the usage of the media types, and that information is now given. The section carefully defines the presentation and content MathML vocabularies, and gives a clear rule for determining what media type should be used for a given MathML instance based on the contents of that instance. The section also contains some explanation and examples to motivate the usage of the three MathML media types. The section ends by addressing use of the media types with earlier versions of MathML > As per RFC 3023, the charset definition and encoding considerations > should be referenced as follows, which the proposals fails to do: > > Registrations for new XML-based media types under top-level types > other than "text" SHOULD, in specifying the charset parameter and > encoding considerations, define them as: "Same as [charset parameter > / encoding considerations] of application/xml as specified in RFC > 3023." These sections have been edited to match the proper format. > The security considerations are missing (in fact the specification > as a whole does not have a security considerations section either). Security considerations have been added. We have listed both the generic issues common to similar XML languages, and two issues specific to MathML: the possible presence of executable code in semantic annotations, and the (possibly inadvertant) denial of service risks arising in computational contexts from trying to solve unsolvable problems. > I believe the text you have under "interoperability considerations" > is misplaced there in all three cases. This text has been completely rewritten. Again, there are some generic considerations common to similar XML languages, as well as several MathML specific issues. In particular, lack of versioning information in MathML instances introduces a backward compatibility concern, and the result of evaluating MathML expressions is not guaranteed to be the same in different computational systems. > I note that under "Applications that use this media type" you have > "(todo)". Going to Last Call with "todo" markers left is not a good > practise. I note that the purpose of this field is to give a general > idea of what kind of applications use it, not to list individual > software products. Thank you for the clarification on the purpose. We have filled out the section appropriately. > Under "Person & email address to contact for further information" > the proposal fails to properly separate name and email address, use > something like "Name <address>" instead. I do not think having a > generic W3C / W3C Webmaster combination there is a good practise Following other media type registrations under the BCP13 process, we have changed this to list Paul as the person, with the Math WG group mailing list for the address, followed by a pointer to the public W3C Math web site for additional information. Checking in media-types.xml; /w3ccvs/WWW/Math/Group/spec/xml/media-types.xml,v <-- media-types.xml new revision: 1.11; previous revision: 1.10 Checking in media-types.xml; /w3ccvs/WWW/Math/Group/spec/xml/media-types.xml,v <-- media-types.xml new revision: 1.12; previous revision: 1.11 Checking in xml/media-types.xml; /w3ccvs/WWW/Math/Group/spec/xml/media-types.xml,v <-- media-types.xml new revision: 1.13; previous revision: 1.12 |
| Miscellaneous |
|
| Summary: | Can I use it yet? |
| Submitted: | Karim Alloula,
http://lists.w3.org/Archives/Public/www-math/2009Oct/0011.html |
| Response: | David Carlisle,
http://lists.w3.org/Archives/Public/www-math/2009Oct/0012.html Karim Alloula, http://lists.w3.org/Archives/Public/www-math/2009Oct/0013.html |
| Discussion: |
As an implementor now is a good time to start implementing the new features, as the best way to make detailed comments on the spec is to implement it, and this last call period, and the following candidate recommendation period are the times to get in any last minute changes suggested by implementation experience. |
| Resolution: | Nothing to change. An informative reply was all that was needed and was appreciated. |
| Summary: | PMML @title attribute |
| Submitted: | Christoph Lange,
http://lists.w3.org/Archives/Public/www-math/2009Oct/0034.html |
| Response: | Robert Miner,
http://lists.w3.org/Archives/Public/www-math/2009Nov/0014.html Christoph Lange, http://lists.w3.org/Archives/Public/www-math/2009Nov/0018.html |
| Discussion: |
There has been a lot of discussion about how to deal with attributes from other markup languages when mixed with MathML in a compound document format. In terms of providing tooltip functionality within MathML in isolation, there is already support via <maction actiontype="tooltip">...</maction> which has been in MathML a long time, and that MathML 3 now elevates to normative status. Consequently, there isn't much appetite for introducing another mechanism via a title attribute. Of course, I think you are primarily interested in the situation in a coupound document format, namely XHTML+MathML+SVG. In that situation, there is more of a case for allowing attributes from the containing document markup language to be used on MathML elements. In 6.4 Combining MathML and Other Formats, the last call draft states that attributes from non-MathML namespaces are permitted when defining compound document formats. There have been several last call comments about compound document formats, and we will be revising the language of 6.4 shortly to make it clearer that so long as the CDF specifies the expected behavior, it is allowed (or even encouraged) to specify that attributes from non-MathML namespaces on MathML element when natural and reasonable. However, in the particular case of the XHTML title attribute, it isn't in any namespace, and so even lax rules permitting attributes from other namespaces in compound documents wouldn't help. The only way to handle it would be to add a MathML attribute also called title, and say it does the same thing as the XHTML title attribute. Since that would again lead to redundant mechanisms for tooltips in MathML itself, the Math WG doesn't want to take that step. Finally, I expect there is an element of pragmatism in your question, since as you note, using the title attribute works in Firefox today, and <maction actiontype='tooltip'> does not. It sort of does, in that it only displays the base expression, and not the tooltip message child. Of course, <maction> does work in IE+MathPlayer, but @title doesn't. There are various JavaScript + CSS workarounds, and so on, but admittedly the current state of implementation leaves a lot to be desired. |
| Resolution: | Informational explanation accepted
|
| Editorial corrections |
|
| Summary: | The schema misses three attributes defined in prose text of Chap. 3 |
| Submitted: | David Carlisle,
http://lists.w3.org/Archives/Public/www-math/2009Nov/0052.html |
| Response: | Self-closing |
| Discussion: |
A late last call comment. The schema misses three attributes defined in the prose text of chapter 3. The attributes of mmultiscripts are defined to be those of msubsup rather than being defined in a separate table. This was missed by the schema extractor, but this has now been fixed, Similarly the deprecated value indentingewline of the linebreak attribute in mspace is defined in text, but not extracted to the schema. http://monet.nag.co.uk/~dpc/draft-spec/appendixa.html#parsing_mmultiscripts. attributes and http://monet.nag.co.uk/~dpc/draft-spec/appendixa.html#parsing_mspace.attributes |
| Resolution: | Checking in mathml3-presentation.rnc; /w3ccvs/WWW/Math/Group/RelaxNG/mathml3/mathml3-presentation.rnc,v <-- mathml3-presentation.rnc new revision: 1.55; previous revision: 1.54 done Checking in mathml3-presentation.rng; /w3ccvs/WWW/Math/Group/RelaxNG/mathml3/mathml3-presentation.rng,v <-- mathml3-presentation.rng new revision: 1.38; previous revision: 1.37 done Checking in dtd/mathml3.dtd; /w3ccvs/WWW/Math/Group/RelaxNG/mathml3/dtd/mathml3.dtd,v <-- mathml3.dtd new revision: 1.29; previous revision: 1.28 done Checking in xsd/mathml3-presentation.xsd; /w3ccvs/WWW/Math/Group/RelaxNG/mathml3/xsd/mathml3-presentation.xsd,v <-- mathml3-presentation.xsd new revision: 1.26; previous revision: 1.25 done |
| Summary: | The table of pseudo-script characters in section 7.7.2 contains some omissions and other editorial issues. |
| Submitted: | Sam Dooley,
http://lists.w3.org/Archives/Public/www-math/2009Nov/0069.html |
| Response: | Sam Dooley,
http://lists.w3.org/Archives/Public/www-math/2009Nov/0069.html |
| Discussion: |
Here is the updated table: U+0022 QUOTATION MARK U+0027 APOSTROPHE U+002A ASTERISK U+0060 GRAVE ACCENT U+00AA FEMININE ORDINAL INDICATOR U+00B0 DEGREE SIGN U+00B2 SUPERSCRIPT TWO U+00B3 SUPERSCRIPT THREE U+00B4 ACUTE ACCENT U+00B9 SUPERSCRIPT ONE U+00BA MASCULINE ORDINAL INDICATOR U+2018 LEFT SINGLE QUOTATION MARK U+2019 RIGHT SINGLE QUOTATION MARK U+201A SINGLE LOW-9 QUOTATION MARK U+201B SINGLE HIGH-REVERSED-9 QUOTATION MARK U+201C LEFT DOUBLE QUOTATION MARK U+201D RIGHT DOUBLE QUOTATION MARK U+201E DOUBLE LOW-9 QUOTATION MARK U+201F DOUBLE HIGH-REVERSED-9 QUOTATION MARK U+2032 PRIME U+2033 DOUBLE PRIME U+2034 TRIPLE PRIME U+2035 REVERSED PRIME U+2036 REVERSED DOUBLE PRIME U+2037 REVERSED TRIPLE PRIME U+2057 QUADRUPLE PRIME In addition, the characters in the Unicode Superscript and Subscript block (U+2070 through U+2094) should be treated as pseudo-scripts when they appear in mathematical formulas. |
| Resolution: | Checking in character-set.xml; /w3ccvs/WWW/Math/Group/spec/xml/character-set.xml,v <-- character-set.xml new revision: 1.107; previous revision: 1.106 done |
| Summary: | align attribute for mover |
| Submitted: | Sam Dooley,
http://lists.w3.org/Archives/Public/www-math/2009Oct/0037.html |
| Response: | Sam Dooley,
http://lists.w3.org/Archives/Public/www-math/2009Oct/0037.html |
| Discussion: | The 'align' attribute for the mover element was omitted from
the schema files due to a bug in the attribute table for mover
in Chapter 3. The attribute has now been restored to the schema.
|
| Resolution: | Self-closing
|
| Summary: | 'other' attribute in the schema files |
| Submitted: | Sam Dooley,
http://lists.w3.org/Archives/Public/www-math/2009Oct/0035.html |
| Response: | David Carlisle,
http://lists.w3.org/Archives/Public/www-math/2009Oct/0036.html |
| Discussion: | This has been fixed in the schema
CommonDeprecatedAtt = attribute other {text}?
CommonAtt = attribute id {xsd:ID}?,
attribute xref {text}?,
attribute class {xsd:NMTOKENS}?,
attribute style {xsd:string}?,
attribute href {xsd:anyURI}?,
CommonDeprecatedAtt,
NonMathMLAtt*
|
| Resolution: | Self-closing
$ cvs commit -m "CommonDeprecatedAtt called from CommonAtt" mathml3-common.rnc Checking in mathml3-common.rnc; /w3ccvs/WWW/Math/Group/RelaxNG/mathml3/mathml3-common.rnc,v <-- mathml3-common.rnc new revision: 1.34; previous revision: 1.33 done |
| Summary: | Chapters 0, 2 and 7 fixes |
| Submitted: | Sam Dooley,
Various internal WG messages quoted from below |
| Response: | Various WG members, |
| Discussion: |
13 Nov 2009I took a couple of minutes to read the Overview page and found a few typos and other wording issues, which I fixed, and a few examples of old promises, listed below, which I haven't fixed. I've checked in mathml-spec.xml with the editorial fixes. Fixed: --- s/Last Call period ends/Last Call period ended/ --- s/summary of comment/summary of comment”/ --- The rechartering of a Math Working group /has allowed 3.0/ does not signal --- Remove /and on markup for elementary math notations/ (repeated) --- While MathML is human-readable, authors typically will use equation editors, --- Several versions of such MathML tools exist, both freely available software and commercial products, and more are under development. 13 Nov 2009The final example in chapter 1 claims to be the content markup form of the quadratic formula, but the markup doesn't match. I've replaced the markup, using 13 Nov 2009Here are more editorial fixes I've applied to chapter 2. None of these are from section 2.1.5. 2.1 Syntax --- s/depends on this/depends on this order/ --- s/tabulated ... Section/tabulated ... in Section/ --- s/ in favor of/) in favor of/ 2.2 math --- s/the math is usually/the math element is usually/ --- s/value of valign/value of altimg-valign/ --- s/The URI specifies/specifies/ --- s/determine a CD base,/determine a CD base;/ --- for all csymbol, annotation, and annotation-xml elements. --- s/in-line/inline/ 2.3 Conformance --- s/Information is nowadays/Information nowadays is/ --- s/manipulate or/manipulate, or/ --- s/aural or tactile/aural, or tactile/ --- This section gives guidelines that describe different types of MathML support and make clear the extent of MathML support in a given application. --- s/users and reviewers/users, and reviewers/ --- s/Relax_NG/RelaxNG/ --- s/a valid MathML expressions/a valid MathML expression/ --- s/may actually be/may be/ --- s/in interpreting/to interpret/ --- s/at MathML validator/at the W3C MathML Validator/ --- s/MathML 2.0 contains/MathML 3.0 contains/ --- s/MathML 2.0 defined/MathML 3.0 defines/ --- s/: The/: the/ --- s/etc)/etc.)/ 20 Nov 2009Here are some editorial fixes I've applied to chapter 7, separate from those I will need to finish off mathvariant. Fixed: 7.6 Non-Marking Characters --- s/(<secref .../>/(secref .../>)/ --- s/such a 1½/such as 1½/ 7.7.1.3 Other Keyboard Substitutions --- s/is used/is used for/ 7.7.2 Pseudo-scripts --- s/mathematical context/mathematical contexts/ --- s/mathematical contexts /mathematical contexts. / --- s/others as well:/many others, as listed below:/ --- s/namely/including/ 7.7.3 Combining characters --- s/underscript and/underscript, and/ --- s/Unicode points/Unicode code points/ --- s/listed in the [Entities]/listed in [Entities]/ --- The general rule is that a base character followed by a string of combining characters should be treated just as though it were the pre-composed character that results from the combination, if such a character exists. Checking in character-set.xml; /w3ccvs/WWW/Math/Group/spec/xml/character-set.xml,v <-- character-set.xml new revision: 1.104; previous revision: 1.103 done 20 Nov 2009Section 7.7.1.1 incorrectly refers to HYPHEN-MINUS as U+002C instead of U+002D. I've fixed the references, cleaned up the text, and added references to U+2010 HYPHEN. --- The most common ordinary text character which enjoys a special mathematical use is U+002D [HYPHEN-MINUS]. As its Unicode name suggests, it is used as a hyphen in prose contexts, and as a minus or negative sign in formulas. For text use, there is a specific code point U+2010 [HYPHEN] which is intended for prose contexts, and which should render as a hyphen or short dash. For mathematical use, there is another code point U+2212 [MINUS SIGN] which is intended for mathematical formulas, and which should render as a longer minus or negative sign. MathML renderers should treat U+002D [HYPHEN-MINUS] as equivalent to U+2212 [MINUS SIGN] in formula contexts such as Checking in character-set.xml; /w3ccvs/WWW/Math/Group/spec/xml/character-set.xml,v <-- character-set.xml new revision: 1.105; previous revision: 1.104 done 20 Nov 2009
Section 7.7.1.2 encourages renderers to treat apostrophe (')
as rsquo (U+2109) in text contexts. At first that sounded OK
to me, but now I think it's a bad idea.
To make it work, you also have to treat backquote (`) as lsquo (U+2018),
but even if that's OK, you still have no way to get upright single quotes
that look like the upright double quotes you expect to get with (").
So I think we need to remove the last half of the sentence that now forms
the middle paragraph. That is, we should still recommend that apostrophe
be treated as prime in math context, but we should drop the advice to
treat apostrophe as rsquo in text context. For symmetry, we should also
recommend that backquote be treated as reverse prime in math context.
|
| Resolution: | Self-closing
cvs commit -m "Sam's corrections and CR text updates" mathml-spec.xml references.xml fundamentals.xml character-set.xml Checking in mathml-spec.xml; /w3ccvs/WWW/Math/Group/spec/xml/mathml-spec.xml,v <-- mathml-spec.xml new revision: 1.231; previous revision: 1.230 done Checking in references.xml; /w3ccvs/WWW/Math/Group/spec/xml/references.xml,v <-- references.xml new revision: 1.94; previous revision: 1.93 done Checking in fundamentals.xml; /w3ccvs/WWW/Math/Group/spec/xml/fundamentals.xml,v <-- fundamentals.xml new revision: 1.133; previous revision: 1.132 done Checking in character-set.xml; /w3ccvs/WWW/Math/Group/spec/xml/character-set.xml,v <-- character-set.xml new revision: 1.108; previous revision: 1.107 done |