[Prev][Next][Index][Thread]
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