Reviewed by: Andrew Thackrah
Date completed: 30 April 2003
Document Reviewed: Mathematical Markup Language (MathML) Version 2.0 (2nd Edition)
This document is a review of MathML 2.0 regarding its conformance to the guidelines of the QA Framework document: Specification Guidelines
The specification met (the requirements of) 16 out of 18 applicable Level 1 checkpoints.
The specification met (the requirements of) 9 out of 13 applicable Level 2 checkpoints.
The specification met (the requirements of) 8 out of 10 applicable Level 3 checkpoints.
See the Back matter at the end of the document for specific comments
The spec. has good general background and specific markup background sections that cover scope.
Yes. Section 1 in good detail.
Yes. Scope is discussed in section 1.3.
Yes. Particularly sections 1.3.1, 1.3.2 and 2.2.
Yes. There are many functional examples throughout the text.
The classification of products varies a little with context. For example in some contexts products are grouped according to their function on presentation and content and in other contexts according to input/output/roundtrip handling of the markup. For conformance purposes only one product is defined: a "MathML processor". Some clear mapping between the classifications in the various might help although it is mostly clear.
Yes. Four product classes are identified: renderers, processors, translators and editors.
Yes. See section 7.2
Yes. Presentation and Content are identified.
Yes. Section 7 covers intercommunication of rendering and processing tools.
The spec. uses the term 'conformance' whereas the linked guidelines document uses the term 'compliance' even though the content of the guidelines document is essentially the same as the spec. If there are to be separate documents covering conformance/compliance it is recommended they use a single term. QAWG prefers 'conformance'.
Yes. This is detailed in section 7 and also in a referenced (and linked) document "MathML 2.0 Compliance Guidelines".
Yes. defines "MathML processor" in conformance section.
The specification makes no use of profiles. The checkpoints in this section are not applicable (N/A)
N/A
N/A
N/A>
N/A
The specification makes no use of modules. The checkpoints in this section are not applicable (N/A)
N/A
N/A
The specification makes no use of functional levels. The checkpoints in this section are not applicable (N/A)
N/A
Yes. Seems to apply only to Context and not Presentation (?) - if so, this could be made explict and explained.
Yes. See section 7.2.1.2.
Yes. Section 7.2.1.2 discusses deprecation wrt input/output/roundtrip product classes.
Generally yes.
Yes. In cases where reasons are not given an alternative usage is given. (Section 6.4)
Latitude for implementer discretion is large. Specific constraints are not all identified as this would clearly be exhaustive. This may be a potential interoperability problem (?)
Yes. Implementers have discretion in some cases whether to use content or presentation markup. Rules and guidelines for these cases are given. Also see rendering rules (section 3).
Yes. Section 7.1
Not really. Latitude for discretion is large.
Yes. Implementation notes cover this.
Yes. The relation between product classes and content/presentation discretion is discussed. Section 7.2 covers a product/extension relationship.
The treatment of extensions is where the spec. performs least well against the SpecGL checkpoints. Future extensions are discussed in the context of future work to be added to the spec. In the context of an implementer extending the current spec. one mechanism is provided for Presentation extensions (mglyph) via Unicode but the conformance implications are not discussed. Interoperability implications are covered in a paragraph dissuading extensions unless absolutely necessary.
Yes. Future extensions are discussed in section 7.3.
Yes. Section 3.2.9 covers Presentation extensions.
No. It is not made clear if extensions may contradict other parts of the spec.
Yes. In the case of presentation mglyphs (section 3.2.9)
No.
No.
No.
Yes. Section 7.2.1.
Yes. (I think..) MathML is only dependent on versions of XML and Unicode.
Conformance claims are handled not through a statement provided in the spec. but by use of the official test suite. The results of a test run appear to constitute a claim.
Yes. identifies one general type and three sub-types (section 7.2.1).
Yes. The MathML test suite results are treated as the conformance claim (section 7.2.1.1)
Yes. Implementers are encouraged to itemize parts of the spec. that are not meaningful to their product/implementation.
Yes. No obvious restrictions.
Publication is encouraged, not demanded. There is no common public repository for IC Statements
Yes. (No ICS) Implementers are given wide latitude, particularly in presentation. They are encouraged to publish there own ICS (test suite results).
Not Applicable
In addition to a conformance section in the spec. the MathML group maintain a separate document "MathML 2.0 Compliance Guidelines". This document duplicates material in the spec. conformance section (section 7). This may lead to document synchronization errors.
No. Text is mainly descriptive rather than prescriptive. There is little use of 'must', some use of 'should' and 'may'. RFC2119 is not referenced. It is not clear if 'should' etc are used according to RFC 2119 rules.
Yes. Text is treated as normative unless explicitly marked.
Yes.
Yes. All in a single section, linked from table of contents (PDF bookmarks list in the version I read)
The specification does not identify assertions or provide any requirement-test linkage mechanism.
No. There is a test suite but there is no direct linkage to assertions in the spec.
No. Text that contains a requirement that could be treated as an assertion is not labelled or identified as such and so it would not be possible to provide a linking mechanism.
Generally the specification conforms well to SpecGL.
The main weakness is lack of information about the conformace implications of extensions to the spec. The possibility of extensions is readily acknowledged and in the main case a mechanism is provided but it is noted that there are interoperability issues here which are not dealt with other than to dissuade an implementer from using the extension mechanism where possible.
The spec. does not use strong, prescriptive RFC2119 language and this makes it harder to locate assertions (but easier to read...). Specific requirements are not tagged (to allow linkage to tests) although there is a test suite (which I haven't looked at)
I was a little confused about product classification. There is more than one classification scheme for the same set of applicable products. Conformance product classes and discretionary implementation classes use different terms.
There is a separate document for "Compliance Guidelines". This document appears to duplicate material in the conformance section of the specification which raises document maintenance concerns. Also both 'compliance' and 'conformance' are used (to mean the same thing).