Comments:7,C,E,F

Hello Robert,

"I'm in charge of corrections in chapter 7, so here is a list of itemized 
corrections for chapter 7 ..."

I am glad to know that the comments were of some use. The following
is another (unfortunately rather long) set of comments on Chapter 7
and a bit on Appendices C, E and F.

7.1.2

Most of this section, I'll maintain, may fit better in a vicinity of Chapters 3, 4. 
(Brief mention of the root element in this chapter is still warranted as IT IS 
the interface (or like a gateway) to MathML (for the parent document of a non-
MathML vocabulary that includes a MathML conforming fragment; for generic 
XML and MathML-aware processors).)

This (discuss "math" first and Presentation and Content elements later) is 
naturally a "top-down" approach (a view which some might not share) of a MathML 
document.

7.1.3

"In browsers where MathML is not natively supported, we anticipate that 
MathML rendering will be carried out via embedded objects such as plug-ins, 
applets, or helper applications."

At this stage, we haven't yet reached the MathML rendering section 7.2. (So, 
how can we talk about "invoking" any rendering solutions?) A link to 7.2 could 
be useful here.

"The direction which has begun emerging for invoking third-party rendering 
and processing software is elucidated in the W3C Working Draft 'Behavioral 
Extensions to CSS' "

From XHTML 1.1 Event Model Appendix A. A Comparison with BECSS 
(http://www.w3.org/TR/xhtml-events), in particular: "The requirements for 
the XHTML Event Module defined in this draft were: [...] To be able to 
integrate with HTML, SMIL, and other languages", that XHTML 1.1 Event 
Model (though overlaps) is not a subset of BECSS functionality, and in the 
light of fact that this chapter focusses on "the mechanics of embedding 
MathML in XHTML", some prose (or a pointer of acknowledgement) regarding 
the module may be useful.

7.1.4

The objection I have here is that some parts of sections 7.1.4, 7.1.4.1 and 
7.1.4.2, IMHO, seem unnecessary. I'll point out those portions and refer to the 
following rationale, denoted by [*], in support. 

Rationale: MathML and HTML are in different directions: Mathematical 
notation, Web publishing. The tone seems to be comparitive: "MathML has no 
element that corresponds to the XHTML anchor element a." and "The IMG 
element has no MathML equivalent." Indicating this may have been necessary 
for MathML 1.0 (being the first XML-based vocabulary from W3C that reached 
the Recommendation status, was a time to emphasize HTML to XML 
transition, and so on) or more appropriately in some sort of MathML 
Requirements document. But stating "parallels" between MathML and HTML is 
not really needed now, is it? MathML does not have elements corresponding 
to other facilities provided by HTML either: forms, metadata (not yet), frames, 
... But that's OK, it is being taken care of under the XML umbrella: 2D 
graphics (SVG), hyperlinks (XLink), forms (XForms), metadata (RDF), ..., 
respectively. MathML (among several other reasons as Chapter 1 points out) 
was designed to fill in for the lack of sufficient support for mathematical 
notations in HTML. Therefore, it may not be useful to open the door for this 
comparison (between MathML and HTML).

"In most cases, XHTML elements either do not apply in mathematical contexts 
(headings, paragraphs, lists, etc.), or MathML already provides equivalent or 
better functionality specifically tailored to mathematical content (tables, style 
changes, etc.). However, there are two notable exceptions."

Suggestion: The above portion is not needed.

Rationale: See [*].

7.1.4.1

1. Why is linking mentioned in 7.1.4.1 in HTML's context? The functionality of 
linking has little to do with HTML. Linking is needed in MathML "on its own", 
as shown by 5.3.4.

2. According to MathML 1.01, 7.1.5. 

"MathML, as an XML application, defines links by the use of the XML-LINK 
attribute." [...] "MathML linking elements are generic XML linking elements as 
described in the Extensible Markup Language (XML): Part 2. Linking working 
draft." [...] "A MathML element is designated as a link by the presence of the 
XML-LINK attribute. The possible values for the this attribute are ..." [...] 
"Elements which specify the value of the XML-LINK attribute as "simple" must 
also specify a value for the HREF attribute."

As MathML 2.0 uses XLink for inducing linking functionality in its elements, and 
syntax and semantics of XLink element and attributes have changed over 
time, it may be useful to point out that MathML 1.01 documents making use of 
XML-LINK attribute and its values, or HREF, are non-MathML 2.0 compliant.

3. MathML 1.01 provided only unidirectional links: "MathML at present does 
not provide a way for other documents to make links into a MathML 
expression." 

Does MathML 2.0 also allow only unidirectional links, as later in the section 
(MathML 2.0, 7.1.4.1) 

"Note that the XML Linking [XLink] and XML Pointer Language [XPointer] 
specifications also define how to link into a MathML expressions. Be aware, 
however, that such links may or may not be properly interpreted in current 
software." 

seems to warn against bi-directionality? It could be useful to make that 
explicit.

4. MathML 1.01, Table 7.1.5.1. 

MathML Elements Which Cannot Be Linking Elements.

<prescripts/> <none/> <sep/> <power/> <malignmark/> <maligngroup/> 

Is there a reason to exclude "power" from this list in MathML 2.0?

7.1.4.2

"The IMG element has no MathML equivalent. The decision to omit a general 
mechanism for image inclusion from MathML was based on several factors. 
However, the main reason for not providing an image facility is that MathML 
takes great pains to make the notational structure and mathematical content 
it encodes easily available to processors, whereas information contained in 
images is only available to a human reader looking at a visual representation. 
Thus, for example, in the MathML paradigm, it would be preferable to 
introduce new glyphs via the mglyph element which at a minimum identifies 
them as glyphs, rather than simply including them as images."

Suggestion: The above portion is not needed.

Rationale: See [*].

"Finally, apart from the introduction of new glyphs, many of the situations 
where one might be inclined to use an image amount to some sort of labeled 
diagram. For example, knot diagrams, Venn diagrams, Dynkin diagrams, 
Feynman diagrams and complicated commutative diagrams all fall into this 
category. As such, their content would be better encoded via some 
combination of structured graphics and MathML markup. Because of the 
generality of the 'labeled diagram' construction, the definition of a markup 
language to encode such constructions extends beyond the scope of the 
current W3C Math activity. (See http://www.w3.org/Graphics for further W3C 
activity in this area.)"

Suggestion: This may be more suitable in Chapter 6 (somewhere at the end 
when the discussion of extending the family of glyphs provided by MathML is 
over).

Rationale: 6.1.5 already says that "MathML 2 does provide the mglyph and 
csymbol elements to accommodate new characters that authors may wish to 
introduce." The above paragraph provides scenarios where such need might 
arise and therefore connects well in there.

Note that carrying out both the suggestions above means that 7.1.4.2 will 
become non-existent.

7.2.2

"MathML-output-compliant applications such as editors and translators may 
choose to generate merror expressions to signal errors ..."

Suggestion: Link to the definition of merror.

7.3

Suggestion: Rename 7.3 Future Extensions -> 7.3 MathML Extensions or 7.3 
Extending MathML.

Rationale: The word "Future" is implicit in the new title. Any extensions (such 
as, modularization) will (obviously) be in future. 

7.3.1

Does MathML encourage use of external style sheets (for reasons of 
modularity, reusability)? Assuming yes, there is no mention of associating style 
sheets. See: "Associating Style Sheets with XML documents Version 1.0", 
James Clark, editor, 29 June 1999. Available at http://www.w3.org/TR/xml-
stylesheet/. 

C.2.10 Lineary Algebra -> C.2.10 Linear Algebra 

E.1.2

The IDL definition for MathMLElement takes into account the class, style and 
id attributes of the "math" element (7.1.2). But the "math" element has other 
attributes as well: macros, mode (deprecated), display, overflow, altimg, and 
altdisplay; why are they (if not all, at least some of them) not accounted for?

Appendix F

Extensible Style Language (XSL) -> Extensible Stylesheet Language (XSL)

Hope this is of some use.

Pankaj

Received on Thursday, 1 June 2000 04:54:01 UTC