W3CUser Interface Domain

MathML 2.0 Last Call Dispositions

Public Version   [Member-Confidential Version]

8 November 2000, Version 1.0

Robert Miner, Design Science
Patrick Ion, AMS, Math WG Co-chair

Table of contents

Comments and Responses

The MathML 2.0 Specification Last Call draft received a lot of comments. Most were non-controversial, and we have done our best to accommodate them. Some involved more substantive issues, and provoked a good deal of discussion between the Math WG and the originators of the comments. In most cases, a consensus opinion emerged, but in others, minor differences or open problems remain.

Below we itemize the comments received and the Math WG responses. The dispositions of non-controversial comments and suggestions are noted briefly in this document. In the case of more substantive issues, discussion is given below describing the background and the resolution proposed by the Math WG.

Bi-directional Layout of Math
Summary:A proposal was made to add support to MathML for full, hierarchical, bi-directional layout, beyond the inherent Unicode support for bi-directional layout within elements accepting character data as content.
Submitted:Martin J. Duerst, http://lists.w3.org/Archives/Member/w3c-math-wg/2000AprJun/0147.html (W3C Member URI)

Inquiries to educators and researchers in right-to-left (RTL) writing communities determined that while practice is not uniform amngst these communities, bidi math layout may be significant in some of them, most notably in some Arabic-speaking locales. Further, it was pointed out that MathML 1.0 was not scrutinized from the I18N viewpoint, and consequently some discussion about bidi layout is necessary in MathML 2.0, even if it is mostly negative in nature, explicitly deferring some aspects of bidi layout to future version.

After much discussion, a strong case emerged that the general problem of automatic bidi layout algorithms for math are difficult and complicated, due to the 2-dimensional nature of math notation, and the fact that spatial relationships and juxtaposition frequently carry meaning in specific math notations. That, together with the lack of clear uniform practice in RTL language communities on which to model algorithms, led to the conclusion that automatic bidi layout in MathML would be deferred pending further investigation. At a minimum, the issue of manual bidi layout should be addressed in a future version of MathML.


A new section on bidi layout has been added to Chapter 3, specifying that the implicit part of the Unicode bidirectional algorithm is applied within leaf nodes, and specifying that MathML 2.0 does not address bidi equation layout in general.


MathML Character Issues
Summary:Several inter-related issues concerning MathML Characters have been raised. There is a question as to how to present the tables of MathML characters in Chapter 6, especially those characters whose Unicode code points are still provisional. There is also an issue about the role of Unicode Plane-1 characters, such as "math bold italic x" and their relation to 'styling' mathematical text. Finally, there is some confusion about the nature of character data allowed in MathML token elements. (See also related issues on style attributes, the mglyph element and the defunct mchar element, and bi-directional layout.)
Submitted:Martin J. Duerst, http://lists.w3.org/Archives/Member/w3c-math-wg/2000AprJun/0147.html (W3C Member URI)

The MathML character issues proved to be quite serious and involved, affecting a number of W3C activities, as well as work of the Unicode Technical Committee.

The first aspect of the problem is that a number of MathML characters, including some that are vital to the design of MathML such as &InvisibleTimes; and &Applyfunction;, will not officially be in Unicode by the time the MathML Recommendation is likely to appear. However, since the MathML uses entity names extensively (see the discussion of <mchar> below for discussion of why this is so) the MathML DTD must point to something in declaring entity names.

A wide variety of solutions was considered: publishing two DTDs, one using PUA codepoints, and one using the tentative assignments, publish an incomplete or invalid DTD, etc. However, in the light of

  • the small number of changes anticipated to proposed code points (this from advice from well-placed people at Unicode and the state of the Unicode process concerning these characters)
  • the very negative ramifications for MathML and MathML implementations of doing anything other than listing the tentative code points

it was ultimately agreed that the MathML spec would continue to publish character tables and a DTD incorporating the provisional codepoints. But, Chapter 6 now goes to great lengths to identify the provisional assignments (color coding, text), to warn implementors of the possible risk of relying on the assignments, and to admonish them to be prepared to change their implementations should the final code-point assignments change.

A second thread considered what the role of proposed Unicode Mathematical Alphabetic Symbols should be in MathML. These characters represent various alphabetics used as symbols, such as "bold italic x". They are still provisional, but only one step away from adoption in Unicode 3.1.

They are quite desirable from the point of view of MathML in that they

  • properly insulate typographically distinguished alphabetic symbols from styling mechanisms that might inadvertently change meaning.
  • reflect the true semantic usage of letter-symbols in mathematics
  • fit very nicely with legacy practice; TeX and many STM publishers maintain separate fonts for these letter-like symbols already, since they differ in spacing and ligature conventions from their text counterparts.

However, they also cause problems in that

  • There is an interim implementation problem, since they are in Unicode Plane 1, and wide spread system support for Plane-1 characters is not yet available.
  • Any BMP + markup scheme for interim encoding leads to multiple representations for expressions.

To address these drawbacks, it was ultimately agreed that MathML would provide a markup-based interim encoding using a mathvariant attribute. Certain MathML token elements containing a single BMP character with particular mathvariant attribute values are defined to be canonically equivalent to the same token elements containing the corresponding Mathematical Alphabetic Symbol. This leads to exactly two representations for these characters, but the correspondence can be simply and precisely defined. This is done in Chapter 6.

Resolution: We had several discussions with both members of the I18N WG and of the Unicode Technical Committee. They suggested suitable formulations of caveats and descriptions of the situation vis-a-vis Unicode and ISO 10646. Chapter 6 was completely rewritten, and the character tables were extensively redesigned. Explanatory text was also added elsewhere in the spec to make sure that the proper usage of character data in MathML is clear, and that the official status of characters is also clear.
Summary:Various technical errors in the MathML character tables
Submitted:Roger Sidje, http://lists.w3.org/Archives/Public/www-math/msg00775.html
Neil Soiffer, http://lists.w3.org/Archives/Member/w3c-math-wg/2000AprJun/0175.html (W3C Member URI)
Neil Soiffer, http://lists.w3.org/Archives/Member/w3c-math-wg/2000AprJun/0252.html (W3C Member URI)
Robert Miner, http://lists.w3.org/Archives/Member/w3c-math-wg/2000AprJun/0149.html (W3C Member URI)
Discussion:After the substantive issues discussed above were resolved, correcting the substance and improving the presentation of the character tables was straight-forward.
Resolution:Done. See the new tables.

Corrections and Additions to the MathML DOM
Summary:DOM should be defined to be normative
Submitted:Lauren Wood, http://lists.w3.org/Archives/Public/www-math/msg00760.html
Discussion:We agree that this should be done.
Resolution:The MathML DOM is now normative.
Summary:MathML DOM needs to define an IDL package.
Submitted:Lauren Wood, http://lists.w3.org/Archives/Public/www-math/msg00760.html
Pankaj Kamthan, http://lists.w3.org/Archives/Public/www-math/msg00812.html
Pankaj Kamthan, http://lists.w3.org/Archives/Public/www-math/msg00823.html
Discussion:It is agreed that IDL, Java, and ECMAScript packages should be prepared.
Resolution:These have been added.
Summary:MathML DOM should use DOM Level 2
Submitted:Lauren Wood, http://lists.w3.org/Archives/Public/www-math/msg00760.html
Discussion:In fact, DOM Level 2 is used throughout. There was one reference to DOM Level 1, which was in error.
Resolution:The reference has been changed to DOM Level 2.
Summary:A number of technical and typographical corrections, especially in Appendix E.
Submitted:Lauren Wood, http://lists.w3.org/Archives/Public/www-math/msg00760.html
Susan Lesch, http://lists.w3.org/Archives/Public/www-math/msg00782.html
Discussion:These should be repaired.
Resolution:All of the technical and typographical errors pointed out have been fixed.
Summary:The MathML DOM should define a "hasFeature" string.
Submitted:Lauren Wood, http://lists.w3.org/Archives/Public/www-math/msg00760.html
Discussion:This will be done.
Resolution:The string "org.w3c.dom.mathml" will be used. A paragraph stating this has been added to Chapter 8.
Summary:Statements in Chapter 8 regarding the DOM Level 2 support for "cascaded, computed or actual style values for a specific element" are incorrect.
Submitted:Lauren Wood, http://lists.w3.org/Archives/Public/www-math/msg00760.html
Discussion:This is entirely true. These statements will be removed.
Resolution:Chapter 8 now contains no reference to DOM style support..
Summary:A statement in Chapter 8 that the MathML DOM encodes syntactical restrictions imposed by MathML was questioned. Since the Core doesn't provide any syntactical restrictions, how can this statement be enforced?
Submitted:Lauren Wood, http://lists.w3.org/Archives/Public/www-math/msg00760.html
Discussion:The MathML DOM uses Core DOMExceptions - in particular, the HIERARCHY_REQUEST_ERR - to enforce certain of these restrictions. Additionally, some differences in the types of attributes and method parameters defined in the various MathML DOM interfaces may be seen as enforcement.
Resolution:In the absence of further comment, the statement will be left as is.
Summary:The MathMLDOMImplementation method for creation of a top-level MathMLmathElement (corresponding to the top-level <math> element), rather than using a "MathMLDocument::create" method, was questioned. Also, the "parent" parameter to this method is unnecessary.
Submitted:Lauren Wood, http://lists.w3.org/Archives/Public/www-math/msg00760.html

Agreement on the "parent" parameter. This has been deleted.

The use of MathMLDOMImplementation to create a MathMLmathElement is predicated on the expected primary usage of MathML as embedded in documents of other types, but always inside a top-level <math> element. This interface and method are intended to provide a hook allowing a hosting document's DOM to instantiate a MathML DOM via an external agent such as a plug-in.

The entire issue of interaction between differing DOM implementations representing sections of a single document is unresolved at this point. We feel that some separation of factory methods from the Document interface may be part of the ultimate resolution; the issue is being studied currently. Since the MathML 2.0 specification is intended to remain stable for some time after promulgation, there is a concern that some hook which could play the role of accessing factory methods without a Document interface might allow a reasonable interaction between implementations of the MathML DOM and ambient DOM implementations.


For the time being, this functionality, and the MathMLmathElement::createMathElement() method, are being left in the MathML specification.

Summary:The MathMLDocumentFragment interface should not be derived from MathMLElement. In particular, it should have no style, class, or id attributes. Its use in read-only attributes to return certain child Nodes of other interfaces is felt to be inappropriate, as a child Node of a MathMLDocumentFragment could not be simultaneously a child of another Node.
Submitted:Lauren Wood, http://lists.w3.org/Archives/Public/www-math/msg00760.html

It is agreed that this should not derive from MathMLElement. Also, the disputed usage of this interface is indeed at odds with the spirit of DocumentFragment.

Resolution:The MathMLDocumentFragment interface is now derived simply from the DocumentFragment interface. The usage as a container for children of other Nodes has been moved to the new interface MathMLNodeList, derived trivially from NodeList but intended to contain MathMLElement Nodes and Text Nodes only.

Typographical and Editorial Corrections
Summary:A number of minor editorial corrections and suggestions
Submitted:Susan Lesch, http://lists.w3.org/Archives/Public/www-math/msg00782.html
Discussion:David points out that the use of 'lower case' and 'upper case' instead of 'lowercase' and 'uppercase' was done for compatibility with old ISO specifications. Apart from that, we will take Susan's suggestions.
Summary:Two technical errors in XSL examples in Chapter 5
Submitted:Sharon Adler, http://lists.w3.org/Archives/Public/www-math/msg00785.html
Discussion:Not controversial.
Summary:Numerous proofreading errors, editorial suggestions, and references
Submitted:Pankaj Kamthan, http://lists.w3.org/Archives/Public/www-math/msg00793.html
Pankaj Kamthan, http://lists.w3.org/Archives/Public/www-math/msg00795.html
Pankaj Kamthan, http://lists.w3.org/Archives/Public/www-math/msg00807.html
Pankaj Kamthan, http://lists.w3.org/Archives/Public/www-math/msg00822.html
Pankaj Kamthan, http://lists.w3.org/Archives/Public/www-math/msg00828.html
Pankaj Kamthan, http://lists.w3.org/Archives/Public/www-math/msg00829.html
Pankaj Kamthan, http://lists.w3.org/Archives/Public/www-math/msg00843.html
Stephane Dalmas, http://lists.w3.org/Archives/Member/w3c-math-wg/2000AprJun/0121.html (W3C Member URI)
Discussion:Mostly of the proposed changes were non-controversial, though a number involved editorial policy decisions. Thus in some cases, we opted not to take the suggestions.
Resolution:Mostly done.
Summary:New internet media type for MathML
Submitted:Murata Makoto, http://lists.w3.org/Archives/Public/www-math/msg00831.html
Pankaj Kamthan, http://lists.w3.org/Archives/Public/www-math/msg00839.html
Discussion:We monitored the discussion on XML MIME type standards and have modified the text to reflect the latest information available. We also put in a warning that the MIME type given is not yet a standard, and thus implementors must be prepared to change in the future if necessary.

Mixing math and natural language
Summary:Rendering of some content markup is language dependent.
Submitted:Andreas Strotmann, http://lists.w3.org/Archives/Public/www-math/msg00714.html
Martin J. Duerst, http://lists.w3.org/Archives/Member/w3c-math-wg/2000AprJun/0147.html (W3C Member URI)
Discussion: The names of the elements are completely separate from how such content elements, and/or their applications is displayed. The sample renderings for content elements are just that, sample renderings. It is perfectly appropriate for the sample renderings in another language to be localized by using different vocabulary.
Resolution:Make it clearer in the discussion that the sample renderings of content elements can be localized.

Reservations about the mchar element
Summary:The mchar element was introduced in MathML 2.0 so that MathML instances using 'MathML characters' could be well-formed without a DTD. In part, this was done to facilitate use with XML Schemas. Objections that this move is premature and hard to implement were raised in several quarters.
Submitted:Roger Sidje, http://lists.w3.org/Archives/Public/www-math/msg00771.html
Martin J. Duerst, http://lists.w3.org/Archives/Member/w3c-math-wg/2000AprJun/0147.html (W3C Member URI)
Dan Connolly, http://lists.w3.org/Archives/Public/www-math/msg00763.html
Dan Connolly, http://lists.w3.org/Archives/Member/w3c-math-wg/2000AprJun/0063.html (W3C Member URI)
Discussion: In light of the widespread objection to the proposal, we put the question of named character entities in MathML first to the XML Schema group. They opted not to decide the issue, since it would involve changes directly to XML. However, since the problem also affected other groups, notably HTML, we then put the issue before the W3C Team. Ultimately were told that we should stick with entities for now, in spite of the drawbacks.
Resolution:The mchar element has been removed in the proposed Candidate Recommendation, and a discussion of the issues surrounding 'DTD-less' usage of MathML has been added.

Miscellaneous Content Markup Issues
Summary:A request that inverse hyperbolic trigonometric functions to be prefixed with 'ar' instead of 'arc' on philosophical grounds.
Submitted:Leszek Sczaniecki, http://lists.w3.org/Archives/Public/www-math/msg00780.html
Discussion:A quick double check of mathematical reference works strongly reinforced the Math WG's position that, philosophy aside, the 'arc' prefix is the standard and widespread convention.
Resolution:No change.
Summary:Proposal to change 'definitionURL' to 'definitionURI'
Submitted:Pankaj Kamthan, http://lists.w3.org/Archives/Public/www-math/msg00793.html
Discussion: While it is true that the intended values of this attribute are URI's, there are also backward compatibility issues. The attribute name definitionURL was used in MathML 1.0. If we were to change the name of this attribute, applications would still need to support both during the period in which definitionURL was deprecated, causing additional compatibility issues.
Resolution:Leave the attribute name as definitionURL.
Summary:Issues with quantifiers in content markup
Submitted:Andreas Strotmann, http://lists.w3.org/Archives/Public/www-math/msg00674.html
Discussion: On reviewing this issue it quickly became clear that restricting the use of named arguments to the already defined elements that understood them was too restrictive. In particular, it prevents users from making use of the named arguments such as <bvar> when defining their own extensions to MathML for purposes of, say, specialized quantifiers.
Resolution:Allow named arguments ( "qualifiers" ) in all <apply> constructions, subject only to the restriction that such usage be correct only when the definition of the function being applied takes into account such usage. Note that such definitions may be provided by the user through use of a definitionURL and/or <csymbol>s.
Summary:Big O-notation and related asymptotic concepts
Submitted:David Eppstein , http://lists.w3.org/Archives/Public/www-math/msg00683.html
Discussion: The request for additional built-in functions supporting these important concepts in asymptotic analysis was carefully considered. (1) The public list discussion and discussions with in the working group made it clear that there was no quick consensus on the best way to introduce the concept. (2) The functionality was on the edge of the stated K-14 domain. (3) The existing extension mechanism, based on providing a definition for a <csymbol> object, is adequate to gain experience with any of the possible approaches, perhaps leading to explicit support in a future extension to MathML.
Resolution:It has been decided not to include additional functions for asymptotic analysis at this time.
Summary:Some confusion about the proper definition of moments, gcd etc.
Submitted:James Davenport, http://lists.w3.org/Archives/Public/www-math/msg00687.html
William F. Hammond, http://lists.w3.org/Archives/Public/www-math/msg00718.html

The discussion surrounding gcd involved two points. (1) The name "gcd" is language specific. (2) There are a number of gcd concepts depending on the mathematical domain one is considering. Alternative gcd definitions can be accommodated by use of definitionURL and/or <csymbol>.

The discussion regarding moments was triggered by the fact that the definition depends on the point about which the moment is computed, e.g., central moments. It was noted that the name of an element need not have anything to do with how it is displayed (visually or aurally). The idea emerged that a new qualifier capturing the concept of "moment about" was in order.

Resolution:Add a new qualifier element, <momentabout>, to describe how the moment is to be considered. There is a default behavior for when this qualifier is not explicitly used. The qualifier can specify concepts such as "moment about the mean" by specifying the function used to compute the point ( e.g., <mean/*>) as the argument to the qualifier.
Summary:Proposal to add some missing constructs
Submitted:Andreas Strotmann, http://lists.w3.org/Archives/Public/www-math/msg00716.html
Discussion: This discussion looked at a number of concepts that potentially needed explicit representation. They included: 1) the notion of application. Does this need a new element, or can an empty <apply> be used? 2) Cartesian product. Should an operator exist explicitly for this, or is it handled by applying <times/> to two or more sets? 3) Use of vectors or-lists to represent n-tuples. Do we need an explicit "tuple" container? 4) mechanisms for referring to a set, list, function, quantifier, predicate as concepts. These concepts do not have a default rendering, but could well be regarded as within the vocabulary of MathML for K-13.
Resolution:1) and 4) The need for noun forms of these various mathematical constructs mentioned here (all containers in MathML) is genuine in the same way that the need for a noun form for a function was needed separate from application of that same function to 0 arguments, but was viewed as quite specialized in that no algebra of such objects is generally dealt with in K-13. If explicit representations are wanted in some context, they can already be represented by use of <csymbol> with appropriate definitionURL's. Thus the working group has elected not to introduce any new elements to explicitly represent the noun forms of these containers. 2) Cartesian product is adequately represented by applying the <times> operator to two or more sets and this is to be made explicit in the signatures in Appendix C. 3) It has been decided to continue to use lists and/or vectors to represent n-tuples at this time since whenever the standard definitions of a list (or vector) are inappropriate, the simple act of adding a definitionURL can be used to transform them into an appropriately defined object.

Style Attributes on Presentation Token Elements
Summary:A proposal was made to remove or deprecate the 'style' attributes on presentation token elements.
Submitted:Daniel Dardailler (reposted by Angel Diaz), http://lists.w3.org/Archives/Member/w3c-math-wg/2000AprJun/0138.html (W3C Member URI)
Hakon Lie, http://lists.w3.org/Archives/Public/www-math/msg00771.html
Daniel Dardailler (reposted by Angel Diaz), http://lists.w3.org/Archives/Member/w3c-math-wg/2000AprJun/0217.html (W3C Member URI)

MathML 1.01 allowed 'fontfamily', 'fontweight', 'fontslant', 'color' and 'background' attributes on presentation token elements. The MathML 2.0 last call draft made no change in this regard, and also permits these attributes. After some analysis, the Math WG has concluded that these attributes were being overloaded to carry both semantic and style information. We propose a remedy that attempts to separate these functions to preserve the semantic usage while improving compatibility with CSS styling in CSS-aware environments.

The main problem is that mathematics treats style information for single character symbols in a completely different way than style information works with text. In mathematics, fraktur g and bold g are two distinct symbols, and not the same character styled in two ways, just as an 'alpha' is not a styled 'a' in either mathematics or text. Preserving the conventional usage and meaning of these typographically distinguished symbols is important for MathML. Moreover, because typographically distinguished symbols carry meaning in mathematical expressions, encapsulating the description of these symbols directly in MathML markup alone is a requirement for MathML. It is essential for interoperability in a variety of non-CSS aware systems.

Recent developments concerning mathematical characters in Unicode are another important factor in the discussion. Since there has long been difficulty in mathematical publishing distinguishing between a "styled character" and a "typographically distinguished symbol", major science and technology publishers mounted a multi-year campaign to have special Unicode characters allocated for typographically distinguished characters. This effort was successful, and it is now essentially definite that in Unicode 3.1, there will be 13 runs of these alphabetic symbol characters in Unicode Plane 1. At that point, there will be code points for characters such as "math bold italic x" and "math fraktur g". The Math WG strongly supports the use of these new characters, and feels that MathML 2.0 should provide a transitional markup equivalent for these new characters for use until there is widespread support for these new characters in processing applications and fonts .

Finally, it is also true that certain presentational attributes of mathematical equations really are generic 'style information' in the CSS sense. For example, the base font and base point size for an entire equation can be changed without risk of information loss. For accessibility, and for reasons of improved information management, it is desirable to distinguish these meaning-neutral presentation properties from the presentational properties of typographically distinguished symbols.

The Math WG proposes the following remedy, which we believe addresses all of the issues raise above.

  1. MathML 2.0 will deprecate the fontfamily, fontweight, fontslant, color and background attributes.

  2. MathML 2.0 will introduce new attributes aimed specifically at describing typographically distinguished symbols:

    mathvariantnormal | bold | italic | bold-italic | double-struck | script | bold-script| fraktur | bold-fraktur | sans-serif | sans-serif-bold | sans-serif-italic | sans-serif-bold-italic | monospace
    mathsizesmall|normal|big|CSS size spec
    mathcolorCSS color spec
    mathbackgroundCSS color spec
  3. In the text of the MathML 2.0 specification these new attributes will be described in two ways. They will be described technically in relation to the new Unicode Plane-1 Mathematical Alphabetic Symbols. Second they will be discussed in relation to writing CSS stylesheets.

  4. In the MathML 2.0 specification, we will state the guidelines for CSS/MathML interoperability in CSS-aware environments. These guidelines will appear in context with the discussion of the attributes, and in the section on compliance.

Resolution: New material has been added to Chapter 3 (presentation markup) introducing the new mathematical style attributes, and explaining their use and meaning. A new discussion of Unicode revisions and the Plane 1 mathematical characters has been added to Chapter 6 (MathML characters), along with definitive character tables. A new section has been added to Chapter 7 (interface issues) discussing issues related to using CSS with MathML, and a sample style CSS stylesheet has been added as an Appendix.

Test Suite and Validator Links
Summary:There were several enquiries as to why links to the MathML test suite and validator aren't active.
Submitted:Luis Alvarez Sobreviela, http://lists.w3.org/Archives/Public/www-math/msg00783.html
'Ariel', http://lists.w3.org/Archives/Public/www-math/msg00833.html
Discussion:The test suite and validator are the subject of ongoing development by working group members and other members of the MathML community. Since both of these applications require a good deal of web development, the people doing the work concluded that it wasn't effective to try to work directly on the W3C servers. Consequently, work will proceed on various external Web sites, but the spec will point to place holder pages under www.w3.org/Math, which will in turn refer readers to the most up to date versions of the test suite and validator. As stable versions of the test suite and validator become available, the intention is to move them to the W3C servers. A preview version of the test suite is already available in the Members area.
Resolution:Place holder pages have been installed at http://www.w3.org/Math/testsuite and http://www.w3.org/Math/validator. Work on the actual test suite and validator is ongoing, but substantial progress has been made. We anticipate replacing the placeholders during the CR period.
Summary:Suggested improvements to the test suite
Submitted:Vincent Quint, http://lists.w3.org/Archives/Member/w3c-math-wg/2000AprJun/0060.html (W3C Member URI)
Discussion:Vincent Quint suggested a number of non-controversial improvements.
Resolution:They are being incorporated as time and resources permit.

XSL Processing
Summary:A suggestion was made to reverse the roles of ids and xrefs in the cross-references mechanism described in Chapter 5 of the MathML 2 specification for performance reasons, since ids are typically indexed while xrefs are not.
Submitted:Sharon Adler, http://lists.w3.org/Archives/Public/www-math/msg00785.html

The changes suggested in Comment 1 (on editorial errors) have been applied in the Candidate Recommendation.

The second comment relates to the order of "id"s and "xref"s in parallel markup. The observation was that this cross-referencing scheme could be computationally intensive if one had to follow links in the "wrong" direction, and asks whether some additional restrictions should be imposed, or the direction of the links reversed.

This is potentially an issue, depending on the implementation. It is important to realize that the application is free to choose which branch receives the "id"s and which branch has the "xref"s. This allows applications to follow the practice suggested in the e-mail, and to put the links in the other direction if it chooses. This is noted in the fourth paragraph from the last in the current section 5.3.3.

It should also be noted that since there may be more than two branches in a <semantics> element, these cross-references may be multi-way associations and there is more than the question of choosing one direction or the other.

Finally, for computationally intensive tasks on intricate linkings an application may choose to use any of the various mechanisms of XLink internally within the MathML object.


The comments from the XSL group have all been addressed in new text in Chapter 5.


W3C contact for Math Working Group: Dave Raggett.
Last revised: 2000/11/08 by pdfion

Copyright    2000 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability,trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.

Valid HTML 4.0!