6 Interactions of MathML with the Host Environment

6.2.1 Recognizing MathML in an XML Model

Within an XML document supporting namespaces [XML], [Namespaces], the preferred method to recognize MathML markup is by the identification of the math element in the appropriate namespace, i.e. that of URI http://www.w3.org/1998/Math/MathML.

This is the recommended method to embed MathML within [XHTML] documents. Some user-agents' setup may require supplementary information to be available.

Markup-language specifications that wish to embed MathML may provide special conditions or recognizing MathML independently of this recommendation. The conditions should be similar to those expressed in this recommendation and the elements' local-names should remain the same.

6.2.2 Resource Types for MathML Documents

Although rendering MathML expressions often occurs in place in a Web browser, other MathML processing functions take place more naturally in other applications. Particularly common tasks include opening a MathML expression in an equation editor or computer algebra system. It is important therefore to specify the encoding names with which MathML fragments should be called.

Outside of the conditions of an XML environment where namespaces are recognized, media types [RFC2045], [RFC2046] should be used if possible to to ensure the invocation of a MathML processor. In the cases where media types are not usable, for example in some clipboard environments, the names described in the next section should be used.

6.2.3 Names of MathML Encodings

MathML contains two distinct vocabularies: one for encoding mathematical semantics defined in Chapter 4 Content Markup and one for encoding visual presentation defined in Chapter 3 Presentation Markup. Some MathML-aware applications import and export only one of these vocabularies, while other may be capable of producing and consuming both. The following three encoding names should be used to distinguish between content and presentation MathML when needed.

• MathML Presentation: Instance contains presentation MathML markup only

  • Windows Flavor Name: MathML Presentation

  • Media Type: application/mathml-presentation+xml

  • Universal Type Identifier: public.mathml.presentation

• MathML Content: Instance contains content MathML markup only

  • Windows Flavor Name: MathML Content

  • Media Type:application/mathml-content+xml

  • Universal Type Identifier: public.mathml.content

• MathML (generic): Any well-formed MathML instance presentation markup, content markup, or a mixture of the two is allowed

  • Windows Flavor Name:MathML

  • Media Type: application/mathml+xml

  • Filename extension:.mml

  • Universal Type Identifier: public.mathml

See Appendix B Media Types Registrations for more details about each of the encoding names.

Supplementary to these names, the clipboard flavor names MathML-Content, and MathML-Presentation have been used and are now deprecated; moreover, in MathML 1.0, the media-type text/mathml was suggested, this has been superceded by [RFC3023].

6.3.1 Basic Transfer Flavors' Names and Contents

Note that the names indicated in Section 6.2.3 Names of MathML Encodings are the exact strings that should be used to describe the flavors corresponding to the encodings. On operating systems that allow such, applications should register such names (e.g. a call to Windows' RegisterClipboardFormat on launch or, on the Macintosh platform, the declaration of the support for the universal type in the application descriptor).

When transferring MathML, for example when placing it within a clipboard, an application MUST ensure the content is a well-formed XML instance of a MathML schema. Specifically:

1. The instance MUST begin with a XML declaration, e.g. <?xml version="1.0">

2. The instance MUST contain exactly one root math element.

3. Since MathML is frequently embedded within other XML document types, the instance MUST declare the MathML namespace on the root math element. In addition, the instance MAY use a schemaLocation attribute on the math element to indicate the location of MathML schema documents against which the instance is valid. Note that the presence of the schemaLocation attribute does not require a consumer of the MathML instance to obtain or use the cited schema documents.

4. The instance MUST use numeric character references (e.g. &#x03b1;) rather than character entity names (e.g. &alpha;) for greater interoperability.

5. The character encoding for the instance MUST be either specified in the XML header, UTF-16, or UTF-8. UTF-16-encoded data MUST begin with a byte-order mark (BOM). If no BOM or encoding is given, the character encoding will be assumed to be UTF-8.

6.3.2 Recommended Behaviors when Transferring

Applications that transfer MathML SHOULD adhere to the following conventions:

1. Applications that have pure presentation markup and/or pure content markup versions of an expression SHOULD offer as many of these two flavors as are available.

2. Applications that only export one MathML flavor should name it MathML if they don't know its nature. If they do, they should offer both the generic and specific transfer types but should only deliver the specific types if they know the recipient will support it. For the HTTP GET transfer, this means that the specific transfer types (presentation, content) should only be returned if the Accept HTTP header includes it. Applications that export the two specific transfer types should export the content and presentation transfer types as well as the generic flavor which combines the two others using a top-level MathML's semantics element (see Section 5.4.1 Top-level Parallel Markup).

3. When an application exports a MathML fragment whose only child of the root element is a semantics element, it SHOULD offer, after the flavors above in the preference order, a flavor for each annotation or annotation-xml element that has a clipboardflavor attribute: the flavor name should be given by the clipboardflavor attribute value of the annotation or annotation-xml element, and the content should be the child text in the surrounding encoding (if the annotation element contains only textual data), a valid XML fragment (if the annotation-xml element contains children), or the data resulting of requesting the URL given by the href attribute.

   User-agents implementors should be aware that the fragments contained in the clipboard could be used in a insecure way: indeed, opening a fragment in a receiving application will execute the programmes it contains, for example embedded scripts, and this without the traditional security restrictions of web-content. User-agent implementors should, thus, only allow transfer of safe content flavors, maybe resorting to a sanitization process.

4. As a final fallback applications MAY export a version of the data in plain-text flavor (such as text/plain, CF_UNICODETEXT, UnicodeText, NSStringPboardType, ...). When an application has multiple versions of an expression available, it may choose the version to export as text at its discretion. Since some older MathML-aware programs expect MathML instances transferred as text to begin with a math element, the text version should generally omit the XML declaration, DOCTYPE declaration and other XML prolog material before the math element. Similarly, the BOM should be omitted for Unicode text encoded as UTF-16. Note, the Unicode text version of the data should always be the last flavor exported, following the principle that exported flavors should be ordered with the most specific flavor first and the least specific flavor last.

6.3.3 Discussion

For purposes of determining whether a MathML instance is pure content markup or pure presentation markup, the math element and the semantics, annotation and annotation-xml elements should be regarded as belonging to both the presentation and content markup vocabularies. This is obvious for the root math element which is required for all MathML expressions. However, the semantics element and its child annotation elements comprise an arbitrary annotation mechanism within MathML, and are not tied to either presentation or content markup. Consequently, applications consuming MathML should always process these four elements even if the application only implements one of the two vocabularies.

It is worth noting that the above recommendations allow agents producing MathML to provide binary data for the clipboard, for example as an image or an application-specific format. The sole method to do so is to reference the binary data by the href attribute since XML character data does not allow arbitrary byte-streams.

While the above recommendations are intended to improve interoperability between MathML-aware applications utilizing the transfer features, it should be noted that they do not guarantee interoperablility. For example, references to external resources (e.g. stylesheets, etc.) in MathML data can also cause interoperability problems if the consumer of the data is unable to locate them, just as can happen when cutting and pasting HTML or many other data types. Applications that make use of references to external resources are encouraged to make users aware of potential problems and provide alternate ways for obtaining the referenced resources. In general, consumers of MathML data containing references they cannot resolve or do not understand should ignore them.

6.3.4 Examples

<?xml version="1.0"?>
<math xmlns="http://www.w3.org/1998/Math/MathML">...</math>

<math xmlns="http://www.w3.org/1998/Math/MathML">...</math>

<?xml version="1.0"?>
<math xmlns="http://www.w3.org/1998/Math/MathML">...</math>

<math xmlns="http://www.w3.org/1998/Math/MathML">...</math>

<?xml version="1.0"?>
<mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://www.w3.org/Math/XMLSchema/mathml3/mathml3.xsd">
  <mml:mrow>
  ...
  <mml:mrow>
</mml:math>

<?xml version="1.0"?>
<mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://www.w3.org/Math/XMLSchema/mathml3/mathml3.xsd">
  <mml:apply>
  ...
  <mml:apply>
</mml:math>

<?xml version="1.0"?>
<mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://www.w3.org/Math/XMLSchema/mathml3/mathml3.xsd">
  <mml:mrow>
    <mml:apply> ... content markup within presentation markup ... </mml:apply>
    ...
  </mml:mrow>
</mml:math> 

{x \over x-1}

<mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://www.w3.org/Math/XMLSchema/mathml3/mathml3.xsd">
  <mml:mrow>
  ...
  <mml:mrow>
</mml:math>

<mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML">
  <mml:semantics>
    <mml:mrow>...</mml:mrow>
    <mml:annotation-xml encoding="MathML Content">...</mml:annotation-xml>
    <mml:annotation clipboardflavor="TeX">{1 \over x}</mml:annotation>
    <mml:annotation clipboardflavor="image/png" href="formula3848.png"/>
  </mml:semantics>
</mml:math>

<?xml version="1.0"?>
<mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://www.w3.org/Math/XMLSchema/mathml3/mathml3.xsd">
  <mml:mrow>
  ...
  <mml:mrow>
</mml:math>

<?xml version="1.0"?>
<mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://www.w3.org/Math/XMLSchema/mathml3/mathml3.xsd">
  <mml:apply>
  ...
  <mml:apply>
</mml:math>

<?xml version="1.0"?>
<mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://www.w3.org/Math/XMLSchema/mathml3/mathml3.xsd">
  <mml:mrow>
    <mml:apply> ... content markup within presentation markup ... </mml:apply>
    ...
  </mml:mrow>
</mml:math> 

{x \over x-1}

<mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://www.w3.org/Math/XMLSchema/mathml3/mathml3.xsd">
  <mml:mrow>
  ...
  <mml:mrow>
</mml:math>

6.4.1 Mixing MathML and HTML

In order to fully integrate MathML into XHTML, it should be possible not only to embed MathML in XHTML, as described in Section 6.2.1 Recognizing MathML in an XML Model, but also to embed XHTML in MathML. However, the problem of supporting XHTML in MathML presents many difficulties. Therefore, at present, the MathML specification does not permit any XHTML elements within a MathML expression, although this may be subject to change in a future revision of MathML.

In most cases, XHTML elements (headings, paragraphs, lists, etc.) either do not apply in mathematical contexts, or MathML already provides equivalent or better functionality specifically tailored to mathematical content (tables, mathematics style changes, etc.). However, there are two notable exceptions, the XHTML anchor and image elements. For this functionality, MathML relies on the general XML linking and graphics mechanisms being developed by other W3C Activities.

<body>
...
<m:math xmlns:m="http://www.w3.org/1998/Math/MathML">
<m:mrow>...<m:mrow>
</m:math>
...
</body>

6.4.2 Linking

In MathML 3, an element is designated as a link by the presence of the href attribute. MathML has no element that corresponds to the HTML/XHTML anchor element a.

MathML allows the href attribute on all elements. However, links on elements that do not correspond to any part of a typical visual rendering should be avoided, since they will have no effect in typical user agents.

The list of presentation markup elements that do not ordinarily have a visual rendering, and thus should not be used as linking elements, is given in the table below.

Note that MathML 2 had no direct support for linking, and followed the W3C Recommendation "XML Linking Language" [XLink] in defining links using an xlink:href attribute. This has changed, and MathML 3 now uses the href attribute for linking. However, particular compound document formats may specify the use of XML Linking with MathML elements. So, user agents that implement XML Linking in compound documents containing MathML should continue to support the use of the xlink:href attribute with MathML 3 as well.

For compound document formats that use XML Linking or other format-specific linking mechanisms, the id attribute should be used to specify locations for links into a MathML expressions. The id attribute is allowed on all elements, and values must be unique within the document, making it ideal for the this purpose.

6.4.3 MathML and Graphical Markup

Apart from the introduction of new glyphs, many of the situations where one might be inclined to use an image amount to displaying labeled diagrams. For example, knot diagrams, Venn diagrams, Dynkin diagrams, Feynman diagrams and commutative diagrams all fall into this category. As such, their content would be better encoded via some combination of structured graphics and MathML markup. However, at the time of this writing, it is beyond the scope of the W3C Math Activity to define a markup language to encode such a general concept as "labeled diagrams." (See http://www.w3.org/Math for current W3C activity in mathematics and http://www.w3.org/Graphics for the W3C graphics activity.)

One mechanism for embedding additional graphical content is via the semantics element, as in the following example:

<semantics>
  <apply>
    <intersect/>
    <ci>A</ci>
    <ci>B</ci>
  </apply>
  <annotation-xml encoding="SVG1.1">
    <svg xmlns="http://www.w3.org/2000/svg"  viewBox="0 0 290 180">
      <clipPath id="a">
      <circle cy="90" cx="100" r="60"/>
      </clipPath>
      <circle fill="#AAAAAA" cy="90" cx="190"
              r="60" style="clip-path:url(#a)"/>
      <circle stroke="black" fill="none" cy="90" cx="100" r="60"/>
      <circle stroke="black" fill="none" cy="90" cx="190" r="60"/>
    </svg>
  </annotation-xml>
  <annotation-xml encoding="application/xhtml+xml">
    <img xmlns="http://www.w3.org/1999/xhtml" src="intersect.gif" alt="A intersect B"/>
  </annotation-xml>
</semantics>

Here, the annotation-xml elements are used to indicate alternative representations of the Content MathML depiction of the intersection of two sets. The first one is in the "Scalable Vector Graphics" format [SVG1.1] (see [XHTML-MathML-SVG] for the definition of an XHTML profile integrating MathML and SVG), the second one uses the XHTML img element embedded as an XHTML fragment. In this situation, a MathML processor can use any of these representations for display, perhaps producing a graphical format such as the image below.

Note that the semantics representation of this example is given in Content MathML markup, as the first child of the semantics element. In this regard, it is the representation most analogous to the alt attribute of the img element in XHTML, and would likely be the best choice for non-visual rendering.

6.5.1 Order of processing attributes versus style sheets

CSS or analogous style sheets can specify changes to rendering properties of selected MathML elements. Since rendering properties can also be changed by attributes on an element, or be changed automatically by the renderer, it is necessary to specify the order in which changes requested by various sources should occur. An example of automatic adjustment is what happens for fontsize, as explained in the discussion on scriptlevel in Section 3.3.4 Style Change <mstyle>. In the case of "absolute" changes, i.e., setting a new property value independent of the old value (as opposed to "relative" changes, such as increments or multiplications by a factor), the absolute change performed last will be the only absolute change which is effective, so the sources of changes which should have the highest priority must be processed last.

In the case of CSS, the order of processing of changes from various sources which affect one MathML element's rendering properties should be as follows:

(first changes; lowest priority)

• Automatic changes to properties or attributes based on the type of the parent element, and this element's position in the parent, as for the changes to fontsize in relation to scriptlevel mentioned above; such changes will usually be implemented by the parent element itself before it passes a set of rendering properties to this element

• From a style sheet from the reader: styles which are not declared "important"

• Explicit attribute settings on this MathML element

• From a style sheet from the author: styles which are not declared "important"

• From a style sheet from the author: styles which are declared "important"

• From a style sheet from the reader: styles which are declared "important"

(last changes; highest priority)

Note that the order of the changes derived from CSS style sheets is specified by CSS itself (this is the order specified by CSS2). The following rationale is related only to the issue of where in this pre-existing order the changes caused by explicit MathML attribute settings should be inserted.

Rationale: MathML rendering attributes are analogous to HTML rendering attributes such as align, which the CSS section on cascading order specifies should be processed with the same priority. Furthermore, this choice of priority permits readers, by declaring certain CSS styles as "important", to decide which of their style preferences should override explicit attribute settings in MathML. Since MathML expressions, whether composed of "presentation" or "content" elements, are primarily intended to convey meaning, with their "graphic design" (if any) intended mainly to aid in that purpose but not to be essential in it, it is likely that readers will often want their own style preferences to have priority; the main exception will be when a rendering attribute is intended to alter the meaning conveyed by an expression, which is generally discouraged in the presentation attributes of MathML.