Re: Comments on MathML Last Call Draft (cont'd)
Here are some more comments on the MathML 2.0 Draft.
Hope they are of some use.
1. It could be mentioned that:
Within this specification, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119.
A reference to "Key words for use in RFCs to Indicate Requirement Levels",
S. Bradner, March 1997. Available at ftp://www.ietf.org/rfc/rfc2119.txt."
could be provided.
In the foregoing, I'm using:
[prose with problems] -> [prose with suggested corrections]
In MathML 1 the ... -> In MathML 1.0 the ...
For that reason MathML 2 passes ... -> For that reason MathML 2.0 passes ...
Perhaps, a consistent use of MathML 1.0 and MathML 2.0 is needed. All of
MathML 1, 1.0; MathML 2, 2.0 are used.
"Though the final form of Schemas is not yet clear, ..."
XML Schemas are, like MathML 2.0, in their last call (that ends May 12,
2000). Rather than the above, it could perhaps be mentioned that MathML
2.0 is ahead of XML Schemas' schedule.
"The Unicode point points are those of the current proposal which will,
it is expected eventaully be part of the next revision, Unicode 4.
Unicode 3 has just been published in February 2000."
This is perhaps better written as:
"The Unicode points are not part of Unicode 3.0, the current standard
which was published in February 2000. They are from the current proposal,
which is expected eventually to be part of the next revision, Unicode 4.0."
It may be useful to mention the technical report:
Unicode in XML and other Markup Languages available at
"Multipurpose Internet Mail Extensions (MIME) Part One: Format of
Internet Message Bodies", N. Freed and N. Borenstein, November 1996.
Note that this RFC obsoletes RFC1521, RFC1522, and RFC1590.
Available at ftp://www.ietf.org/rfc/rfc2045.txt.
"Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types",
N. Freed and N. Borenstein, November 1996. Note that this RFC obsoletes
RFC1521, RFC1522, and RFC1590.
Available at ftp://www.ietf.org/rfc/rfc2046.txt.
may be useful here.
"However, there are two notable exceptions."
It may be useful to mention exactly which at this stage (the XHTML anchor
"a" and image "img" elements).
"The reader is cautioned that this is at present still a working draft,
and is therefore subject to future revision."
Yes, but XLink is ahead of MathML 2.0 schedule. Last call ended on March
... prefix for the MathML namespace to math:. ->
... prefix for the MathML namespace to math. (No colon needed.)
"An SGML parser, such as nsgmls, can be used to validate MathML. In this
case an SGML declaration defining the constraints of XML applicable to an
SGML parser must be used."
This may have been the case (by necessity) in case of MathML 1.0 when
(robust and well-tested) validating XML parsers were rare. There are
several validating XML parsers in a variety of programming languages for
diverse platforms now. Furthermore, one can avoid the extra step of:
"In this case an SGML declaration defining the constraints of XML
applicable to an SGML parser must be used."
It seems that MathML 2.0 elements are missing from the EBNF grammar. For
example, divergence, imaginary, card, and so on.