From: KAMTHAN pankaj <kamthan@cs.concordia.ca>

Date: Thu, 01 Jun 2000 04:48:48 -0400

Message-Id: <200006010848.EAA10044@pollen.cs.concordia.ca>

To: rminer@geomtech.com, www-math@w3.org

Date: Thu, 01 Jun 2000 04:48:48 -0400

Message-Id: <200006010848.EAA10044@pollen.cs.concordia.ca>

To: rminer@geomtech.com, www-math@w3.org

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. PankajReceived on Thursday, 1 June 2000 04:54:01 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:27:30 UTC
*