Issue 178
412 |Issue 361
413 | 414 | 415 | 416 |MathML documents should be validated using the RelaxNG Schema for MathML, either in 420 | the XML encoding (http://www.w3.org/Math/RelaxNG/mathml4/mathml4.rng) 421 | or in compact notation (https://www.w3.org/Math/RelaxNG/mathml4/mathml4.rnc) 422 | which is also shown below.
423 | 424 |In contrast to DTDs there is no in-document method to associate a RelaxNG schema with 425 | a document.
426 | 427 | 428 | 429 | 430 |MathML Core is specified in [[[MathML-Core]]] however the Schema is developed alongside the schema for MathML 4 and presented here, it can also be found at https://www.w3.org/Math/RelaxNG/mathml4/mathml4-core.rnc.
434 | 435 | 436 |The grammar for Presentation MathML 4 builds on the grammar for the MathML 442 | Core, and can be found at https://www.w3.org/Math/RelaxNG/mathml4/mathml4-presentation.rnc.
443 | 444 | 445 | 446 |The grammar for Strict Content MathML 4 can be found at https://www.w3.org/Math/RelaxNG/mathml4/mathml4-strict-content.rnc.
452 | 453 | 454 |The grammar for Content MathML 4 builds on the grammar for the Strict Content MathML 461 | subset, and can be found at https://www.w3.org/Math/RelaxNG/mathml4/mathml4-content.rnc.
462 | 463 | 464 | 465 |The grammar for full MathML 4 is simply a merger of the above grammars, 471 | and can be found at https://www.w3.org/Math/RelaxNG/mathml4/mathml4.rnc.
472 | 473 | 474 | 475 |Some elements and attributes that were deprecated in MathML 3 482 | are removed from MathML 4. This schema extends the full MathML 4 483 | schema, adding these constructs back, allowing validation of existing 484 | MathML documents. It can be found at https://www.w3.org/Math/RelaxNG/mathml4/mathml4-legacy.rnc.
486 | 487 | 488 | 489 |3 | This specification defines the Mathematical Markup Language, or 4 | MathML. MathML is a markup language 5 | for describing mathematical notation and capturing 6 | both its structure and content. The goal of MathML is to enable 7 | mathematics to be served, received, and processed on the World Wide 8 | Web, just as [[HTML]] has 9 | enabled this functionality for text. 10 |
11 |12 | This specification of the markup language MathML is intended 13 | primarily for a readership consisting of those who will be 14 | developing or implementing renderers or editors using it, or 15 | software that will communicate using MathML as a protocol for input 16 | or output. It is not a User's Guide but rather a 17 | reference document. 18 |
19 |20 | MathML can be used to encode both mathematical notation and 21 | mathematical content. About thirty-eight of the MathML tags describe 22 | abstract notational structures, while another about one hundred and 23 | seventy provide a way of unambiguously specifying the intended 24 | meaning of an expression. Additional chapters discuss how the MathML 25 | content and presentation elements interact, and how MathML renderers 26 | might be implemented and should interact with browsers. Finally, 27 | this document addresses the issue of special characters used for 28 | mathematics, their handling in MathML, their presence in Unicode, 29 | and their relation to fonts. 30 |
31 |32 | While MathML is human-readable, authors typically will 33 | use equation editors, conversion 34 | programs, and other specialized software tools to generate 35 | MathML. Several versions of such MathML tools exist, 36 | both freely available software and commercial 37 | products, and more are under development.
38 |MathML was originally specified as an XML application and most of the 39 | examples in this specification assume that syntax. Other syntaxes are possible, most 40 | notably 41 | [[HTML]] specifies the syntax for MathML in HTML. Unless explicitly noted, 42 | the examples in this specification are also valid HTML syntax. 43 |
44 |As an essential element of the Open Web Platform, the W3C MathML 11 | specification has the unprecedented potential to enable content 12 | authors and developers to incorporate mathematical expressions on the 13 | web in such a way that the underlying structural and semantic 14 | information can be exposed to other technologies. Enabling this 15 | information exposure is foundational for accessibility, as well as 16 | providing a path for making digital mathematics content machine 17 | readable, searchable and reusable
18 | 19 |The internationally accepted standards and underpinning principles 20 | for creating accessible digital content on the web can be found in the 21 | W3C's Web Content Accessibility Guidelines [[WCAG21]]. In extending 22 | these principles to digital content containing mathematical 23 | information, WCAG provides a useful framework for defining 24 | accessibility wherever MathML is used.
25 | 26 |As the current WCAG guidelines provide no direct guidance on how to 27 | ensure mathematical content encoded as MathML will be accessible to 28 | users with disabilities, this specification defines how to apply these 29 | guidelines to digital content containing MathML.
30 | 31 |A benefit of following these recommendations is that it helps to 32 | ensure that digital mathematics content meets the accessibility 33 | requirements already widely used around the world for web content. In 34 | addition, ensuring that digital mathematics materials are accessible 35 | will expand the readership of such content to both readers with and 36 | without disabilities.
37 | 38 |Additional guidance on best practices will be developed over time 39 | in [[?MathML-Notes]]. Placing these in Notes allows them to adapt and 40 | evolve independent of the MathML specification, since accessibility 41 | practices often need more frequent updating. The Notes are also 42 | intended for use with past, present, and future versions of MathML, in 43 | addition to considerations for both the MathML-Core and the full 44 | MathML specification. The approach of a separate document ensures that 45 | the evolution of MathML does not lock accessibility best practices in 46 | time, and allows content authors to apply the most recent 47 | accessibility practices.
48 |Many of the advances of mathematics in the modern world (i.e., 54 | since the late Renaissance) were arguably aided by the development of 55 | early symbolic notation which continues to be evolved in our present 56 | day. While simple literacy text can be used to state underlying 57 | mathematical concepts, symbolic notation provides a succinct method of 58 | representing abstract mathematical constructs in a portable manner 59 | which can be more easily consumed, manipulated and understood by 60 | humans and machines. Mathematics notation is itself a language 61 | intended for more than just visual rendering, inspection and 62 | manipulation, as it is also intended to express the underlying meaning 63 | of the author. These characteristics of mathematical notation have in 64 | turn a direct connection to mathematics accessibility.
65 | 66 |Accessibility has been a purposeful consideration from the very 67 | beginning of the MathML specification, as alluded to in the 1998 68 | MathML 1.0 specification. This understanding is further reflected in 69 | the very first version of the Web Content Accessibility Guidelines 70 | (WCAG 1.0, W3C Recommendation 5-May-1999), which mentions the use of 71 | MathML as a suggested technique to comply with Checkpoint 3.1, "When 72 | an appropriate markup language exists, use markup rather than images 73 | to convey information," by including the example technique to "use 74 | MathML to mark up mathematical equations..." It is also worth noting, 75 | that under the discussion of WCAG 1.0 Guideline 3, "Use markup and 76 | style sheets and do so properly," that the editors have included the 77 | admonition that "content developers must not sacrifice appropriate 78 | markup because a certain browser or assistive technology does not 79 | process it correctly." Now some 20 years after the publication of the 80 | original WCAG recommendation, we still struggle with the fact that 81 | many content developers have been slow to adopt MathML due to those 82 | very reasons. However, with the publication of MathML 4.0, the 83 | accessibility community is hopeful of what the future will bring for 84 | widespread mathematics accessibility on the web.
85 | 86 |Using MathML in digital content extends the potential to support a 87 | wide array of accessibility use cases. We discuss these below.
88 | 89 |Auditory output. Technological means of providing dynamic 90 | text-to-speech output for mathematical expressions precedes the 91 | origins of MathML, and this use case has had an impact on shaping the 92 | MathML specification from the beginning. Beyond simply generating 93 | spoken text strings, the use of audio cues such as changes in spoken 94 | pitch to help provide an auditory analog of two-dimensional visual 95 | structure has been found useful. Other audio applications have 96 | included other types of audio cues such as binaural spatialization, 97 | earcons, and spearcons to help disambiguate mathematical expressions 98 | rendered by synthetic speech. MathML provides a level of robust 99 | information about the structure and syntax of mathematical expressions 100 | to enable these techniques. It is also important to note that the 101 | ability to create extensive sets of automated speech rules used by 102 | MathML-aware TTS tools provide for virtually infinite portability of 103 | math speech to the various human spoken languages (e.g., 104 | internationalization), as well as different styles of spoken math 105 | (e.g., ClearSpeak, MathSpeak, SimpleSpeak, etc.). In the future, this 106 | could provide even more types of speech rules, such as when an 107 | educational assessment needs to apply a more restrictive reading so as 108 | not to invalidate the testing construct, or when instructional content 109 | aimed at early learners needs to adopt the spoken style used in the 110 | classroom for young students.
111 | 112 |Braille output. The tactile rendering of mathematical expressions 113 | in braille is a very important use case. For someone who is blind, 114 | interpreting mathematics through auditory rendering alone is a 115 | cognitive taxing experience except for the most basic expressions. And 116 | for a deafblind user, auditory renderings are completely 117 | inaccessible. Several math braille codes are in common use globally, 118 | such as the Nemeth braille code, UEB Technical, German braille 119 | mathematics code, French braille mathematics code, etc. Dynamic 120 | mathematics braille translators such as Liblouis support translation 121 | of MathML content on webpages for individuals who access the web via a 122 | refreshable braille display. Thus, using MathML is essential for 123 | providing dynamic braille content for mathematics.
124 | 125 |Other forms of visual transformation. Synchronized highlighting is 126 | a common addition to text-to-speech intended for sighted 127 | users. Because MathML provides the ability to parse the underlying 128 | tree structure of expressions, individual elements of the expression 129 | can be visually highlighted as they are spoken. This enhances the 130 | ability of TTS users to stay engaged with the text reading, which can 131 | potentially increase comprehension and learning. Even for people 132 | visually reading without TTS, visual highlighting within expressions 133 | as one navigates a web page using caret browsing can be a useful 134 | accessibility feature which MathML can potentially support.
135 | 136 |For individuals who are deaf or hard of hearing but are unable to 137 | use braille, mathematical equations rendered in MathML can potentially 138 | be turned into visually displayed text. Since research has shown that, 139 | especially among school-age children with reading impairments, the 140 | ability to understand symbolic notation occurring in mathematical 141 | expression is much more difficult than reading literary text, enabling 142 | this capability could be a useful access technique for this 143 | population.
144 | 145 |Another potential accessibility scaffold which MathML could provide 146 | for individuals who are deaf or hard of hearing would be the ability 147 | to provide input to automated signing avatars. Automated signing 148 | avatar technology which generates American Sign Language has already 149 | been applied to elementary level mathematics add citation. Sign 150 | languages vary by county (and sometimes locality) and are not simply 151 | "word to sign" translations, as sign language has its own grammar, so 152 | being able to access the underlying tree structure of mathematical 153 | expressions as can be done with MathML will provide the potential for 154 | representing expressions in sign language from a digital document 155 | dynamically without having to use static prerecorded videos of human 156 | signers.
157 | 158 |Graphing an equation is a commonly used means of generating a 159 | visual output which can aid in comprehending the effects and 160 | implications of the underlying mathematical expressions. This is 161 | helpful for all people, but can be especially impactful for those with 162 | cognitive or learning impairments. Some dynamic graphing utilities 163 | (e.g., Desmos and MathTrax) have extended this concept beyond a simple 164 | visual line trace, to auditory tracing (e.g., tones which rise and 165 | fall in pitch to provide an audio construct of the visual trace) as 166 | well as a dynamically generated text description of the visual 167 | graph. Using MathML in digital content will provide the potential for 168 | developers to apply such automated accessible graphing utilities to 169 | their websites.
170 | 171 |User agents (e.g., web browsers) should leverage information in the 184 | MathML expression tree structure to maximize accessibility. Browsers 185 | should process MathML into the DOM tree's internal representation, 186 | which contains objects representing all the markup's elements and 187 | attributes. In general, user agents will expose accessibility 188 | information via a platform accessibility service (e.g., an 189 | accessibility API), which is passed on to assistive technology 190 | applications via the accessibility tree. The accessibility tree should 191 | contain accessibility-related information for most MathML 192 | elements. Browsers should ensure the accessibility tree generated from 193 | the DOM tree retains this information so that Accessibility APIs can 194 | provide a representation that can be understood by assistive 195 | technologies. However, in compliance with the W3C User Agent 196 | Accessibility Guidelines Success Criterion 4.1.4, "If the user agent 197 | accessibility API does not provide sufficient information to one or 198 | more platform accessibility services, then Document Object Models 199 | (DOM), must be made programmatically available to assistive 200 | technologies" [[UAAG20]].
201 | 202 |By ensuring that most MathML elements 203 | become nodes in the DOM tree, and the resulting accessibility tree, 204 | user agents can expose math nodes for keyboard navigation within 205 | expressions. This can support important user needs such as the ability 206 | to visually highlight elements of an expression and/or speak 207 | individual elements as one navigates with arrow keys. This can further 208 | support other forms of synchronous navigation, such as individuals 209 | using refreshable braille displays along with synthetic speech.
210 |While it is common practice for the accessibility tree to ignore
211 | most DOM node elements that are primarily used for visual display
212 | purposes, it is important to point out that math expressions often use
213 | what appears as visual styling to convey information which can be
214 | important for some types of assistive technology applications. For
215 | example, omitting the <mspace>
216 | element from the accessibility tree will impact the ability to
217 | generate a valid math braille representation of expressions on a
218 | braille display. Further, when color is expressed in MathML with the
219 | mathcolor and mathbackground attributes, these elements
221 | need to be included if they are used to express meaning.
The
222 | alttext attribute can be used to
223 | override standard speech rule processing (e.g., as is often done in
224 | standardized assessments). However, there are numerous limitations to
225 | this method. For instance, the entire spoken text of the expression
226 | must be given in the tag, even if the author is only concerned about
227 | one small portion. Further, alttext is
228 | limited to plain text, so speech queues such as pausing and pitch
229 | changes cannot be included for passing on to speech engines. Also, the
230 | alttext attribute has no direct linkage
231 | to the MathML tree, so there will be no way to handle synchronized
232 | highlighting of the expression, nor will there be a way for users to
233 | navigate through an expression.
An early draft of [[[MathML-AAM]]] is
236 | available. This specification is intended for user agent developers
237 | responsible for MathML accessibility in their product. The goal of
238 | this specification is to maximize the accessibility of MathML content
239 | by ensuring each assistive technology receives MathML content with the
240 | roles, states, and properties it expects. The placing of ARIA labels
241 | and aria-labeledby is not appropriate in MathML because this will override
242 | braille generation.
This section considers how to use WCAG to establish requirements 254 | for accessible MathML content on the web, using the same four 255 | high-level content principles: that content should be perceivable, 256 | operable, understandable, and robust. Therefore, this section defines 257 | how to apply the conformance criteria defined in WCAG to address 258 | qualities unique to digital content containing MathML.
259 | 260 | 261 |It is important that MathML be used for marking up all mathematics 267 | and linear chemical equation content. This precludes simply using 268 | ASCII characters or expression images in HTML (even if alt text is 269 | used). Even a single letter variable ideally should be marked up in 270 | MathML because it represents a mathematical expression. This way, 271 | audio, braille and visual renderings of the variable will be 272 | consistent throughout the page.
273 | 274 |intent and arg attributesMathML's intent and arg attributes has
280 | been developed to reduce notational ambiguity which cannot be reliably
281 | resolved by assistive technology. This also includes blanks and units,
282 | which are covered by the Intent attribute.
Common use of mathematical notation employs several invisible
296 | operators
whose symbols are not displayed but function as if the
297 | visible operator were present. These operators should be marked up in
298 | MathML to preserve their meaning as well as to prevent possible
299 | ambiguity for users of assistive technology.
Screen readers will not speak anything enclosed in an <mphantom> element; therefore, do not use
303 | <mphantom> in combination with an
304 | operator to create invisible operators.
Implicit Multiplication: The invisible times
operator
307 | (⁢) should be used to indicate multiplication whenever the
308 | multiplication operator is used tacitly in traditional notation.
Function Application: The "apply function" operator 311 | (⁡) should be used to indicate function application.
312 | 313 | 314 |Invisible Comma: The invisible comma
or invisible
315 | separator
operator (⁣) should be used to semantically
316 | separate arguments or indices when commas are omitted.
Implicit Addition: In mixed fractions the invisible plus
319 | character (⁤) should be used as an operator between the
320 | whole number and its fraction.
It is good practice to group sub-expressions as they would be
328 | interpreted mathematically. Properly grouping sub-expressions using
329 | <mrow> can improve display by affecting spacing, allows for more
330 | intelligent linebreaking and indentation, it can simplify semantic
331 | interpretation of presentation elements by screen readers and
332 | text-to-speech applications.
In general, the spacing elements <mspace>, <mphantom>,
339 | and <mpadded> should not be used to convey meaning.
All numeric quantities should be enclosed in an <mn>
346 | element. Digit group separators, such as commas, periods, or spaces,
347 | should also be included as part of the number and should not be
348 | treated as operators.
It is important to apply superscripts and subscripts to the 355 | appropriate element or sub-expression. It is not correct to apply a 356 | superscript or subscript to a closing parenthesis or any other 357 | grouping symbol. Important for navigation
358 | 359 |Elementary notations have their own layout elements. For long
364 | division and stacked expressions use the proper elements such as <mlongdiv> and <mstack> instead of <mtable>.
Blanks in a fill-in-the-blank
style of question are often
374 | visualized by underlined spaces, empty circles, squares, or other
375 | symbols. To indicate a blank, use the intent and arg attributes.
In an interactive electronic environment where the user should fill
378 | the blank on the displayed page, JavaScript would typically be used to
379 | invoke an editor when the blank is clicked on. To facilitate this, an
380 | id should be added to the element to identify it for editing and
381 | eventual processing. Additionally, an onclick or similar event
382 | trigger should be added. The details depend upon the type of
383 | interaction desired, along with the specific JavaScript being used.
MathML provides built-in support for tables and equation numbering,
390 | which complements HTML functionality with lists and tables. In
391 | practice, it is not always clear which structural elements should be
392 | used. Ideally, a table (either HTML <table> or MathML
393 | <mtable>) should be used when information between aligned rows
394 | or columns are semantically related. In other cases, such as ordinary
395 | problem numbering or information presented in an ordered sequence, an
396 | HTML ordered list <ol>; is more appropriate.
Choosing between <table> and <mtable> may require some
399 | forethought in how best to meet the usability needs of the intended
400 | audience and purpose of the table content. HTML structural elements
401 | are advantageous because screen readers provide more robust table
402 | navigation, whereas the user may only "enter" or
403 | "exit" an <mtable> in a MathML island. However, the
404 | <mtable> element is useful because it can be tweaked easily for
405 | visual alignment without creating new table cells, which can improve
406 | reading flow for the user. However, <mtable> should still be
407 | used for matrices and other table-like math layouts.
Instructional content for young learners may sometimes use the
415 | written form of math symbols. For example, the multiplication sign
416 | × might be written as times
or multiplied
417 | by
. Because times
and multiplied by
are ordinary
418 | words, speech engines will not have an issue reading them. However,
419 | in some cases, there may be a use-case for including these terms in
420 | MathML. For instance, the word times
in x = 2 times a
421 | could be marked up as an operator by means of
422 | <mo>times</mo>.
It is sometimes beneficial to a reader to have additional, auxiliary information for a given 431 | mathematical construct. This is particularly the case in educational materials where 432 | newly introduced syntax benefits from repeated reinforcement. Such information is often 433 | too verbose for more familiar readers, indeed even to the same person after their first reading. 434 | Hence, common AT behavior has been to only vocalize an 435 | accessible description 436 | on user request, omitting it by default.
437 |It is appropriate to provide such descriptions using the ARIA 1.3 attribute
438 | aria-description,
439 | which allows for a literal string value to annotate its host element.
440 | As an example, consider the minimal markup for the circumference formula,
441 | with each non-trivial component described.
442 |
446 | <mrow aria-description="circumference of a circle"> 447 | <mn>2</mn> 448 | <mi aria-description="mathematical constant">π</mi> 449 | <mi aria-description="radius variable">r</mi> 450 | </mrow> 451 |452 |
While aria-description has been used on its own for brevity,
455 | it is recommended to use it together with an intent annotation,
456 | as appropriate.
457 |
To ensure equal access, when aria-description
459 | or intent are used,
460 | useful descriptions should also be made visible on the page.
461 | A common affordance to achieve that is interactively displaying
462 | a tooltip containing the description.
463 |
https and referencing the GitHub Issues page
20 | as required for current W3C publications.
21 | mode and macros attributes from <math>. These have been deprecated
38 | since MathML 2. macros had no
39 | defined behaviour, and mode can be
40 | replaced by suitable use of display.
41 | The `mathml4-legacy` schema makes these valid if needed for legacy applications.other attribute.
44 | This have been deprecated
45 | since MathML 2.
46 | The `mathml4-legacy` schema makes this valid if needed for legacy applications.mo operator
64 | in .
65 | mathvariant, mathsize,
79 | mathcolor and
80 | mathbackground.
81 | These attributes are also no longer valid on mstyle.
82 | The `mathml4-legacy` schema makes these valid if needed for legacy applications.
83 | mglyph which is still retained to include images in MathML.
86 | mspace (it was equivalent to `newline`).
89 | mtr and mtd. The [[?MathML1]] required that an
93 | implementation infer the row markup if it was omitted.
94 | malignmark has been
96 | restricted and simplified, matching the features implemented in
97 | existing implementations.
98 | The groupalign attribute on table
99 | elements is no longer supported.mo attributes, fence
101 | and separator, have been removed
102 | (and are also no longer listed as properties in ).
103 | They are still valid in the schema,
104 | but invalid in the default schema.none is
106 | replaced by an empty mrow throughout,
107 | to match [[MathML-Core]].mlabeledtr and the associated attributes
109 | side and minlabelspacing
110 | are no longer specified. They are removed from the default schema but valid in
111 | the Legacy Schema.mpadded length attributes
114 | ( "+" | "-" )?
115 | unsigned-number
116 | ( ("%" pseudo-unit?)
117 | | pseudo-unit
118 | | unit
119 | | namedspace
120 | )? is no longer supported.
121 | Most of the functionality is still available using standard CSS
122 | length syntax. See Note: mpadded
123 | lengths.src (to match the normative
137 | schema) not href. The previous
138 | examples were also valid, as href
139 | is a common presentational attribute allowed on all elements.
140 | reln,
150 | declare and fn have been removed.
152 | The `mathml4-legacy` schema makes these valid if needed for legacy applications.intent attribute.Mixing Markup Languages for Mathematical Expressions
<semantics> element to mix
177 | Presentation and Content MathML is maintained in the second
178 | section, although reduced with some non normative text and
179 | examples moved to [[?MathML-Notes]].encoding and definitionURL on <semantics>. They are invalid in this
185 | specification. The `mathml4-legacy` schema may be used if these
186 | attributes need to be validated for a legacy application.compactpresentation is provided as well as the 233 | tabular presentation used previously.
This chapter contains discussion of 9 | characters for use within MathML, recommendations for their use, 10 | and warnings concerning the correct form of the 11 | corresponding code points given in the Universal Multiple-Octet Coded Character 12 | Set (UCS) ISO-10646 as codified in Unicode [[Unicode]].
13 |
19 | Additional Mathematical Alphanumeric Symbols
20 | were provided in Unicode 3.1.
21 | As discussed in , MathML offers an
22 | alternative mechanism to specify mathematical alphanumeric characters.
23 | Namely, one uses the mathvariant attribute on a token element
24 | such as mi to indicate that the character data in the token
25 | element selects a mathematical alphanumeric symbol.
26 |
30 | An important use of the mathematical alphanumeric symbols in Plane 1 31 | is for identifiers normally printed in special mathematical fonts, 32 | such as Fraktur, Greek, Boldface, or Script. As another example, 33 | the Mathematical Fraktur alphabet runs from U+1D504 ("A") to U+1D537 ("z"). 34 | Thus, an identifier for a variable that uses Fraktur characters could 35 | be marked up as 36 |
37 | 38 |40 | <mi>𝔄<!--BLACK-LETTER CAPITAL A--></mi> 41 |42 |
mathvariant attribute:
45 |
46 | 48 | <mi mathvariant="fraktur">A</mi> 49 |50 |
54 | A MathML processor must treat a mathematical alphanumeric character 55 | (when it appears) as identical to the corresponding combination of 56 | the unstyled character and mathvariant attribute value. 57 |
58 | 59 |60 | It is intended that renderers distinguish at least those combinations 61 | that have equivalent Unicode code points, and renderers are free to 62 | ignore those combinations that have no assigned Unicode code point 63 | or for which adequate font support is unavailable. 64 |
65 | 66 |72 | Some characters, although important for the quality of print or 73 | alternative rendering, do not have glyph marks that correspond 74 | directly to them. They are called here non-marking characters. 75 | Their roles are 76 | discussed in and .
77 | 78 |In MathML, control of page composition, such as line-breaking, is
79 | effected by the use of the proper attributes on the mo and mspace elements.
The characters below are not simple spacers. They are 82 | especially important new additions to the UCS because they provide 83 | textual clues which can increase the quality of print rendering, 84 | permit correct audio rendering, and allow the unique recovery of 85 | mathematical semantics from text which is visually ambiguous. 86 |
87 | 88 | 89 |Some characters which occur fairly often in mathematical texts, and 137 | have special significance there, are frequently confused with other 138 | similar characters in the UCS. In some cases, common keyboard 139 | characters have become entrenched as alternatives to the more appropriate 140 | mathematical characters. In others, characters have legitimate uses in 141 | both formulas and text, but conflicting rendering and font 142 | conventions. All these characters are called here anomalous 143 | characters.
144 | 145 |Typical Latin-1-based keyboards contain several characters that 149 | are visually similar to important mathematical characters. 150 | Consequently, these characters are frequently substituted, 151 | intentionally or unintentionally, for their more correct mathematical 152 | counterparts.
153 | 154 |The most common ordinary text character which enjoys a special
158 | mathematical use is U+002D [HYPHEN-MINUS]. As its Unicode name
159 | suggests, it is used as a hyphen in prose contexts, and as a minus
160 | or negative sign in formulas.
161 | For text use, there is a specific code point U+2010 [HYPHEN] which is
162 | intended for prose contexts, and which should render as a hyphen or
163 | short dash.
164 | For mathematical use, there is another code point U+2212 [MINUS SIGN]
165 | which is intended for mathematical formulas, and which should render
166 | as a longer minus or negative sign.
167 | MathML renderers should treat U+002D [HYPHEN-MINUS] as equivalent to
168 | U+2212 [MINUS SIGN] in formula contexts such as mo, and as
169 | equivalent to U+2010 [HYPHEN] in text contexts such as mtext.
170 |
On a typical European keyboard there is a key available which is 178 | viewed as an apostrophe or a single quotation mark (an upright or 179 | right quotation mark). Thus one key is doing double duty for prose 180 | input to enter U+0027 [APOSTROPHE] and U+2019 [RIGHT SINGLE QUOTATION 181 | MARK]. In mathematical contexts it is also commonly used for the 182 | prime, which should be U+2032 [PRIME]. Unicode recognizes the 183 | overloading of this symbol and remarks that it can also signify the 184 | units of minutes or feet. In the unstructured printed text of normal 185 | prose the characters are placed next to one another. The U+0027 186 | [APOSTROPHE] and U+2019 [RIGHT SINGLE QUOTATION MARK] are marked with 187 | glyphs that are small and raised with respect to the center line of 188 | the text. The fonts used provide small raised glyphs in the 189 | appropriate places indexed by the Unicode codes. The U+2032 [PRIME] 190 | of mathematics is similarly treated in fuller Unicode fonts. 191 |
192 | 193 |MathML renderers are encouraged to treat U+0027 194 | [APOSTROPHE] as U+2032 [PRIME] when appropriate in 195 | formula contexts.
196 | 197 |A final remark is that a ‘prime’ is often used in 198 | transliteration of the Cyrillic character U+044C [CYRILLIC SMALL 199 | LETTER SOFT SIGN]. This different use of primes is not part of 200 | considerations for mathematical formulas. 201 |
202 | 203 |While the minus and prime characters are the most common and 209 | important keyboard characters with more precise mathematical 210 | counterparts, there are a number of other keyboard character 211 | substitutions that are sometimes used. For example some may expect
212 | 213 |<mo>''</mo>215 |
to be treated as 217 | U+2033 [DOUBLE PRIME], and analogous substitutions could perhaps be made for U+2034 218 | [TRIPLE PRIME] and U+2057 [QUADRUPLE PRIME]. Similarly, sometimes U+007C [VERTICAL 219 | 220 | LINE] is used for U+2223 [DIVIDES]. MathML regards these as 221 | application-specific authoring conventions, and recommends that 222 | authoring tools generate markup using the more precise mathematical 223 | characters for better interoperability. 224 |
225 | 226 |There are a number of characters in the UCS that traditionally have 234 | been taken to have a natural ‘script’ aspect. The 235 | visual presentation of these characters is similar to a script, that 236 | is, raised from the baseline, and smaller than the base font size. The 237 | degree symbol and prime characters are examples. For use in text, such 238 | characters occur in sequence with the identifier they follow, and are 239 | typically rendered using the same font. These characters are called 240 | pseudo-scripts here.
241 | 242 |In almost all mathematical contexts, pseudo-script characters should
243 | be associated
244 | with a base expression using explicit script markup in MathML. For
245 | example, the preferred encoding of x prime
is
<msup><mi>x</mi><mo>′<!--PRIME--></mo></msup>249 |
and not
252 | 253 |<mi>x'</mi>255 |
or any other variants not using an explicit script construct. Note, however, that
258 | within
259 | text contexts such as mtext, pseudo-scripts may be used in sequence with other character data.
There are two reasons why explicit markup is preferable in 262 | mathematical contexts. First, a problem arises with typesetting, when 263 | pseudo-scripts are used with subscripted identifiers. Traditionally, 264 | subscripting of x' would be rendered stacked under the prime. This is 265 | easily accomplished with script markup, for example:
266 | 267 |<mrow><msubsup><mi>x</mi><mn>0</mn><mo>′<!--PRIME--></mo></msubsup></mrow>269 |
By contrast,
272 | 273 |<mrow><msub><mi>x'</mi><mn>0</mn></msub></mrow>275 |
will render with staggered scripts.
277 | 278 |Note this means that a renderer of MathML will have to treat 279 | pseudo-scripts differently from most other character codes it finds in 280 | a superscript position; in most fonts, the glyphs for pseudo-scripts 281 | are already shrunk and raised from the baseline. 282 |
283 | 284 |The second reason that explicit script markup is preferrable to 285 | juxtaposition of characters is that it generally better reflects the 286 | intended mathematical structure. For example,
287 | 288 |290 | <msup> 291 | <mrow><mo>(</mo><mrow><mi>f</mi><mo>+</mo><mi>g</mi></mrow><mo>)</mo></mrow> 292 | <mo>′<!--PRIME--></mo> 293 | </msup>294 |
accurately reflects that the prime here is operating on an entire 296 | expression, and does not suggest that the prime is acting on the final right parenthesis. 297 |
298 | 299 |However, the data model for all MathML token elements is Unicode text, 300 | so one cannot rule out the possibility of valid MathML markup 301 | containing constructions such as
302 | 303 |<mrow><mi>x'</mi></mrow>305 |
and
307 | 308 |<mrow><mi>x</mi><mo>'</mo></mrow>310 |
While the first form may, in some rare situations, legitimately be used 313 | to distinguish a multi-character identifer named x' from the 314 | derivative of a function x, such forms should generally be avoided. 315 | Authoring and validation tools are encouraged to generate the 316 | recommended script markup:
317 | 318 |<mrow><msup><mi>x</mi><mo>′<!--PRIME--></mo></msup></mrow>320 |
The U+2032 [PRIME] character is perhaps the most common 324 | pseudo-script, but there are many others, as listed below:
325 | 326 || Pseudo-script Characters | 332 ||
| U+0022 | 339 |QUOTATION MARK | 340 |
| U+0027 | 344 |APOSTROPHE | 345 |
| U+002A | 349 |ASTERISK | 350 |
| U+0060 | 354 |GRAVE ACCENT | 355 |
| U+00AA | 359 |FEMININE ORDINAL INDICATOR | 360 |
| U+00B0 | 364 |DEGREE SIGN | 365 |
| U+00B2 | 369 |SUPERSCRIPT TWO | 370 |
| U+00B3 | 374 |SUPERSCRIPT THREE | 375 |
| U+00B4 | 379 |ACUTE ACCENT | 380 |
| U+00B9 | 384 |SUPERSCRIPT ONE | 385 |
| U+00BA | 389 |MASCULINE ORDINAL INDICATOR | 390 |
| U+2018 | 394 |LEFT SINGLE QUOTATION MARK | 395 |
| U+2019 | 399 |RIGHT SINGLE QUOTATION MARK | 400 |
| U+201A | 404 |SINGLE LOW-9 QUOTATION MARK | 405 |
| U+201B | 409 |SINGLE HIGH-REVERSED-9 QUOTATION MARK | 410 |
| U+201C | 414 |LEFT DOUBLE QUOTATION MARK | 415 |
| U+201D | 419 |RIGHT DOUBLE QUOTATION MARK | 420 |
| U+201E | 424 |DOUBLE LOW-9 QUOTATION MARK | 425 |
| U+201F | 429 |DOUBLE HIGH-REVERSED-9 QUOTATION MARK | 430 |
| U+2032 | 434 |PRIME | 435 |
| U+2033 | 439 |DOUBLE PRIME | 440 |
| U+2034 | 444 |TRIPLE PRIME | 445 |
| U+2035 | 449 |REVERSED PRIME | 450 |
| U+2036 | 454 |REVERSED DOUBLE PRIME | 455 |
| U+2037 | 459 |REVERSED TRIPLE PRIME | 460 |
| U+2057 | 464 |QUADRUPLE PRIME | 465 |
471 | In addition, the characters in the Unicode Superscript and Subscript block 472 | (beginning at U+2070) should be treated as pseudo-scripts when they 473 | appear in mathematical formulas. 474 |
475 | 476 |Note that several of these characters are common on keyboards, 477 | including U+002A [ASTERISK], U+00B0 [DEGREE SIGN], U+2033 [DOUBLE PRIME], 478 | and U+2035 [REVERSED PRIME] also known as a back prime. 479 |
480 | 481 |In the UCS there are many combining characters that are intended 487 | to be used for the many accents of numerous different natural 488 | languages. Some of them may seem to provide markup needed for 489 | mathematical accents. They should not be used in mathematical markup. 490 | Superscript, subscript, underscript, and overscript constructions as 491 | just discussed above 492 | should be used for this purpose. Of course, combining 493 | characters may be used in multi-character identifiers as they are 494 | needed, or in text contexts. 495 |
496 | 497 |498 | There is one more case where combining characters turn up naturally 499 | in mathematical markup. Some relations have associated negations, 500 | such as U+226F [NOT GREATER-THAN] for the negation of 501 | U+003E [GREATER-THAN SIGN]. The glyph for U+226F [NOT GREATER-THAN] 502 | is usually just that for U+003E [GREATER-THAN SIGN] with a slash through 503 | it. Thus it could also be expressed by U+003E-0338 making use of 504 | the combining slash U+0338 [COMBINING LONG SOLIDUS OVERLAY]. 505 | That is true of 25 other characters in common enough mathematical use 506 | to merit their own Unicode code points. In the other direction there are 507 | 31 character entity names listed in [[Entities]] which 508 | are to be expressed using U+0338 [COMBINING LONG SOLIDUS OVERLAY]. 509 |
510 | 511 |In a similar way there are mathematical characters which have negations 512 | given by a vertical bar overlay U+20D2 [COMBINING LONG VERTICAL LINE OVERLAY]. 513 | Some are available in pre-composed forms, and some named character entities 514 | are given explicitly as combinations. In addition there are examples 515 | using U+0333 [COMBINING DOUBLE LOW LINE] and 516 | U+20E5 [COMBINING REVERSE SOLIDUS OVERLAY], and variants specified 517 | by use of the U+FE00 [VARIATION SELECTOR-1]. For fuller listing of 518 | these cases see the listings in [[Entities]]. 519 |
520 | 521 |The general rule is that a base character followed by a string of 522 | combining characters should be treated just as though it were the 523 | pre-composed character that results from the combination, 524 | if such a character exists. 525 |
526 | 527 |Information nowadays is commonly 5 | generated, processed and rendered by 6 | software tools. The exponential growth of the Web is fueling the 7 | development of advanced systems for automatically searching, 8 | categorizing, and interconnecting information. 9 | In addition, there are increasing numbers of 10 | Web services, some of which offer technically based materials 11 | and activities. Thus, although MathML 12 | can be written by hand and read by humans, 13 | whether machine-aided or just with much concentration, 14 | the future of MathML is 15 | largely tied to the ability to process it with software tools.
16 | 17 |There are many different kinds of MathML 18 | processors: editors for authoring MathML expressions, translators for 19 | converting to and from other encodings, validators for checking MathML 20 | expressions, computation engines that evaluate, manipulate, or compare 21 | MathML expressions, and rendering engines that produce visual, aural, 22 | or tactile representations of mathematical notation. What it 23 | means to support MathML varies widely between applications. For 24 | example, the issues that arise with a validating 25 | parser are very different from those for an equation 26 | editor.
27 | 28 |This section gives guidelines that describe different types 29 | of MathML support and make clear the extent of MathML support in 30 | a given application. Developers, users, and reviewers are encouraged 31 | to use these guidelines in characterizing products. The intention 32 | behind these guidelines is to facilitate reuse by 33 | and interoperability 34 | of MathML applications by accurately setting out their 35 | capabilities in quantifiable terms.
36 | 37 |The W3C Math Working Group maintains MathML Compliance 38 | Guidelines. Consult this document for future updates on 39 | conformance activities and resources. 40 |
41 | 42 |A valid MathML expression is an XML construct determined by the MathML 46 | RelaxNG Schema together with the additional requirements given in this specification.
47 | 48 |We shall use the phrase “a MathML processor” 49 | to mean any application that 50 | can accept or produce a valid MathML 51 | expression. A MathML processor that both accepts and produces valid 52 | MathML expressions may be able to “round-trip” MathML. 53 | Perhaps the simplest example of an 54 | application that might round-trip a MathML 55 | expression would be an editor that writes it to a new file without 56 | modifications.
57 | 58 |Three forms of MathML conformance are specified: 59 |
60 |A MathML-input-conformant processor must 64 | accept all valid MathML expressions; it should appropriately translate all 65 | MathML expressions into application-specific form allowing native 66 | application operations to be performed.
67 |A MathML-output-conformant processor must 71 | generate valid MathML, appropriately representing all 72 | application-specific data.
73 |A MathML-round-trip-conformant processor must 77 | preserve MathML equivalence. Two MathML expressions are 78 | “equivalent” if and only if both expressions have the 79 | same interpretation (as stated by the MathML 80 | Schema and specification) 81 | under any relevant circumstances, by any MathML processor. Equivalence on an 82 | element-by-element basis is discussed elsewhere in this document.
83 | 84 |Beyond the above definitions, the MathML specification makes no 88 | demands of individual processors. In order to guide developers, the 89 | MathML specification includes advisory material; for example, there 90 | are many recommended rendering rules throughout . 91 | However, in general, developers are given wide latitude to 92 | interpret what kind of MathML implementation is meaningful for 93 | their own particular application.
94 | 95 |To clarify the difference between conformance and 96 | interpretation of what is meaningful, consider some examples: 97 |
98 |In order 101 | to be MathML-input-conformant, a 102 | validating parser needs only to accept expressions, and return 103 | “true” for expressions that are valid MathML. In 104 | particular, it need not render or interpret the MathML expressions at 105 | all.
106 |A MathML computer-algebra interface based on content markup 110 | might choose to ignore all presentation markup. Provided the interface 111 | accepts all valid MathML expressions including those containing 112 | presentation markup, it would be technically correct to characterize 113 | the application as MathML-input-conformant.
114 |An equation editor might have an internal data representation 118 | that makes it easy to export some equations as MathML but not 119 | others. If the editor exports the simple equations as valid MathML, 120 | and merely displays an error message to the effect that conversion 121 | failed for the others, it is still technically 122 | MathML-output-conformant.
As the previous examples show, to be useful, the concept of MathML 128 | conformance frequently involves a judgment about what parts of the 129 | language are meaningfully implemented, as opposed to parts that are 130 | merely processed in a technically correct way with respect to the 131 | definitions of conformance. This requires some mechanism for giving a 132 | quantitative statement about which parts of MathML are meaningfully 133 | implemented by a given application. To this end, the W3C Math Working 134 | Group has provided a test 135 | suite.
136 | 137 |The test suite consists of a large number of MathML expressions 138 | categorized by markup category and dominant MathML element being 139 | tested. The existence of this test suite makes it possible, for example, 140 | to characterize quantitatively the hypothetical computer algebra interface 141 | mentioned above by saying that it is a MathML-input-conformant processor 142 | which meaningfully implements MathML content markup, including all of 143 | the expressions in the content markup section of the test suite.
144 | 145 |Developers who choose not to implement parts of the MathML 146 | specification in a meaningful way are encouraged to itemize the parts 147 | they leave out by referring to specific categories in the test suite.
148 | 149 |For MathML-output-conformant processors, information about currently 150 | available tools to validate MathML is 151 | maintained at the W3C MathML Validator. 152 | Developers of MathML-output-conformant processors are encouraged to verify 153 | their output using this 154 | validator.
155 | 156 |Customers of MathML applications who wish to verify claims as to which 157 | parts of the MathML specification are implemented by an application are 158 | encouraged to use the test suites as a part of their decision 159 | processes.
160 |MathML 4.0 contains a number of features of earlier MathML 166 | which are now deprecated. The following points define what it means for a 167 | feature to be deprecated, and clarify the relation between 168 | deprecated features and current MathML conformance.
169 | 170 |In order to be MathML-output-conformant, authoring tools may not 174 | generate MathML markup containing deprecated features.
175 |In order to be MathML-input-conformant, rendering and reading 179 | tools must support deprecated features if they are to be 180 | in conformance with MathML 1.x or MathML 2.x. They do not have to support deprecated 181 | features to be considered in conformance with MathML 4.0. However, all tools 182 | are encouraged to support the old forms as much as 183 | possible.
184 |In order to be MathML-round-trip-conformant, a processor need 188 | only preserve MathML equivalence on expressions containing no 189 | deprecated features.
190 |MathML 4.0 defines three basic extension mechanisms: the mglyph
200 | element provides a way of displaying glyphs for non-Unicode
201 | characters, and glyph variants for existing Unicode characters; the
202 | maction element uses attributes from other namespaces to obtain
203 | implementation-specific parameters; and content markup makes use of
204 | the definitionURL attribute, as well as
205 | Content Dictionaries and the cd attribute, to point to external
206 | definitions of mathematical semantics.
These extension mechanisms are important because they provide a way
209 | of encoding concepts that are beyond the scope of MathML 4.0 as presently
210 | explicitly specified, which
211 | allows MathML to be used for exploring new ideas not yet susceptible
212 | to standardization. However, as new ideas take hold, they may become
213 | part of future standards. For example, an emerging character that
214 | must be represented by an mglyph element today may be
215 | assigned a Unicode code point in the future. At that time,
216 | representing the character directly by its Unicode code point would be
217 | preferable. This transition into Unicode has
218 | already taken place for hundreds of characters used for mathematics.
Because the possibility of future obsolescence is inherent in the
221 | use of extension mechanisms to facilitate the discussion of new ideas,
222 | MathML can reasonably make
223 | no conformance requirements concerning the use of
224 | extension mechanisms, even when alternative standard markup is
225 | available. For example, using an mglyph element to represent
226 | an 'x' is permitted. However, authors and implementers are
227 | strongly encouraged to use standard markup whenever possible.
228 | Similarly, maintainers of documents employing MathML 4.0 extension
229 | mechanisms are encouraged to monitor relevant standards activity
230 | (e.g., Unicode, OpenMath, etc.) and to update documents as more
231 | standardized markup becomes available.
If a MathML-input-conformant application receives
239 | input containing one or more elements with an illegal number or type
240 | of attributes or child schemata, it should nonetheless attempt to
241 | render all the input in an intelligible way, i.e., to render normally
242 | those parts of the input that were valid, and to render error messages
243 | (rendered as if enclosed in an merror element) in place of
244 | invalid expressions.
MathML-output-conformant applications such as
247 | editors and translators may choose to generate merror
248 | expressions to signal errors in their input. This is usually
249 | preferable to generating valid, but possibly erroneous, MathML.
The MathML attributes described in the MathML specification are 256 | intended to allow for good presentation and content markup. However 257 | it is never possible to cover all users' needs for markup. Ideally, the MathML 258 | attributes should be an open-ended list so that users can add specific 259 | attributes for specific renderers. However, this cannot be done within 260 | the confines of a single XML DTD or in a Schema. 261 | Although it can be done using extensions of the standard DTD, say, 262 | some authors will wish to use non-standard 263 | attributes to take advantage of renderer-specific capabilities while 264 | remaining strictly in conformance with the standard 265 | DTD.
266 | 267 |To allow this, the MathML 1.0 specification [[[?MathML1]]]
268 | allowed the attribute other on all elements, for use as a hook to pass
269 | on renderer-specific information. In particular, it was intended as a hook for
270 | passing information to audio renderers, computer algebra systems, and for pattern
271 | matching in future macro/extension mechanisms. The motivation for this approach to
272 | the problem was historical, looking to PostScript, for example, where comments are
273 | widely used to pass information that is not part of PostScript.
In the next period of evolution of MathML the
276 | development of a general XML namespace mechanism
277 | seemed to make the use of the other
278 | attribute obsolete. In MathML 2.0, the other attribute is
279 | deprecated in favor of the use of
280 | namespace prefixes to identify non-MathML attributes. The
281 | other attribute has been removed in MathML 4.0. although it
282 | is still valid (with no defined behavior) in the mathml4-legacy schema.
For example, in MathML 1.0, it was recommended that if additional information
285 | was used in a renderer-specific implementation for the maction element
286 | (),
287 | that information should be passed in using the other attribute:
291 | <maction actiontype="highlight" other="color='#ff0000'"> expression </maction> 292 |293 |
From MathML 4.0 onwards, a data-*
296 | attribute could be used:
300 | <body> 301 | ... 302 | <maction actiontype="highlight" data-color="#ff0000"> expression </maction> 303 | ... 304 | </body> 305 |306 |
Note that the intent of allowing non-standard attributes is 309 | not to encourage software developers to use this as a 310 | loophole for circumventing the core conventions for MathML markup. 311 | Authors and applications should use non-standard attributes 312 | judiciously.
313 | 314 |Web platform implementations of MathML should implement [[MathML-Core]], 320 | and so the Privacy Considerations specified there apply.
321 |Web platform implementations of MathML should implement [[MathML-Core]], 327 | and so the Security Considerations specified there apply.
328 |In some situations, MathML expressions can be parsed as XML. The security considerations of XML parsing apply then as explained in [[?RFC7303]].
329 |The current Math Working Group is chartered from April 2021, 8 | until May 2023 and is co-chaired by Neil Soiffer and Brian Kardell 9 | (Igalia).
10 | 11 |Between 2019 and 2021 the W3C MathML-Refresh Community Group was chaired by Neil Soiffer and 12 | developed the initial proposal for MathML Core and requirements for MathML 4.
13 | 14 |15 | The W3C Math Working Group responsible for MathML 3 (2012–2013) was co-chaired by 16 | David Carlisle of NAG and Patrick Ion of the AMS; Patrick Ion and Robert 17 | Miner of Design Science were co-chairs 2006-2011. 18 | Contact the co-chairs about membership in 19 | the Working Group. For the current membership see the 20 | W3C Math home page. 21 |
22 | 23 |Robert Miner, whose leadership and contributions were essential 24 | to the development of the Math Working Group and MathML from their 25 | beginnings, died tragically young in December 2011.
26 | 27 |Participants in the Working Group responsible for MathML 3.0 have been: 28 |
29 | 30 |31 | Ron Ausbrooks, 32 | Laurent Bernardin, 33 | Pierre-Yves Bertholet, 34 | Bert Bos, 35 | Mike Brenner, 36 | Olga Caprotti, 37 | David Carlisle, 38 | Giorgi Chavchanidze, 39 | Ananth Coorg, 40 | Stéphane Dalmas, 41 | Stan Devitt, 42 | Sam Dooley, 43 | Margaret Hinchcliffe, 44 | Patrick Ion, 45 | Michael Kohlhase, 46 | Azzeddine Lazrek, 47 | Dennis Leas, 48 | Paul Libbrecht, 49 | Manolis Mavrikis, 50 | Bruce Miller, 51 | Robert Miner, 52 | Chris Rowley, 53 | Murray Sargent III, 54 | Kyle Siegrist, 55 | Andrew Smith, 56 | Neil Soiffer, 57 | Stephen Watt, 58 | Mohamed Zergaoui 59 |60 | 61 |
62 | All the above persons have been members of the Math Working Group, 63 | but some not for the whole life of the Working Group. The 22 authors listed for MathML3 64 | at the start of that specification are those who contributed 65 | reworkings and reformulations used in the actual text of the specification. 66 | Thus the list includes the principal authors of MathML2 much of whose text was repurposed 67 | here. They were, of course, supported and encouraged by the activity and discussions 68 | of the whole Math Working Group, and by helpful commentary from outside it, both within 69 | the W3C and further afield. 70 |
71 | 72 |73 | For 2003 to 2006 W3C Math Activity comprised a Math Interest Group, 74 | chaired by David Carlisle of NAG and Robert Miner of Design Science. 75 |
76 | 77 |78 | The W3C Math Working Group (2001–2003) 79 | was co-chaired by Patrick Ion of the 80 | AMS, and Angel Diaz of IBM from June 2001 to May 2002; afterwards 81 | Patrick Ion continued as chair until the end of the WG's extended charter. 82 |
83 | 84 |Participants in the Working Group responsible for MathML 2.0, second 85 | edition were: 86 |
87 |88 | Ron Ausbrooks, 89 | Laurent Bernardin, 90 | Stephen Buswell, 91 | David Carlisle, 92 | Stéphane Dalmas, 93 | Stan Devitt, 94 | Max Froumentin, 95 | Patrick Ion, 96 | Michael Kohlhase, 97 | Robert Miner, 98 | Luca Padovani, 99 | Ivor Philips, 100 | Murray Sargent III, 101 | Neil Soiffer, 102 | Paul Topping, 103 | Stephen Watt 104 |105 | 106 |
Earlier active participants of the W3C Math Working Group (2001 – 2003) have 107 | included: 108 |
109 |110 | Angel Diaz, 111 | Sam Dooley, 112 | Barry MacKichan 113 |114 | 115 |
The W3C Math Working Group was co-chaired by Patrick Ion 116 | of the AMS, and Angel Diaz of IBM from July 1998 to December 2000.
117 | 118 |Participants in the Working Group responsible for MathML 2.0 were: 119 |
120 |121 | Ron Ausbrooks, 122 | Laurent Bernardin, 123 | Stephen Buswell, 124 | David Carlisle, 125 | Stéphane Dalmas, 126 | Stan Devitt, 127 | Angel Diaz, 128 | Ben Hinkle, 129 | Stephen Hunt, 130 | Douglas Lovell, 131 | Patrick Ion, 132 | Robert Miner, 133 | Ivor Philips, 134 | Nico Poppelier, 135 | Dave Raggett, 136 | T.V. Raman, 137 | Murray Sargent III, 138 | Neil Soiffer, 139 | Irene Schena, 140 | Paul Topping, 141 | Stephen Watt 142 |143 | 144 |
Earlier active participants of this second W3C Math Working Group have 145 | included: 146 |
147 |148 | Sam Dooley, 149 | Robert Sutor, 150 | Barry MacKichan 151 |152 | 153 |
At the time of release of MathML 1.0 [[MathML1]] the 154 | Math Working Group was co-chaired by Patrick Ion and Robert Miner, then of the 155 | Geometry Center. Since that time several changes in membership have taken 156 | place. In the course of the update to MathML 1.01, in addition to people listed in 157 | the original membership below, corrections were offered by David Carlisle, Don 158 | Gignac, Kostya Serebriany, Ben Hinkle, Sebastian Rahtz, Sam Dooley and others.
159 | 160 |Participants in the Math Working Group responsible for the finished 161 | MathML 1.0 specification were: 162 |
163 |164 | Stephen Buswell, 165 | Stéphane Dalmas, 166 | Stan Devitt, 167 | Angel Diaz, 168 | Brenda Hunt, 169 | Stephen Hunt, 170 | Patrick Ion, 171 | Robert Miner, 172 | Nico Poppelier, 173 | Dave Raggett, 174 | T.V. Raman, 175 | Bruce Smith, 176 | Neil Soiffer, 177 | Robert Sutor, 178 | Paul Topping, 179 | Stephen Watt, 180 | Ralph Youngen 181 |182 |
183 | 184 | Others who had been members of the W3C Math WG for periods at 185 | earlier stages were: 186 | 187 |
188 |189 | Stephen Glim, 190 | Arnaud Le Hors, 191 | Ron Whitney, 192 | Lauren Wood, 193 | Ka-Ping Yee 194 |195 |
The Working Group benefited from the help of many other 201 | people in developing the specification for MathML 1.0. We 202 | would like to particularly name Barbara Beeton, Chris Hamlin, 203 | John Jenkins, Ira Polans, Arthur Smith, Robby Villegas and Joe 204 | Yurvati for help and information in assembling the character 205 | tables in , as well as Peter Flynn, 206 | Russell S.S. O'Connor, Andreas Strotmann, and other 207 | contributors to the www-math 208 | mailing list for their careful 209 | proofreading and constructive criticisms.
210 | 211 |212 | As the Math Working Group went on to MathML 2.0, it again was 213 | helped by many from the W3C family of Working Groups with whom 214 | we necessarily had a great deal of interaction. Outside the 215 | W3C, a particularly active relevant front was the interface 216 | with the Unicode Technical Committee (UTC) and the NTSC WG2 217 | dealing with ISO 10646. There the STIX project put together a 218 | proposal for the addition of characters for mathematical 219 | notation to Unicode, and this work was again spearheaded 220 | by 221 | Barbara Beeton of the AMS. The whole problem ended split into 222 | three proposals, two of which were advanced by Murray Sargent 223 | of Microsoft, a Math WG member and member of the UTC. But the 224 | mathematical community should be grateful for essential help 225 | and guidance over a couple of years of refinement of the 226 | proposals to help mathematics provided by Kenneth Whistler of 227 | Sybase, and a UTC and WG2 member, and by Asmus Freytag, also 228 | involved in the UTC and WG2 deliberations, and always a stalwart 229 | and knowledgeable supporter of the needs of scientific notation. 230 |
231 | 232 |The basic ‘syntax’ of MathML is 14 | defined using XML syntax, 15 | but other syntaxes that can encode labeled trees are possible. Notably the HTML parser 16 | may also be used with MathML. 17 | Upon this, we layer a ‘grammar’, being the rules for allowed elements, 18 | the order in which they can appear, 19 | and how they may be contained within each other, 20 | as well as additional syntactic rules for the values of attributes. 21 | These rules are defined by this specification, 22 | and formalized by a RelaxNG schema [[RELAXNG-SCHEMA]] in . 23 | Derived schema in other formats, DTD (Document Type Definition) 24 | and XML Schema [[XMLSchemas]] are also provided. 25 |
26 | 27 |MathML's character set consists of any 28 | Unicode characters [[Unicode]] allowed by the syntax being used. (See for example [[XML]] or [[HTML]].) 29 | The use of Unicode characters for mathematics is 30 | discussed in .
31 | 32 |The following sections discuss the general aspects 33 | of the MathML grammar as well as describe the syntaxes used 34 | for attribute values. 35 |
36 | 37 |An XML namespace [[Namespaces]] is a collection of names identified by a URI. 43 | The URI for the MathML namespace is:
44 | 45 | 46 |47 | http://www.w3.org/1998/Math/MathML 48 |49 | 50 | 51 |
To declare a namespace when using the XML serialisation of MathML,
52 | one uses an xmlns
53 | attribute, or an attribute with an xmlns prefix.
57 | <math xmlns="http://www.w3.org/1998/Math/MathML"> 58 | <mrow>...</mrow> 59 | </math> 60 |61 |
When the xmlns attribute is used as a
64 | prefix, it declares a prefix which can then be used to explicitly associate other
65 | elements
66 | and attributes with a particular namespace.
67 | When embedding MathML within HTML using XML syntax, one might use:
68 |
72 | <body xmlns:m="http://www.w3.org/1998/Math/MathML"> 73 | ... 74 | <m:math><m:mrow>...</m:mrow></m:math> 75 | ... 76 | </body> 77 |78 |
HTML does not support namespace extensibility in the same way. The HTML parser
81 | has in-built knowledge of the HTML, SVG, and MathML namespaces. xmlns attributes are
82 | just treated as normal attributes. Thus, when using the HTML serialisation of MathML,
83 | prefixed element names must not be used. xmlns=http://www.w3.org/1998/Math/MathML
84 | may be used on the math element; it will be ignored by the HTML parser.
85 |
86 | If a MathML expression is likely to be in contexts where it may be parsed by an XML
87 | parser or an HTML parser, it SHOULD
88 | use the following form to ensure maximum compatibility:
92 | <math xmlns="http://www.w3.org/1998/Math/MathML"> 93 | ... 94 | </math> 95 |96 |
There are presentation elements that conceptually accept only
104 | a single argument, but which for convenience have been written to accept any number
105 | of children;
106 | then we infer an mrow containing those children which acts as
107 | the argument to the element in question; see .
108 |
In the detailed discussions of element syntax given with each 111 | element throughout the MathML specification, the number of arguments required and 112 | their order, as well as other constraints on the content, are specified. 113 | This information is also tabulated 114 | for the presentation elements in .
115 | 116 |Web Platform implementations of [[MathML-Core]] should follow the 121 | detailed layout rules specified in that document.
122 | 123 |This document only recommends (i.e., does not require) specific 124 | ways of rendering Presentation MathML; this is in order to allow 125 | for medium-dependent rendering and for implementations not using 126 | the CSS based Web Platform.
127 | 128 |MathML elements take attributes with values that further specialize
134 | the meaning or effect of the element. Attribute names are shown in a
135 | monospaced font throughout this document. The meanings of attributes and their
136 | allowed values are described within the specification of each element.
137 | The syntax notation explained in this section is used in specifying allowed values.
138 |
To describe the MathML-specific syntax of 144 | attribute values, the following conventions and notations are 145 | used for most attributes in the present document.
146 | 147 | 148 || Notation | 154 |What it matches | 155 |
|---|---|
| boolean | 162 |As defined in [[MathML-Core]], a string that is an
163 | ASCII case-insensitive match to true or
164 | false. |
165 |
| unsigned-integer | 168 |As defined in [[MathML-Core]], an integer, whose first character is neither
169 | U+002D HYPHEN-MINUS character (-) nor
170 | U+002B PLUS SIGN (+). |
171 |
| positive-integer | 175 |An [=unsigned-integer=] not consisting solely of "0"s (U+0030), representing a positive integer | 176 |
| integer | 180 |an optional "-" (U+002D), followed by an [=unsigned-integer=], 181 | and representing an integer 182 | | 183 |
| number | 187 |188 | an optional prefix of "-" (U+002D), followed by an [=unsigned-number=], 189 | representing a terminating decimal number (a type of rational number) | 190 |
| unsigned-number | 194 |
195 | value as defined in
196 | [[CSS-VALUES-3]] number, whose first character is neither
197 | U+002D HYPHEN-MINUS character (-) nor
198 | U+002B PLUS SIGN (+),
199 | representing a non-negative terminating decimal number
200 | (a type of rational number) |
201 |
| character | 205 |a single non-whitespace character | 206 |
| string | 210 |an arbitrary, nonempty and finite, string of characters | 211 |
| length | 215 |a length, as explained below, | 216 |
| namedspace | 220 |a named [=length=], [=namedspace=], as explained in | 221 |
| color | 225 |a color, using the syntax specified by [[CSS-Color-3]] | 226 |
| id | 230 |an identifier, unique within the document; 231 | must satisfy the NAME syntax of the XML recommendation [[XML]] | 232 |
| idref | 236 |an identifier referring to another element within the document; 237 | must satisfy the NAME syntax of the XML recommendation [[XML]] | 238 |
| URI | 242 |a Uniform Resource Identifier [[RFC3986]]. Note that the attribute value 243 | is typed in the schema as anyURI which allows any sequence of XML characters. 244 | Systems needing to use this string as a URI must encode the bytes of the UTF-8 encoding 245 | of any characters not allowed in URI using %HH encoding where HH are the byte value 246 | in hexadecimal. 247 | This ensures that such an attribute value may be interpreted as an IRI, 248 | or more generally a LEIRI; see [[IRI]]. | 249 |
| italicized word | 253 |values as explained in the text for each attribute; see | 254 |
| "literal" | 258 |quoted symbol, literally present in the attribute value (e.g. "+" or '+') | 259 |
The ‘types’ described above, except for string, 265 | may be combined into composite patterns using the following operators. The whole 266 | attribute value must be delimited by single (') or double (") quotation marks in the 267 | marked up 268 | document. Note that double quotation marks are often used in this specification to 269 | mark up 270 | literal expressions; an example is the "-" in line 5 of the table above. 271 |
272 | 273 |274 | In the table 275 | below a form f means an instance of a type described in the table above. 276 | The combining operators are shown in order of precedence from highest 277 | to lowest:
278 | 279 || Notation | 285 |What it matches | 286 |
|---|---|
| 293 | | same | 294 |
| 298 | | an optional instance of | 299 |
| 303 | | zero or more instances of , with 304 | separating whitespace characters | 305 |
| 309 | | one or more instances of , with 310 | separating whitespace characters | 311 |
| 315 | | one instance of each form , in sequence, 316 | with no separating whitespace | 317 |
| 321 | | one instance of each form , in sequence, with 322 | separating whitespace characters (but no commas) | 323 |
| 327 | | any one of the specified forms | 328 |
The notation we have chosen here is in the style of the syntactical notation of the 333 | RelaxNG 334 | used for MathML's basic schema, . 335 |
336 | 337 |Since some applications are inconsistent about normalization 338 | of whitespace, for maximum interoperability it is advisable to use only 339 | a single whitespace character for separating parts of a value. 340 | Moreover, leading and trailing whitespace in attribute values should be avoided.
341 | 342 |For most numerical attributes, only those in a subset of the 343 | expressible values are sensible; values outside this subset are not 344 | errors, unless otherwise specified, but rather are rounded up or down 345 | (at the discretion of the renderer) to the closest value within the 346 | allowed subset. The set of allowed values may depend on the renderer, 347 | and is not specified by MathML.
348 | 349 |If a numerical value within an attribute value syntax description
350 | is declared to allow a minus sign ('-'), e.g., number or
351 | integer, it is not a syntax error when one is provided in
352 | cases where a negative value is not sensible. Instead, the value
353 | should be handled by the processing application as described in the
354 | preceding paragraph. An explicit plus sign ('+') is not allowed as
355 | part of a numerical value except when it is specifically listed in the
356 | syntax (as a quoted '+' or "+"), and its presence can change the
357 | meaning of the attribute value (as documented with each attribute
358 | which permits it).
Most presentation elements have attributes that accept values
366 | representing lengths to be used for size, spacing or similar properties.
367 | [[MathML-Core]] accepts lengths only in the
368 | <length-percentage>
369 | syntax defined in [[CSS-VALUES-3]].
370 | MathML Full extends length syntax by accepting also a namedspace
371 | being one of:
| Positive space | Negative space | Value |
|---|---|---|
veryverythinmathspace |
379 | negativeveryverythinmathspace |
380 | ±1/18 em | 381 |
verythinmathspace |
384 | negativeverythinmathspace |
385 | ±2/18 em | 386 |
thinmathspace |
389 | negativethinmathspace |
390 | ±3/18 em | 391 |
mediummathspace |
394 | negativemediummathspace |
395 | ±4/18 em | 396 |
thickmathspace |
399 | negativethickmathspace |
400 | ±5/18 em | 401 |
verythickmathspace |
404 | negativeverythickmathspace |
405 | ±6/18 em | 406 |
veryverythickmathspace |
409 | negativeveryverythickmathspace |
410 | ±7/18 em | 411 |
In MathML 3, the attributes on mpadded
417 | allowed three pseudo-units, height,
418 | depth, and width (taking the place of one of the usual CSS units)
419 | denoting the original dimensions of the content.
420 | It also allowed a deprecated usage with lengths specified as
421 | a number without a unit which was interpreted as a multiple of the
422 | reference value. These forms are considered invalid in MathML 4.
423 |
Two additional aspects of relative units must be clarified, however.
430 | First, some elements such as or mfrac
431 | implicitly switch to smaller font sizes for some of their arguments.
432 | Similarly, mstyle can be used to explicitly change
433 | the current font size. In such cases, the effective values of
434 | an em or ex inside those contexts will be
435 | different than outside. The second point is that the effective value
436 | of an em or ex used for an attribute value
437 | can be affected by changes to the current font size.
438 | Thus, attributes that affect the current font size,
439 | such as mathsize
440 | and scriptlevel, must be processed before
441 | evaluating other length valued attributes.
442 |
Default values for MathML attributes are, in general, given along with the 452 | detailed descriptions of specific elements in the text. Default values 453 | shown in plain text in the tables of attributes for an element are literal, 454 | but when italicized are descriptions of how default values can be computed.
455 | 456 |Default values described as inherited are taken from the 457 | rendering environment, as described in , 458 | or in some cases (which are described individually) taken from the values of other 459 | attributes of surrounding elements, or from certain parts of those 460 | values. The value used will always be one which could have been specified 461 | explicitly, had it been known; it will never depend on the content or 462 | attributes of the same element, only on its environment. (What it means 463 | when used may, however, depend on those attributes or the content.)
464 | 465 |Default values described as automatic should be computed by 466 | a MathML renderer in a way which will produce a high-quality rendering; how 467 | to do this is not usually specified by the MathML specification. The value 468 | computed will always be one which could have been specified explicitly, had 469 | it been known, but it will usually depend on the element content and 470 | possibly on the context in which the element is rendered.
471 | 472 |Other italicized descriptions of default values which appear in the 473 | tables of attributes are explained individually for each attribute.
474 | 475 |The single or double quotes which are required around attribute values 476 | in an XML start tag are not shown in the tables of attribute value syntax 477 | for each element, but are around attribute values in examples in the 478 | text, so that the pieces of code shown are correct.
479 | 480 |Note that, in general, there is no mechanism in MathML to simulate the
481 | effect of not specifying attributes which are inherited or
482 | automatic. Giving the words inherited
or
483 | automatic
explicitly will not work, and is not generally
484 | allowed. Furthermore, the mstyle element ()
485 | can even be used to change the default values of presentation attributes
486 | for its children.
Note also that these defaults describe the 489 | behavior of MathML applications when an attribute is not supplied; 490 | they do not indicate a value that will be filled in by an XML parser, 491 | as is sometimes mandated by DTD-based specifications.
492 | 493 |In general, there are a number of
494 | properties of MathML rendering that may be thought of as overall
495 | properties of a document, or at least of sections of a large
496 | document. Examples might be mathsize (the math font
497 | size: see ), or the
498 | behavior in setting limits on operators such as integrals or sums
499 | (e.g., movablelimits or displaystyle), or
500 | upon breaking formulas over lines (e.g.
501 | linebreakstyle); for such attributes see several
502 | elements in .
503 | These may be thought to be inherited from some such
504 | containing scope. Just above we have mentioned the setting of default
505 | values of MathML attributes as inherited or
506 | automatic; there is a third source of global default values
507 | for behavior in rendering MathML, a MathML operator dictionary. A
508 | default example is provided in .
509 | This is also discussed in and examples are given in
510 | .
In addition to the attributes described specifically for each element,
519 | the attributes in the following table are allowed on every MathML element.
520 | Also allowed are attributes from the xml namespace, such as xml:lang,
521 | and attributes from namespaces other than MathML,
522 | which are ignored by default.
| Name | 530 |values | 531 |default | 532 |
|---|---|---|
| id | 539 |[=id=] | 540 |none | 541 |
545 | Establishes a unique identifier associated with the element
546 | to support linking, cross-references and parallel markup.
547 | See xref and .
548 | |
549 | ||
| xref | 553 |[=idref=] | 554 |none | 555 |
559 | References another element within the document.
560 | See id and .
561 | |
562 | ||
| class | 566 |[=string=] | 567 |none | 568 |
| 572 | Associates the element with a set of style classes for use with 573 | [[CSS21]]. 574 | See for discussion of the interaction of MathML and CSS. 575 | | 576 |||
| style | 580 |[=string=] | 581 |none | 582 |
| 586 | Associates style information with the element for use with 587 | [[CSS21]]. 588 | See for discussion of the interaction 589 | of MathML and CSS. 590 | | 591 |||
| href | 595 |URI | 596 |none | 597 |
| 601 | Can be used to establish the element as a hyperlink to the specified URI. 602 | | 603 |||
All MathML presentation elements accept intent and arg attributes to support specifying
611 | intent
. These are more fully described in
612 | [[[#mixing_intent]]].
| Name | 619 |values | 620 |default | 621 |
|---|---|---|
| intent | 628 |intent expression | 629 |none | 630 |
The intent attribute is more fully described
634 | in . It may be used on presentation
635 | elements to give information about the intended meaning of the
636 | expression, mainly for guiding audio or braille accessible
637 | renderings. |
638 | ||
| arg | 641 |name | 642 |none | 643 |
The arg attribute is more fully described
647 | in . It may be used to name an element to be referenced from an
648 | intent expression on an ancestor element. |
649 | ||
See also for a list of MathML attributes 656 | which can be used on most presentation token elements. 657 |
658 | 659 |In MathML, as in XML, whitespace
means simple spaces,
665 | tabs, newlines, or carriage returns, i.e., characters with hexadecimal
666 | Unicode codes U+0020, U+0009, U+000A, or
667 | U+000D, respectively; see also the discussion of whitespace in Section 2.3 of
668 | [[XML]].
MathML ignores whitespace occurring outside token elements.
671 | Non-whitespace characters are not allowed there. Whitespace occurring
672 | within the content of token elements, except for <cs>, is normalized as follows. All whitespace at the beginning and end of the content is
673 | removed, and whitespace internal to content of the element is
674 | collapsed canonically, i.e., each sequence of 1 or more
675 | whitespace characters is replaced with one space character (U+0020, sometimes
676 | called a blank character).
For example, <mo> ( </mo> is equivalent to
679 | <mo>(</mo>, and
683 | <mtext> 684 | Theorem 685 | 1: 686 | </mtext> 687 |688 |
is equivalent to
690 | <mtext>Theorem 1:</mtext>
691 | or
692 | <mtext>Theorem 1:</mtext>.
Authors wishing to encode white space characters at the start or end of
695 | the content of a token, or in sequences other than a single space, without
696 | having them ignored, must use non-breaking space U+00A0 (or nbsp)
697 | or other non-marking characters that are not trimmed.
698 | For example, compare the above use of an mtext element
699 | with
703 | <mtext> 704 |  <!--nbsp-->Theorem  <!--nbsp-->1: 705 | </mtext>706 |
When the first example is rendered, there is nothing before
709 | Theorem
, one Unicode space character between Theorem
and
710 | 1:
, and nothing after 1:
. In the
711 | second example, a single space character is to be rendered before
712 | Theorem
; two spaces, one a Unicode space character and
713 | one a Unicode no-break space character, are to be rendered before
714 | 1:
; and there is nothing after the
715 | 1:
.
Note that the value of the xml:space attribute is not relevant
718 | in this situation since XML processors pass whitespace in tokens to a
719 | MathML processor; it is the requirements of MathML processing which specify that
720 | whitespace is trimmed and collapsed.
For whitespace occurring outside the content of the token elements
723 | mi, mn, mo, ms, mtext,
724 | ci, cn, cs, csymbol and annotation,
725 | an mspace element should be used, as opposed to an mtext element containing
726 | only whitespace entities.
<math> ElementMathML specifies a single top-level or root math element,
737 | which encapsulates each instance of
738 | MathML markup within a document. All other MathML content must be
739 | contained in a math element; in other words,
740 | every valid MathML expression is wrapped in outer
741 | <math> tags. The math
742 | element must always be the outermost element in a MathML expression;
743 | it is an error for one math element to contain
744 | another. These considerations also apply when sub-expressions are
745 | passed between applications, such as for cut-and-paste operations;
746 | see .
The math element can contain an arbitrary number
749 | of child elements. They render by default as if they
750 | were contained in an mrow element.
The math element accepts any of the attributes that can be set on
756 | , including the common attributes
757 | specified in .
758 | In particular, it accepts the dir attribute for
759 | setting the overall directionality; the math element is usually
760 | the most useful place to specify the directionality
761 | (see for further discussion).
762 | Note that the dir attribute defaults to ltr
763 | on the math element (but inherits on all other elements
764 | which accept the dir attribute); this provides for backward
765 | compatibility with MathML 2.0 which had no notion of directionality.
766 | Also, it accepts the mathbackground attribute in the same sense
767 | as mstyle and other presentation elements to set the background
768 | color of the bounding box, rather than specifying a default for the attribute
769 | (see ).
In addition to those attributes, the math element accepts:
| Name | 779 |values | 780 |default | 781 |
|---|---|---|
| display | 788 |"block" | "inline" | 789 |inline | 790 |
794 | specifies whether the enclosed MathML expression should be rendered
795 | as a separate vertical block (in display style)
796 | or inline, aligned with adjacent text.
797 | When display=block, displaystyle is initialized
798 | to true,
799 | whereas when display=inline, displaystyle
800 | is initialized to false;
801 | in both cases scriptlevel is initialized to 0
802 | (see ).
803 | Moreover, when the math element is embedded in a larger document,
804 | a block math element should be treated as a block element as appropriate
805 | for the document type (typically as a new vertical block),
806 | whereas an inline math element should be treated as inline
807 | (typically exactly as if it were a sequence of words in normal text).
808 | In particular, this applies to spacing and linebreaking: for instance,
809 | there should not be spaces or line breaks inserted between inline math
810 | and any immediately following punctuation.
811 | When the display attribute is missing, a rendering agent is free to initialize
812 | as appropriate to the context.
813 | |
814 | ||
| maxwidth | 818 |length | 819 |available width | 820 |
| 824 | specifies the maximum width to be used for linebreaking. 825 | The default is the maximum width available in the surrounding environment. 826 | If that value cannot be determined, the renderer should assume an infinite rendering 827 | width. 828 | | 829 |||
| overflow | 833 |"linebreak" | "scroll" | "elide" | "truncate" | "scale" | 834 |linebreak | 835 |
| 839 | specifies the preferred handing in cases where an expression is too long to 840 | fit in the allowed width. See the discussion below. 841 | | 842 |||
| altimg | 846 |URI | 847 |none | 848 |
| 852 | provides a URI referring to an image to display as a fall-back 853 | for user agents that do not support embedded MathML. 854 | | 855 |||
| altimg-width | 859 |length | 860 |width of altimg |
861 |
865 | specifies the width to display altimg, scaling the image if necessary;
866 | see altimg-height.
867 | |
868 | ||
| altimg-height | 872 |length | 873 |height of altimg |
874 |
878 | specifies the height to display altimg, scaling the image if necessary;
879 | if only one of the attributes altimg-width and altimg-height
880 | are given, the scaling should preserve the image's aspect ratio;
881 | if neither attribute is given, the image should be shown at its natural size.
882 | |
883 | ||
| altimg-valign | 887 |length 888 | | "top" | "middle" | "bottom" | 889 |0ex | 890 |
894 | specifies the vertical alignment of the image with respect to adjacent inline material.
895 | A positive value of altimg-valign shifts the bottom of the image above the
896 | current baseline, while a negative value lowers it.
897 | The keyword "top" aligns the top of the image with the top of adjacent inline material;
898 | "center" aligns the middle of the image to the middle of adjacent material;
899 | "bottom" aligns the bottom of the image to the bottom of adjacent material
900 | (not necessarily the baseline). This attribute only has effect
901 | when display=inline.
902 | By default, the bottom of the image aligns to the baseline.
903 | |
904 | ||
| alttext | 908 |[=string=] | 909 |none | 910 |
| 914 | provides a textual alternative as a fall-back for user agents 915 | that do not support embedded MathML or images. 916 | | 917 |||
| cdgroup | 921 |URI | 922 |none | 923 |
927 | specifies a CD group file that acts as a catalogue of CD bases for locating
928 | OpenMath content dictionaries of csymbol, annotation, and
929 | annotation-xml elements in this math element; see . When no cdgroup attribute is explicitly specified, the
930 | document format embedding this math element may provide a method for determining
931 | CD bases. Otherwise the system must determine a CD base; in the absence of specific
932 | information http://www.openmath.org/cd is assumed as the CD base for all
933 | csymbol, annotation, and annotation-xml elements. This is the
934 | CD base for the collection of standard CDs maintained by the OpenMath Society.
935 | |
936 | ||
In cases where size negotiation is not possible or fails
941 | (for example in the case of an expression that is too long to fit in the allowed width),
942 | the overflow attribute is provided to suggest a processing method to the renderer.
943 | Allowed values are:
MathML has been widely adopted by assistive technologies (AT).
14 | However, math notations can be ambiguous which can result in AT guessing at what should be spoken in some cases.
15 | MathML 4 adds a lightweight method for authors to express their intent: the intent attribute.
16 | This attribute is similar to the aria-label attribute
17 | with some important distinctions.
18 | In terms of accessibility, the major difference is that intent
19 | does not affect braille generation.
20 | Most languages have a separate braille code for math so that the words used for speech should not be affected by braille generation.
21 | Some languages, such as English, have more than one braille math code and it is impossible for the author to know which is desired by the reader.
22 | Hence, even if the author knew the (math) braille for the element, they could not override aria-label
23 | by using the proposed aria-braillelabel because they wouldn't know which code to use.
24 |
As described in ,
27 | MathML elements allow attributes intent and arg that allow the
30 | intent
of the term to be specified. This
31 | annotation is not meant to provide a full mathematical definition
32 | of the term. It is primarily meant to help AT generate audio and/or braille renderings, see .
33 | Nevertheless, it may also be useful to guide translations to Content MathML, or computational systems.
The intent attribute encodes a
36 | simple functional syntax representing the intended speech.
37 | A formal grammar is given below, but a typical example would be
38 | intent="power($base,$exponent)" used in a context such as:
42 | <msup intent="power($base,$exp)"> 43 | <mi arg="base">x</mi> 44 | <mi arg="exp">n</mi> 45 | </msup> 46 |47 |
The intent value of power($base,$exp) makes it clear that the author intends that this expression
49 | denotes exponentiation as opposed to one of many other meanings of superscripts.
50 | Since power will be a concept supported by the AT, it may choose different
51 | ways of speaking depending on context, arguments or other details.
52 | For example, the above expression might be spoken as "x to the power n",
53 | but if "2" were given instead of "n", it may say "x squared".
intentThe value of the intent attribute, should match the following grammar.
61 | intent := self-property-list | expression
62 | self-property-list := property+ S
63 | expression := S ( term property* | application ) S
64 | term := concept-or-literal | number | reference
65 | concept-or-literal := NCName
66 | number := '-'? \d+ ( '.' \d+ )?
67 | reference := '$' NCName
68 | application := expression '(' arguments? S ')'
69 | arguments := expression ( ',' expression )*
70 | property := S ':' NCName
71 | S := [ \t\n\r]*
72 |
73 |
74 | Here NCName
75 | is as defined in in [[xml-names]], and digit is a character in the range 0–9.
The parts consist of:
79 |NCName production as used for
82 | no-namespace element name.
83 | A [=concept-or-literal=] are interpreted either as a [=concept=] or [=literal=].
84 | A concept corresponds to some mathematical or 87 | application specific function or concept. 88 | For many concepts, the words used to speak a concept are very similar to the name 89 | used when referencing a concept.
90 |A literal is a name starting with `_`
(U+00F5).
93 | These will never be included in an [=Intent Concept Dictionary=].
94 | The reading of a literal is generated by replacing any
95 | -, _, . in the name by
96 | spaces and then reading the resulting phrase.
2.5 denotes itself.
103 | $name refers to a descendant element
108 | that has an attribute arg="name". Unlike id
109 | attributes, arg do not have to be
110 | unique within a document. When searching for a matching element the
111 | search should only consider descendants, while stopping early at any
112 | elements that have a set intent or
113 | arg attribute, without descending
114 | into them.
115 | Proper use of [=reference=], instead of inserting equivalent literals,
116 | allows intent to be used while navigating the mathematical structure.
117 | The list of properties supported by any system is open but should include 140 | the core properties as described below.
141 |Every AT system that supports intent contains,
158 | at least implicitly, a list of the concepts that it recognizes.
159 | The details of matching and using concept names is given in .
160 | Such an AT SHOULD recognize the concepts in the [=Core=] list discussed below;
161 | It MAY also include concepts in the [=Open=] list discussed below,
162 | as well as any of its own.
An Intent Concept Dictionary
164 | is an abstract mapping of [=concept=] names to speech, text or braille for that concept;
165 | it is somewhat analogous to the used by
166 | MathML renderers in that it provides a set of defaults renderers should be aware of.
167 | The property also has some analogies to the operator dictionary's use of
168 | form because a match makes use of fixity properties
169 | (prefix, infix, etc.).
170 |
173 | [=Intent=] Concept names are maintained in two lists, each maintained in the 174 | w3c/mathml-docs GitHub repository. 175 | Note that while these concept dictionaries are published as HTML tables (based on yaml data), 176 | there is no requirement on how a system implements the mapping from concepts to speech hints. 177 | Rather than a fixed list or hash table, it might use XPath matching, regular expressions, 178 | appropriately trained generative AI or any other suitable mechansim. 179 | The only requirement is that it should accept the cases listed in the Core concept dictionary 180 | and produce acceptable speech hints for those cases. 181 |
182 | 183 |divide,
power, and 190 |
greater-than. The list is curated by the Math Working 191 | Group based on experience with different AT implementations and 192 | following the guidelines set out in [[?Concept-Lists]]. 193 |
NCName is allowed.
203 | Future versions of the core
concept list may incorporate names
206 | from the open
list if usage indicates that is appropriate.
207 |
Intent [=properties=] act as modifiers of the speech or Braille that
214 | otherwise would have been generated by the intent attribute.
215 | Most of these properties only have a
216 | defined effect in specific contexts, such as on the head of an
217 | application
219 | or applying to an <mtable>.
220 | The use of these properties in other contexts is not an error,
221 | but as with any properties, is by default ignored but may have a
222 | system-specific effect.
Similar to the lists of [=Concepts=], the Working Group maintains a [=Properties list=] of [=property=] values that should be implemented.
225 |Here, we describe the major classes of property affecting speech generation.
231 |:prefix,
233 | :infix, :postfix,
234 | :function, :silent
237 | These properties in a function application request that
239 | the reading of the name may be suppressed, or the word ordering may be affected.
240 | Note that the properties :prefix, :infix and :postfix
241 | refer to the spoken word order of the name and arguments,
242 | and not (necessarily) the order used in the displayed mathematical notation.
union is in the
247 | Core list with speech patterns "$1 union $2" and "union of $1 and $2".
248 | An intent union :prefix ($a,$b) would
249 | indicate that the latter style is preferred.
250 | f :prefix ($x) : f x
f :infix ($x,y) : x f y
f :postix ($x) : x f
f :function ($x, $y): f of x and y
f :silent ($x,$y) : x y
f:function($x, $y) could also be spoken as
263 | f of x comma y. If none of these properties is used, the 264 |
function property should be assumed unless the literal is
265 | silent (for example _) in which case the :silent property
266 | should be assumed. See the examples in .:literal, :common, :legacyThese properties control the overall style of generated speech. 272 | The detailed description in each case is available in a separate document.
273 |:literal requests that the AT should not infer any semantics
274 | and just speak the elements with a literal interpretation, including leaf content (eg |
might be spoken as vertical bar
). :common requests use of a specified set of heuristics do allow intents to be inferred for common notations. :legacy requests system-specific behavior.
:matrix,
277 | :system-of-equations, :lines, :continued-row, :equation-labelThese properties may be used on an mtable or on a
280 | [=reference=] to an mtable, mtr and mtd.
281 | They affect the way the parts of an alignment are announced.
The exact wordings used are system specfic.
283 |:matrix
285 | should be read in style suitable for matrices, with typically
286 | column numbers being announced.:system-of-equations should be read in style suitable for
288 | displayed equations (and inequalities), with typically
289 | column numbers not being announced. Each table row would
290 | normally be announced as an "equation" but a
291 | `continued-row` property on an mtr indicates
292 | that the row continues an equation wrapped from the row
293 | above.:equation-label may be used on an mtd to mark a cell containing an equation label.When the intent attribute corresponding to a specific node
303 | contains a concept component, the AT's [=Intent Concept Dictionary=] should be consulted.
304 | The concept name should be normalized
305 | (`_`
(U+00F5) and `.`
(U+002E) to `-`
(U+002D)),
306 | and compared using ASCII case-insensitive
307 | match. If arguments were given explicitly in the intent
308 | then their number gives the arity, and the
309 | fixity is determined from an explicit property
310 | or may default from the concept dictionary. Otherwise, arity is assumed to be 0.
A concept is considered a supported concept (by the AT)
312 | when the normalized name, the fixity property, and the arity
313 | all match an entry in the AT's concept dictionary.
314 | This does not exclude implementations which support additional concepts,
315 | as well as concepts with many arities, fixities or aliases,
316 | as long as they are mapped appropriately.
317 | The speech hint in the matching entry
318 | can be used as a guide for the generation of
319 | specific audio, replacement text or braille renderings, as appropriate.
320 | It can also help clarify argument order.
321 | However, because common notations have many specialized ways of being spoken, the AT
322 | is NOT constrained to use the hint as given. For example, AT may
323 | vocalize a fraction marked up with <mfrac>
324 | as three quarters
or three over x
325 | or may vocalize an inline fraction marked up as <mo>/</mo>
326 | as three divided by x
.
327 | The choice may depend on the contents
328 | and carrier element associated with an
329 | intent="divide($num,$denom)".
330 | Note that properties other than those specifying fixity
331 | may also indicate different rendering choices.
Otherwise, if the concept name, fixity and arity do not match that is considered to be an 333 | unsupported concept (by the AT) 334 | and will be treated the same as a [=literal=]; 335 | that is, the name is spoken as-is after normalizing each of `-`, `_` and `.` to an inter-word space. 336 | Even for an unsupported concept, if a fixity property and arguments were given, 337 | the speech for the arguments should be composed 338 | in a manner consistent with the given fixity property, if possible.
339 |Note that future updates of an AT may add or remove concepts in its [=Intent Concept Dictionary=]. 340 | Hence which concepts are supported may change with each update.
341 | 342 |In cases where the intent contains neither an explicit nor inferrable concept
343 | the AT should generally read out the MathML in a literal or structural fashion,
344 | as with the :literal property.
345 | However, any given [=properties=] should be respected if possible,
346 | and may be useful to indicate the kind of mathematical object,
347 | rather than giving an explicit [=concept=] name to be spoken.
348 | This can be a useful technique, especially for large constructs such as tables as
349 | it allows the children to be inferred without needing to be
350 | explicitly referenced in the `intent` as would be the case with an applicaton.
351 | For example, `<mtable intent=":array">...` might read the table as
352 | an array of values, whereas `<mtable intent=":system-of-equations">...`
353 | might read the table in a style more appropriate for a list of
354 | equations. In both cases the navigation of the underlying table
355 | structure can be supplied by the AT system, as it would for an
356 | unannotated table.
In general, depending upon the reader, AT may add words or sounds to make
359 | the speech clearer to the listener. For example, for someone
360 | who can not see the a fraction, AT might say fraction x over
361 | three end fraction
so the listener knows exactly what is
362 | part of the fraction. For someone who can see the content,
363 | these extra words might be a distraction. AT should always
364 | produce speech that is appropriate to the community they serve.
An intent processor may report errors in intent expressions in 370 | any appropriate way, including returning a message as the 371 | generated text, or throwing an exception (error) in whatever form 372 | the implementation supports. However in web platform contexts it is 373 | often not appropriate to report errors to the reader who has no 374 | access to correct the source, so intent procesors should offer a 375 | mode which recovers from errors as described below.
376 |intent
380 | attribute does not match the grammar ,
381 | then the processor should act as if the attribute were not
382 | present.
383 | Typically this will result in a suitable fallback text being
384 | generated from the MathML element and its descendants. Note that
385 | just the erroneous attribute is ignored, other intent attributes in the MathML
387 | expression should be used.arg attribute with value `x` on a
390 | descendant element, the processor should act as if the reference
391 | were replaced by the literal `_dollar_x`.The [=literal=] and [=property=] features extend the coverage of mathematical concepts 400 | beyond the predefined dictionaries and allow expression of speech preferences. 401 | For example, when `$x` and `$y` reference `<mi arg="x">x</mi>` and `<mi 402 | arg="y">y</mi>` respectively, then
403 |list :silent ($x,$y) would be read as x y
semi-factorial :postfix($x) would be read as x semi factorial
These features also allow taking almost complete control of the generated speech. 408 | For example, compare:
409 |free-algebra ($r, $x)free algebra of r and x
free-algebra-construct:silent (_free, $r, _algebra, _on, $x)free r algebra on x
_(free, _($r,algebra), on, $x)free r algebra; on x
However, since the literals are not in dictionaries, 420 | the meaning behind the expressions become more opaque, 421 | and thus excessive use of these features will tend to limit the AT's ability 422 | to adapt to the needs of the user, as well as limit translation and locale-specific speech. 423 | Thus, the last two examples would be discouraged.
424 |Conversely, when specific speech not corresponding to a meaningful concept
425 | is nevertheless required,
426 | it will be better to use a [=literal=] name (prefixed with `_`
)
427 | rather than an [=unsupported concept=].
428 | This avoids unexpected collisions with future updates to the concept dictionaries.
429 | Thus, the last example is particularly discouraged.
430 |
A primary use for intent is to
437 | disambiguate cases where the same syntax is used for different meanings,
438 | and typically has different readings.
Superscript, msup, may represent a power, a transpose,
441 | a derivative or an embellished symbol. These cases would be distinguished as follows, showing possible readings with and without intent
445 | <msup intent="power($base,$exp)"> 446 | <mi arg="base">x</mi> 447 | <mi arg="exp">n</mi> 448 | </msup> 449 |450 |
x to the n-th power451 |
x superscript n end superscript
An alternative default rendering without intent would be to assume that
453 | msup is always a power, so the second rendering above
454 | might also be x to the n-th power
. In that case the second renderings below
455 | will (incorrectly) speak the examples using raised to the ... power
.
456 |
459 | <msup intent="$op($a)"> 460 | <mi arg="a">A</mi> 461 | <mi arg="op" intent="transpose">T</mi> 462 | </msup> 463 |464 |
transpose of A465 |
A superscript T end superscript
However, with a property, this example might be read differently.
467 |469 | <msup intent="$op :postfix ($a)"> 470 | <mi arg="a">A</mi> 471 | <mi arg="op" intent="transpose">T</mi> 472 | </msup> 473 |474 |
A transpose475 |
479 | <msup intent="derivative($a)"> 480 | <mi arg="a">f</mi> 481 | <mi>′</mi> 482 | </msup> 483 |484 |
derivative of f485 |
f superscript prime end superscript
488 | <msup intent="x-prime"> 489 | <mi>x</mi> 490 | <mo>′</mo> 491 | </msup> 492 |493 |
x prime494 |
x superscript prime end superscript
Custom accessible descriptions, such as author-preferred variable or operator names, can also be annotated compositionally, via the underscore function.
497 |The above notation could instead intend the custom name "x-new", which we can mark with a single literal `intent="_x-new"`, or as a compound narration of two arguments:
498 |500 | <msup intent="_($base,$script)"> 501 | <mi arg="base">x</mi> 502 | <mo arg="script" intent="_new">′</mo> 503 | </msup> 504 |505 |
x new506 |
x superscript prime end superscript
Using the underscore function may also add clarity when the fragments of a compound name are explicitly localized. A cyrillic (Bulgarian) example:
509 |511 | <msup intent="_($base,$script)"> 512 | <mi arg="base" intent="_хикс">x</mi> 513 | <mo arg="script" intent="_прим">′</mo> 514 | </msup> 515 |516 |
хикс прим517 |
x superscript prime end superscript
Alternatively, the narration of individual fragments could be fully delegated to AT, while still specifying their grouping:
520 |522 | <msup intent="_($base,$script)"> 523 | <mi arg="base">x</mi> 524 | <mo arg="script">′</mo> 525 | </msup> 526 |527 |
x prime528 |
x superscript prime end superscript
An overbar may represent complex conjugation, or mean (average), again with possible readings with and without intent:
534 | <mover intent="conjugate($v)"> 535 | <mi arg="v">z</mi> 536 | <mo>¯</mo> 537 | </mover> 538 | <mtext> <!--nbsp-->is not <!--nbsp--></mtext> 539 | <mover intent="mean($var)"> 540 | <mi arg="var">X</mi> 541 | <mo>¯</mo> 542 | </mover> 543 |544 | 545 |
conjugate of z is not mean of X547 |
546 | z with bar above is not X with bar above
The intent mechanism is extensible through the use of [=unsupported concept=] names. 550 | For example, assuming that the Bell Number is not present in any of the dictionaries, 551 | the following example
552 |554 | <msub intent="bell-number($index)"> 555 | <mi>B</mi> 556 | <mn arg="index">2</mn> 557 | </msub> 558 |559 |
will still produce the expected reading:
560 |bell number of 2561 |
CSS customization of MathML is generally not made available to AT and is ignored 567 | in accessible readouts. 568 | In cases where authors have meaningful stylistic emphases, 569 | or stylized constructs with custom names, using an intent attribute is appropriate. 570 | For example, color-coding of subexpressions is often helpful in teaching materials:
571 |573 | <mn>1</mn><mo>+</mo> 574 | <mrow style="padding:0.1em;background-color:lightyellow;" 575 | intent="highlighted-step($step)"> 576 | <mfrac arg="step"><mn>6</mn><mn>2</mn></mfrac> 577 | </mrow> 578 | <mi>x</mi> 579 | <mo>=</mo> 580 | <mn>1</mn><mo>+</mo> 581 | <mn style="padding:0.1em;background-color:lightgreen;" 582 | intent="highlighted-result(3)">3</mn> 583 | <mi>x</mi> 584 |585 |
one plus highlighted step of six over two end highlighted step x 586 | equals one plus highlighted result of three end highlighted result x 587 |588 |
The <mtable> element is
595 | used in many ways, for denoting matrices, systems of equations,
596 | steps in a proof derivation, etc. In addition to these uses it
597 | may be used to implement forced line breaking and alignment,
598 | especially for systems that do not implement
599 | [[[#presm_linebreaking]]], or for conversions from (La)TeX where
600 | alignment constructs are used in similar ways.
Whenever a kind of tabular construct has an associated property, 602 | it is usually better to use only the property and allow AT to infer 603 | how to speak navigate the expression. By use of properties in this way the 604 | author can give hints to the speech generation and generate 605 | speech suitable for a list of aligned equations rather than say a matrix.
606 | 607 |When core properties are insufficient to represent a tabular 608 | layout, the use of intent concept names and, if appropriate, also 609 | properties from the open list of properties should be used to 610 | convey the desired speech and navigation of the tabular 611 | layout. Because of the likely complexity of these layouts, 612 | testing with AT should be done to verify that users hear the 613 | expression as the author intended.
614 | 615 | 616 | 617 |Matrices
618 |620 | <mrow intent='$m'> 621 | <mo>(</mo> 622 | <mtable arg='m' intent=':matrix'> 623 | <mtr> 624 | <mtd><mn>1</mn></mtd> 625 | <mtd><mn>0</mn></mtd> 626 | </mtr> 627 | <mtr> 628 | <mtd><mn>0</mn></mtd> 629 | <mtd><mn>1</mn></mtd> 630 | </mtr> 631 | </mtable> 632 | <mo>)</mo> 633 | </mrow> 634 |635 |
636 | The 2 by 2 matrix;643 |
637 | column 1; 1;
638 | column 2; 0;
639 | column 1; 0;
640 | column 2; 1;
641 | end matrix 642 |
Aligned equations
647 |649 | <mtable intent=':equations'> 650 | <mtr> 651 | <mtd columnalign="right"> 652 | <mn>2</mn> 653 | <mo>⁢<!--InvisibleTimes--></mo> 654 | <mi>x</mi> 655 | </mtd> 656 | <mtd columnalign="center"> 657 | <mo>=</mo> 658 | </mtd> 659 | <mtd columnalign="left"> 660 | <mn>1</mn> 661 | </mtd> 662 | </mtr> 663 | <mtr> 664 | <mtd columnalign="right"> 665 | <mi>y</mi> 666 | </mtd> 667 | <mtd columnalign="center"> 668 | <mo>></mo> 669 | </mtd> 670 | <mtd columnalign="left"> 671 | <mi>x</mi> 672 | <mo>-</mo> 673 | <mn>3</mn> 674 | </mtd> 675 | </mtr> 676 | </mtable> 677 |678 |
679 | 2 equations,683 |
680 | equation 1; 2 x, is equal to, 1;
681 | equation 2; y, is greater than, x minus 3; 682 |
Aligned Equations with wrapped expressions
686 | 687 |689 | <mtable intent=':equations'> 690 | <mtr> 691 | <mtd columnalign="right"> 692 | <mi>a</mi> 693 | </mtd> 694 | <mtd columnalign="center"> 695 | <mo>=</mo> 696 | </mtd> 697 | <mtd columnalign="left"> 698 | <mi>b</mi> 699 | <mo>+</mo> 700 | <mi>c</mi> 701 | <mo>-</mo> 702 | <mi>d</mi> 703 | </mtd> 704 | </mtr> 705 | <mtr intent=':continued-row'> 706 | <mtd columnalign="right"></mtd> 707 | <mtd columnalign="center"></mtd> 708 | <mtd columnalign="left"> 709 | <mo form="infix">+</mo> 710 | <mi>e</mi> 711 | <mo>-</mo> 712 | <mi>f</mi> 713 | </mtd> 714 | </mtr> 715 | </mtable> 716 |717 |
718 | 1 equation; a, is equal to, b plus c minus d; plus e minus f; 719 |720 |
Mathematics and its notations have evolved over several centuries, or even millennia. 11 | To the experienced reader, mathematical notation conveys 12 | a large amount of information quickly and compactly. 13 | And yet, while the symbols and arrangements of the notations 14 | have a deep correspondence to the semantic structure and meaning 15 | of the mathematics being represented, the notation and semantics 16 | are not the same. The semantic symbols and structures are 17 | subtly distinct from those of the notation.
18 | 19 |Thus, there is a need for a markup language 20 | which can represent both the traditional displayed notations 21 | of mathematics, as well as its semantic content. 22 | While the traditional rendering is useful to sighted readers, 23 | the markup language must also support accessibility. 24 | The semantic forms must support a variety of computational purposes. 25 | Both forms should be appropriate to all educational levels from 26 | elementary to research.
27 |33 | MathML is a markup language for describing mathematics. 34 | It uses XML syntax when used standalone or within other XML, 35 | or HTML syntax when used within HTML documents. 36 | Conceptually, MathML consists of two main strains of markup: 37 | Presentation markup is used to display mathematical expressions; 38 | and Content markup is used to convey mathematical meaning. 39 | These two strains, along with other external representations, 40 | can be combined using parallel markup. 41 |
42 | 43 |44 | This specification is organized as follows: 45 | discusses Fundamentals common to Presentation and Content markup; 46 | and cover Presentation and Content markup, 47 | respectively; 48 | discusses how markup may be annotated, particularly for accessibility; 49 | discusses how markup may be annotated so that Presentation, Content and other formats may be combined; 50 | addresses how MathML interacts with applications; 51 | Finally, a discussion of special symbols, 52 | and issues regarding characters, entities and fonts, 53 | is given in . 54 |
55 |60 | The specification of MathML is developed in two layers. 61 | MathML Core ([[MathML-Core]]) covers (most of) Presentation Markup, 62 | with the focus being the precise details of displaying mathematics in web browsers. 63 | MathML Full, this specification, extends [[[MathML-Core]]] 64 | primarily by defining Content MathML, in . 65 | It also defines extensions to Presentation MathML consisting 66 | of additional attributes, elements or enhanced syntax of attributes. 67 | These are defined for compatibility with legacy MathML, 68 | as well as to cover , 69 | and other aspects not included in level 1 of [[[MathML-Core]]] 70 | but which may be incorporated into future versions of [[[MathML-Core]]]. 71 |
72 |73 | This specification covers both MathML Core and its extensions; 74 | features common to both are indicated with 75 | , 76 | whereas extensions are indicated with . 77 |
78 |79 | It is intended that MathML Full is a proper superset of MathML Core. 80 | Moreover, it is intended that any valid Core Markup be considered as valid Full Markup as well. 81 | It is also intended that an otherwise conforming implementation of MathML Core, 82 | which also implements parts or all of the extensions of MathML Full, 83 | should continue to be considered a conforming implementation of MathML Core. 84 |
85 | 86 | 87 | 88 |92 | In addition to these two specifications, the Math WG group has developed the non-normative 93 | [[[MathML-Notes]]] 94 | that contains additional examples and information to help understand best practices when using MathML. 95 |
96 |References to sections in which an element is defined are marked in bold.
12 | 13 |In addition to the standard MathML attributes, some attributes from 20 | other namespaces such as Xlink or XML Schema are also listed here.
21 | 22 |The Relax NG schema may be used to check the XML serialization of 5 | MathML and serves as a foundation for validating other serializations 6 | of MathML, such as the HTML serialization.
7 |Even when using the XML serialization, some normalization of
8 | the input may be required before applying this schema. Notably,
9 | following HTML, [[MathML-Core]] allows attributes such as
10 | onclick to be specified in any case, eg
11 | OnClick="...".
12 | It is not practically feasible to specify that attribute names are
13 | case insensitive here so only the lowercase names are allowed.
14 | Similarly any attribute with name starting with the prefix
15 | data- should be considered valid. The schema here only
16 | allows a fixed attribute, data-other, so input should be
17 | normalized to remove data attributes before validating, or the schema
18 | should be extended to support the attributes used in a particular
19 | application.
The MathML DTD uses the strategy outlined in 5 | [[?Modularization]] to allow the use of namespace prefixes 6 | on MathML elements. However it is recommended that 7 | namespace prefixes are not used in XML serialization of 8 | MathML, for compatibility with the HTML serialization.
9 | 10 |Note that unlike the HTML serialization, when using the
11 | XML serialization, character entity references such as
12 | ∫ may not be used unless a DTD is
13 | specified, either the full MathML DTD as described here or the
14 | set of HTML/MathML entity declarations as specified by [[Entities]].
15 | Characters may always be specified by using character data directly, or numeric character references, so
16 | ∫ or ∫ rather than
17 | ∫.
MathML fragments can be validated using the XML Schema for MathML, 5 | located at http://www.w3.org/Math/XMLSchema/mathml4/mathml4.xsd. The 6 | provided schema has been mechanically generated from the Relax NG schema, it omits 7 | some constraints that can not be enforced using XSD syntax.
8 | 9 |Web platform implementations of MathML should implement [[MathML-Core]], 4 | and so the Privacy Considerations specified there apply.
5 |Web platform implementations of MathML should implement [[MathML-Core]], 4 | and so the Security Considerations specified there apply.
5 |Public discussion of MathML and issues of support through the W3C
5 | for mathematics on the Web takes place on the public mailing list of the Math Working
6 | Group (list archives).
7 | To subscribe send an email to www-math-request@w3.org
8 | with the word subscribe in the subject line.
9 | Alternatively, report an issue at this specification's
10 | GitHub repository.
12 | A fuller discussion of the document's evolution can be found in 13 | [[[#changes]]]. 14 |
15 |Some sections are collapsed and may be expanded to reveal more details. 16 | The following button may be used to expand all such sections. 17 |
18 | 19 |