数学用マークアップ言語 (MathML) ヴァージョン 4.0
Mathematical Markup Language (MathML) Version 4.0

W3C First Public Working Draft

More details about this document
This version:
Latest published version:
Latest editor's draft:
Commit history
David Carlisle (NAG(訳注:ニューメリカルアルゴリズムグループ))
David Carlisle (NAG)
Former editors:
Patrick Ion
Patrick Ion
Robert Miner (故人)
Robert Miner (deceased)
GitHub w3c/mathml (pull requests, new issue, open issues)
Latest MathML Recommendation


この仕様書は, 数学用マークアップ言語, MathMLを定義しています. MathMLは数学表記を記述したり, その構造と意味をうまく再現したりするマークアップ言語です. MathMLの目標は, [HTML]が文章に対してできるようにしたように, 数学をインターネット上で提供したり, 受け取ったり, 処理できたりするようにすることです.

This specification defines the Mathematical Markup Language, or MathML. MathML is a markup language for describing mathematical notation and capturing both its structure and content. The goal of MathML is to enable mathematics to be served, received, and processed on the World Wide Web, just as [HTML] has enabled this functionality for text.

このマークアップ言語MathMLの仕様書は本来, MathMLの描画ソフトウェアや編集ツール, もしくは入出力のプロトコルにMathMLを利用して通信するソフトウェアの, 開発もしくは実装をしている人々を読者として想定しています. この仕様書は, ユーザーガイドではなく参照用の文書です.

This specification of the markup language MathML is intended primarily for a readership consisting of those who will be developing or implementing renderers or editors using it, or software that will communicate using MathML as a protocol for input or output. It is not a User's Guide but rather a reference document.

MathMLは, 数学表記と数学の内容の両方をコード化するのに利用できます. 約38のMathMLタグが抽象的な表記構造については説明しており, 他の約170のMathMLタグが式の意図している意味を明確に特定する方法を提供しています. さらに続く章では, どのようにMathMLのコンテント要素とプレゼンテーション要素が相互に作用するか, どのようにMathML描画ソフトウェアが実装されブラウザと相互に作用するか論じています. 最後に, この文書は, 数学で利用される特別な文字の問題, それらの文字のMathMLでの処理, ユニコードでの存在, フォントの関係について取り組んでいます.

MathML can be used to encode both mathematical notation and mathematical content. About thirty-eight of the MathML tags describe abstract notational structures, while another about one hundred and seventy provide a way of unambiguously specifying the intended meaning of an expression. Additional chapters discuss how the MathML content and presentation elements interact, and how MathML renderers might be implemented and should interact with browsers. Finally, this document addresses the issue of special characters used for mathematics, their handling in MathML, their presence in Unicode, and their relation to fonts.

MathMLは人が読める言語ですが, MathMLを書く人は典型的に, 数式編集ツールや変換ソフトウェア, また, MathMLを生成する他の特別なソフトウェアを利用するでしょう. 様々なヴァージョンのそういったMathMLソフトウェアが存在し, 無料で利用できるソフトウェアも商用ソフトウェアも両方あり, さらにたくさんのソフトウェアが開発中です.

While MathML is human-readable, authors typically will use equation editors, conversion programs, and other specialized software tools to generate MathML. Several versions of such MathML tools exist, both freely available software and commercial products, and more are under development.

MathMLは元来XMLアプリケーションとして仕様が定められており, この仕様書の例のほとんどはXMLの構文を想定しています. 他の構文も利用可能で, 中でも[HTML]はHTMLの中のMathMLの構文を定めています. 特に注意書きが無い場合, この仕様書の例は有効なHTMLの構文でもあります.

MathML was originally specified as an XML application and most of the examples in this specification assume that syntax. Other syntaxes are possible, most notably [HTML] specifies the syntax for MathML in HTML. Unless explicitly noted, the examples in this specification are also valid HTML syntax.

Status of This Document

この節では, 公表された時点でのこの文書の位置付けについて述べます. 最新のW3Cの公表した文書のリストやこの技術報告書の最新版は, W3C技術報告書の索引(http://www.w3.org/TR/)で見ることができます.

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

MathMLについての公式な議論やインターネット上の数学に関するW3Cを通じた対応における課題については, 数学作業部会の公式なメーリングリスト (履歴一覧)で交わされています. 寄付をされたい場合, 題名にsubscribeという語句を記入してwww-math-request@w3.orgにメールを送付して下さい. あるいは, この仕様書のGitHubリポジトリに課題を報告して下さい.

Public discussion of MathML and issues of support through the W3C for mathematics on the Web takes place on the public mailing list of the Math Working Group (list archives). To subscribe send an email to www-math-request@w3.org with the word subscribe in the subject line. Alternatively, report an issue at this specification's GitHub repository.

この文書の発展についての全ての議論は, I. 変更点で見つけられるでしょう.

A fuller discussion of the document's evolution can be found in I. Changes.

節の中には, 省略されていて, より詳細を見るために展開できるものもあります. 次のボタンは, そのような全ての節を展開するために利用できるでしょう.

Some sections are collapsed and may be expanded to reveal more details. The following button may be used to expand all such sections.

この文書は, 数学作業部会によって, 勧告工程に従って, 初期草案として発行されました.

This document was published by the Math Working Group as a First Public Working Draft using the Recommendation track.

初期草案としての発行は, W3Cおよびその会員による支持を意味していません.

Publication as a First Public Working Draft does not imply endorsement by W3C and its Members.

この文書は草案であり, いつでも他の文書によって更新されたり, 置き換えられたり, 使われなくなったりするかもしれません. 作業の経過によらず, この文書を掲載することが不適当になります.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

この文書は, W3C特許指針の下で運営している作業部会によって作成されました. W3Cは, この作業部会の成果に関連して作成された特許開示の公開一覧を管理しています. この一覧のページは, 特許を開示する場合の指示書きを含んでいます. 特許について実際に生じている情報を持っている方は, その情報が本質的な主張(訳注:当該日本語訳では"Essential Claim"の日本語訳に"本質的な主張"を当てていますが, "Essential Claim"という用語はW3C特許指針で定義された用語です.)に当たると思われる場合, W3C特許指針の第6節に従って必ずその情報を開示して下さい.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

この文書は, 2021年11月2日版のW3C手続き文書により決定されました.

This document is governed by the 2 November 2021 W3C Process Document.

Issue summary

1. 導入


This section is non-normative.

1.1 数学とその表記
Mathematics and its Notation

数学とその表記は, 何百年も, 何千年にもわたって発展してきました. 経験豊かな読者に向けて, 数学表記は, 膨大な情報を速やかに, そして簡潔に伝えます. 一方で, その表記の記号や取り決めは, 表現された数学の意味に関する構造や意味そのものと深く調和しているにも関わらず, 表記と意味は同一ではありません. 意味に関する記号や構造は, それらの表記と微妙に異なっています.

Mathematics and its notations have evolved over several centuries, or even millennia. To the experienced reader, mathematical notation conveys a large amount of information quickly and compactly. And yet, while the symbols and arrangements of the notations have a deep correspondence to the semantic structure and meaning of the mathematics being represented, the notation and semantics are not the same. The semantic symbols and structures are subtly distinct from those of the notation.

したがって, 数学の伝統的な描画された表記とその意味する内容の両方を表現できるマークアップ言語が必要です. 伝統的な描画は, 目が見える読者にとっては利用しやすいですが, マークアップ言語は, アクセシビリティにも対応しなければなりません. 意味に関する形式は, 様々な計算の目的に対応しなければなりません. 両方の形式が, 初等教育から学術研究までの全ての教育水準に適合すべきです.

Thus, there is a need for a markup language which can represent both the traditional displayed notations of mathematics, as well as its semantic content. While the traditional rendering is useful to sighted readers, the markup language must also support accessibility. The semantic forms must support a variety of computational purposes. Both forms should be appropriate to all educational levels from elementary to research.

1.2 概要

MathMLは, 数学を記述するためのマークアップ言語です. MathMLは, 単独または他のXMLの中で用いられるときはXML構文を使用し, HTML文書の中で用いられるときはHTML構文を使用します. 概念的に, MathMLは, 2つの主なマークアップの系統から成ります. プレゼンテーションマークアップは, 数式を表示するために使用されます. そして, コンテントマークアップは, 数学の意味を伝えるために使用されます. これらの2つの系統は, 他の外部の表現と一緒に, 並列のマークアップを使用して混在させることもできます.

MathML is a markup language for describing mathematics. It uses XML syntax when used standalone or within other XML, or HTML syntax when used within HTML documents. Conceptually, MathML consists of two main strains of markup: Presentation markup is used to display mathematical expressions; and Content markup is used to convey mathematical meaning. These two strains, along with other external representations, can be combined using parallel markup.

この仕様書は, 次のもので構成されます. 2. MathMLの基礎は, プレゼンテーションマークアップとコンテントマークアップに共通する基礎について論じています. 3. プレゼンテーションマークアップ4. コンテントマークアップは, それぞれプレゼンテーションマークアップとコンテントマークアップについて網羅しています. 5. MathMLに注釈を付けるは, どのようにマークアップに注釈を付けてもよいか, 特にアクセシビリティのためにどうするのか, また, どのようにプレゼンテーションマークアップやコンテントマークアップや他の書式が混在してもよいのかについて論じています. 6. ホスト環境との相互作用は, どのようにMathMLがアプリケーションソフトウェアと相互作用するかに取り組んでいます. 最後に, 特別な記号についての議論や文字, 実体, フォントに関する課題は, 7. 文字, 実体, フォントの中で示しています.

This specification is organized as follows: 2. MathML Fundamentals discusses Fundamentals common to Presentation and Content markup; 3. Presentation Markup and 4. Content Markup cover Presentation and Content markup, respectively; 5. Annotating MathML discusses how markup may be annotated, particularly for accessibility, as well as how Presentation, Content and other formats may be combined; 6. Interactions with the Host Environment addresses how MathML interacts with applications; Finally, a discussion of special symbols, and issues regarding characters, entities and fonts, is given in 7. Characters, Entities and Fonts.

1.3 MathMLコアとの関係
Relation to MathML Core

MathMLの仕様書は, 2つの層で開発されています. MathMLコア ([MathMLコア])は, ウェブブラウザで数学を描画する際の正確な細部に焦点を当てることで, (ほとんどの)プレゼンテーションマークアップを網羅しています. 完全なMathML, すなわちこの仕様書は, 第一に4. コンテントマークアップでコンテントMathMLを定義することでMathMLコアを拡張しています. この仕様書は, 追加の属性, 要素, 属性のより強化された構文から成る, プレゼンテーションMathMLの拡張も定義しています. それらの拡張は, 従来のMathMLとの互換性のために, また, 3.1.7 式の改行, 3.6 初等数学, MathMLコアレベル1に含まれていない他の側面を網羅するために定義されました. ただし, それらの側面は, MathMLコアの将来版に組み入れられるかもしれません.

The specification of MathML is developed in two layers. MathML Core ([MathML-Core]) covers (most of) Presentation Markup, with the focus being the precise details of displaying mathematics in web browsers. MathML Full, this specification, extends MathML Core primarily by defining Content MathML, in 4. Content Markup. It also defines extensions to Presentation MathML consisting of additional attributes, elements or enhanced syntax of attributes. These are defined for compatibility with legacy MathML, as well as to cover 3.1.7 Linebreaking of Expressions, 3.6 Elementary Math and other aspects not included in level 1 of MathML Core but which may be incorporated into future versions of MathML Core.

この仕様書は, MathMLコアとその拡張の両方を網羅しています. 両方に共通の機能はで示され、一方, 拡張はで示されています.

This specification covers both MathML Core and its extensions; features common to both are indicated with , whereas extensions are indicated with .

このことは, 完全なMathMLがMathMLコアの適切な上位集合であることを意図しています. さらに, 何らかの有効なMathMLコアは有効な完全なマークアップと見なされることを意図しています. また, MathMLコアに適合した実装とは別の, 完全なMathMの拡張の一部または全部を実装したものは, 引き続きMathMLコアの適合した実装と見なされるべきであることを意図しています.

It is intended that MathML Full is a proper superset of MathML Core. Moreover, it is intended that any valid Core Markup be considered as valid Full Markup as well. It is also intended that an otherwise conforming implementation of MathML Core, which also implements parts or all of the extensions of MathML Full, should continue to be considered a conforming implementation of MathML Core.

1.4 MathMLメモ
MathML Notes

これらの2つの仕様書に加えて, 数学作業部会は, 規範的でないMathMLにおけるメモを開発しています. その文書は, MathMLを利用する際の最良の慣例を理解するのを助ける, 追加の例や情報を含んでいます.

In addition to these two specifications, the Math WG group has developed the non-normative Notes on MathML that contains additional examples and information to help understand best practices when using MathML.

2. MathMLの基礎
MathML Fundamentals

2.1 MathML構文と文法
MathML Syntax and Grammar

2.1.1 一般的に考慮すべき点
General Considerations

MathMLの基本となる‘構文’は, XML構文を用いて定義されていますが, 番号付きのツリー構造をコード化できる他の構文も利用可能です. 特にHTML処理プログラムは, MathMLと一緒に利用されるかもしれません. この構文の上に, 要素が現れる順番やどのように要素がお互いの中に含まれるかといった要素に示された決まり, また, 属性の値についての追加の構文上の決まりとなる‘文法’を重ねます. それらの決まりは, この仕様書で定義されており, A. MathMLの処理のRelaxNGスキーマ[RELAXNGスキーマ]により書かれています. 他の書式に由来する構文, DTD(文書型宣言), XMLスキーマ[XMLスキーマ]も提供されています.

The basic ‘syntax’ of MathML is defined using XML syntax, but other syntaxes that can encode labeled trees are possible. Notably the HTML parser may also be used with MathML. Upon this, we layer a ‘grammar’, being the rules for allowed elements, the order in which they can appear, and how they may be contained within each other, as well as additional syntactic rules for the values of attributes. These rules are defined by this specification, and formalized by a RelaxNG schema [RELAXNG-SCHEMA] in A. Parsing MathML. Derived schema in other formats, DTD (Document Type Definition) and XML Schema [XMLSchemas] are also provided.

MathMLの文字セットは, 使用されている構文で認められている何らかのユニコード[ユニコード]から構成されています. ([XML]または[HTML]の例を参照して下さい.) 数学でのユニコードの利用については, 7. 文字, 実体, フォントで論じています.

MathML's character set consists of any Unicode characters [Unicode] allowed by the syntax being used. (See for example [XML] or [HTML].) The use of Unicode characters for mathematics is discussed in 7. Characters, Entities and Fonts.

続く節では, MathML文法の一般的な側面について論じたり, 属性の値で利用される構文について説明しています.

The following sections discuss the general aspects of the MathML grammar as well as describe the syntaxes used for attribute values.

2.1.2 MathMLと名前空間
MathML and Namespaces

XML名前空間[名前空間]は, URIによって特定された名前の集合です. MathML名前空間に対するURIは次のとおりです.

An XML namespace [Namespaces] is a collection of names identified by a URI. The URI for the MathML namespace is:


MathMLのXMLシリアル化(訳注:"名前を一意に定める機能"を意図)を利用した場合に名前空間を宣言するには, xmlns属性を利用するか, もしくはxmlns接頭辞で始まる属性を利用します.

To declare a namespace when using the XML serialisation of MathML, one uses an xmlns attribute, or an attribute with an xmlns prefix.

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

xmlns属性を接頭辞として利用する場合, 他の要素と属性を, 特定の名前空間と明確に結び付けるのに利用できる接頭辞を宣言します. XML構文を使用するHTMLに埋め込まれたMathMLの場合, 次のように利用するでしょう.

When the xmlns attribute is used as a prefix, it declares a prefix which can then be used to explicitly associate other elements and attributes with a particular namespace. When embedding MathML within HTML using XML syntax, one might use:

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

HTMLは同じ方法で名前空間を拡張することに対応しておらず, HTML処理プログラムは, HTML, SVG, MathML名前空間について元々組み込まれている情報のみを持っています. xmlns属性は, 単に通常の属性として扱われます. したがって, MathMLのHTMLシリアル化を利用する場合, 接頭辞の付いた要素名は使用してはなりません. xmlns="http://www.w3.org/1998/Math/MathML"がmath要素で使用されるかもしれませんが, HTML処理プログラムは, それを無視します. MathMLの式がXML処理プログラムやHTML処理プログラムで処理される文脈の中にあるような場合, 最大限の互換性を確かなものにするために次の形式を利用すべきです.

HTML does not support namespace extensibility in the same way, the HTML parser has in-built knowledge of the HTML, SVG and MathML namespaces. xmlns attributes are just treated as normal attributes. Thus when using the HTML serialisation of MathML, prefixed element names must not be used. xmlns=http://www.w3.org/1998/Math/MathML may be used on the math element, it will be ignored by the HTML parser. If a MathML expression is likely to be in contexts where it may be parsed by an XML parser or an HTML parser, it SHOULD use the following form to ensure maximum compatibility:

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

2.1.3 子要素と引数
Children versus Arguments

概念上は, 単独の引数しか持たないプレゼンテーション要素がありますが, 便利なように任意の数を持つように書かれてきました. その場合, 省略されたmrowが疑問にあった要素の引数としてふるまう子要素を囲っています. 省略された<mrow>を参照して下さい.

There are presentation elements that conceptually accept only a single argument, but which for convenience have been written to accept any number of children; then we infer an mrow containing those children which acts as the argument to the element in question; see Inferred <mrow>s.

MathML仕様書の至るところにある要素それぞれに与えられた要素の構文の詳細な議論において, 必要な引数の数と引数の順番, 他の内容についての制約について指定されています. この情報は, 3.1.3 必要な引数でプレゼンテーション要素に対して一覧にされています.

In the detailed discussions of element syntax given with each element throughout the MathML specification, the number of arguments required and their order, as well as other constraints on the content, are specified. This information is also tabulated for the presentation elements in 3.1.3 Required Arguments.

2.1.4 MathMLと描画
MathML and Rendering

[MathMLコア]のウェブプラットフォームでの実装は, その仕様書の中で指定された詳細な配置の決まりに従うべきです.

Web Platform implementations of [MathML-Core] should follow the detailed layout rules specified in that document.

この文書は, プレゼンテーションMathMLを描画する特定の方法を推奨しているのみです(すなわち, 必須とはしていません). これは, 媒体依存の描画やCSSに基づくウェブプラットフォームを使用しない実装を認めるためです.

This document only recommends (i.e., does not require) specific ways of rendering Presentation MathML; this is in order to allow for medium-dependent rendering and for implementations not using the CSS based Web Platform.

2.1.5 MathML属性の値
MathML Attribute Values

MathML要素は, 要素の意味または効果を詳細に特定する値と一緒に属性を使用します. 属性の名前は, この文書の中では等幅フォントで示します. 属性の意味や利用可能な値は, 各要素の仕様の中で説明します. この節で説明する構文の表記は, 利用可能な値を指定するのに使用されます.

MathML elements take attributes with values that further specialize the meaning or effect of the element. Attribute names are shown in a monospaced font throughout this document. The meanings of attributes and their allowed values are described within the specification of each element. The syntax notation explained in this section is used in specifying allowed values. MathML仕様書で使われる構文表記
Syntax notation used in the MathML specification

属性の値についてMathMLで指定された構文を説明するのに, 次に示す慣習と表記がこの文書のほとんどの属性に使用されます.

To describe the MathML-specific syntax of attribute values, the following conventions and notations are used for most attributes in the present document.

What it matches
[MathMLコア]で定義された, 最初の文字がハイフンマイナス文字(-)でもプラス記号(+)でもない整数
As defined in [MathML-Core], an integer, whose first character is neither U+002D HYPHEN-MINUS character (-) nor U+002B PLUS SIGN (+).
符号無し整数の文字列, ただし, 単に"0"(U+0030)のみから成るものは除く, 正の整数を表す
An unsigned-integer not consisting solely of "0"s (U+0030), representing a positive integer
必須でない"-"(U+002D), それに続く符号無し整数, 整数を表す
an optional "-" (U+002D), followed by an unsigned-integer, and representing an integer
[CSS-VALUES-3]で定義された値, 最初の文字がハイフンマイナス文字(-)でもプラス記号(+)でもない, 10進数で終わる数(有理数の型)を表す
value as defined in [CSS-VALUES-3] number, whose first character is neither U+002D HYPHEN-MINUS character (-) nor U+002B PLUS SIGN (+), representing a non-negative terminating decimal number (a type of rational number)

必須でない接頭辞"-"(U+002D), それに続く符号無し数, 10進数で終わる数(有理数の型)を表す
an optional prefix of "-" (U+002D), followed by an unsigned number, representing a terminating decimal number (a type of rational number)
a single non-whitespace character
an arbitrary, nonempty and finite, string of characters
長さ, 後で説明, 長さの値の属性
a length, as explained below, Length Valued Attributes
名前付き長さ, 名前付き長さ, 長さの値の属性の中で説明
a named length, namedspace, as explained in Length Valued Attributes

色, [CSS-Color-3]で指定された構文を使用
a color, using the syntax specified by [CSS-Color-3]
id 文書の中で唯一である識別子, XML勧告[XML]の名前の構文を満足しなければならない
an identifier, unique within the document; must satisfy the NAME syntax of the XML recommendation [XML]
文書の中の他の要素を参照する識別子, XML勧告[XML]の名前の構文を満足しなければならない
an identifier referring to another element within the document; must satisfy the NAME syntax of the XML recommendation [XML]
URI 統一資源識別子[RFC3986]. 属性の値は, 何らかの一連のXML文字で与えられた, 何らかのURIとして構文の中で分類されることに注意して下さい. URLとして文字列を利用する必要のあるシステムは, URLで認められていない文字を, HHが16進数のバイト値である%HHというパーセントエンコードを利用して, UTF-8文字コードのバイトでコード化しなければなりません. これは, そのような属性値をIRIとして, もっと一般にLEIRIとして解釈することを確かにします. [IRI]を参照して下さい.
a Uniform Resource Identifier [RFC3986]. Note that the attribute value is typed in the schema as anyURI which allows any sequence of XML characters. Systems needing to use this string as a URI must encode the bytes of the UTF-8 encoding of any characters not allowed in URI using %HH encoding where HH are the byte value in hexadecimal. This ensures that such an attribute value may be interpreted as an IRI, or more generally a LEIRI, see [IRI].
italicized word
それぞれの属性について文章で説明された値, 属性の既定値参照, (注釈:原文では斜体となっているものを日本語訳では太字+下線付きで記載)
values as explained in the text for each attribute; see Default values of attributes
引用符で囲まれた記号, 属性値の中に文字通り現れる(例えば"+"または'+')
quoted symbol, literally present in the attribute value (e.g. "+" or '+')

上で述べられている‘型’は, 文字列を除いて, 次に示す演算子を使用して混合した様式に組み合せることができます. 全ての属性値は, 記述されている文書の中で一重(')または二重(")引用符によって境界を決めなければなりません. この仕様書では, 二重引用符が文字列の式を記述するのによく使用されることに注意して下さい. 例としては, 上の表の5行目の"-"です.

The ‘types’ described above, except for string, may be combined into composite patterns using the following operators. The whole attribute value must be delimited by single (') or double (") quotation marks in the marked up document. Note that double quotation marks are often used in this specification to mark up literal expressions; an example is the "-" in line 5 of the table above.

下の表でfは上の表で述べた型を意味します. 組み合せる演算子は, 優先度の高いものから低いものの順で示しています.

In the table below a form f means an instance of a type described in the table above. The combining operators are shown in order of precedence from highest to lowest:

What it matches
( f ) fと同じ
same as f
f ? 0または1つのf
an optional instance of f
f * 空白文字で区切られた0以上のf
zero or more instances of f, with separating whitespace characters
f + 空白文字で区切られた1つ以上のf
one or more instances of f, with separating whitespace characters
f1 f2 ... fn 空白文字で区切られていないfiそれぞれの一連のもの
one instance of each form fi, in sequence, with no separating whitespace
f1, f2, ..., fn (コンマでなく)空白文字で区切られたfiそれぞれの一連のもの
one instance of each form fi, in sequence, with separating whitespace characters (but no commas)
f1 | f2 | ... | fn 指定されたのfiどれか1つ
any one of the specified forms fi

ここで使用する表記は, MathMLの基本となる構文(A. MathMLの処理)として利用されるRelaxNGの構文表記の書式です.

The notation we have chosen here is in the style of the syntactical notation of the RelaxNG used for MathML's basic schema, A. Parsing MathML.

ソフトウェアの中には空白の標準化が一貫していないものもあるので, 最大の相互運用性のためには, 属性値の部分部分を区切るのに単独の空白文字のみを使用するのが賢明です. さらに, 属性値の中の最初と最後の空白は避けるべきです.

Since some applications are inconsistent about normalization of whitespace, for maximum interoperability it is advisable to use only a single whitespace character for separating parts of a value. Moreover, leading and trailing whitespace in attribute values should be avoided.

ほとんどの数値の属性に対して, 表現可能な属性値の値の一部のみがふさわしい値です. それ以外の値は, 他で指定されていない限りエラーにはなりませんが, その代わり(描画ソフトウェア次第で)認められている範囲の最も近い値に切り上げられたり切り捨てられたりします. 認められている値の範囲は描画ソフトウェアに依存してもよいですし, MathMLでは指定していません.

For most numerical attributes, only those in a subset of the expressible values are sensible; values outside this subset are not errors, unless otherwise specified, but rather are rounded up or down (at the discretion of the renderer) to the closest value within the allowed subset. The set of allowed values may depend on the renderer, and is not specified by MathML.

属性値の構文の説明の中の数値の値が, 例えば整数といったマイナス記号('-')が認められていると宣言されている場合, 負の値がふさわしくない状況で使用されたとしても構文エラーにはなりません. その代わり, 値は処理ソフトウェアによって前の段落で説明したように扱われるべきです. 明確なプラス記号('+')は, (引用符で囲まれた'+'または"+"として)構文で明確に示されていない限り, 数値の値の一部としては認められません. また, プラス記号の存在は(それぞれの属性で認められると文書化されていても)属性の値の意味を変えてしまうでしょう.

If a numerical value within an attribute value syntax description is declared to allow a minus sign ('-'), e.g., number or integer, it is not a syntax error when one is provided in cases where a negative value is not sensible. Instead, the value should be handled by the processing application as described in the preceding paragraph. An explicit plus sign ('+') is not allowed as part of a numerical value except when it is specifically listed in the syntax (as a quoted '+' or "+"), and its presence can change the meaning of the attribute value (as documented with each attribute which permits it). 長さの値の属性
Length Valued Attributes

ほとんどのプレゼンテーション要素は, 大きさ, 間隔, またはそれらに類似した特性に対して使用する, 長さを表わす値を受け入れる属性を持っています. [MathMLコア]は, [CSS-VALUES-3]で定義された<長さや百分率>の構文における長さしか受け入れません. 完全なMathMLは, 次の名前付き長さも受け入れることで, 長さの構文を拡張しています.

Most presentation elements have attributes that accept values representing lengths to be used for size, spacing or similar properties. [MathML-Core] accepts lengths only in the <length-percentage> syntax defined in [CSS-VALUES-3]. MathML Full extends length syntax by accepting also a namedspace being one of:

Positive space
Negative space

veryverythinmathspace negativeveryverythinmathspace ±1/18 em
verythinmathspace negativeverythinmathspace ±2/18 em
thinmathspace negativethinmathspace ±3/18 em
mediummathspace negativemediummathspace ±4/18 em
thickmathspace negativethickmathspace ±5/18 em
verythickmathspace negativeverythickmathspace ±6/18 em
veryverythickmathspace negativeveryverythickmathspace ±7/18 em

加えて, mpaddedの属性は, 中身の元々の大きさを示す(通常のCSS単位の代わりをする)3つの疑似添え字height, depth, widthを認めています.

In addition, the attributes on mpadded allow three pseudo-units, height, depth and width (taking the place of one of the usual CSS units) denoting the original dimensions of the content.

MathML 3は, 単位無しの数字として指定される長さの非推奨の利用も認めていました. この利用は, 参照する値の倍数として解釈されていました. この形式は, MathML 4では無効と見なされます.

MathML 3 also allowed a deprecated usage with lengths specified as a number without a unit. This was interpreted as a multiple of the reference value. This form is considered invalid in MathML 4. 単位についての追加の注意点
Additional notes about units

ここで, 相対的な単位の2つの追加の側面について明らかにしておかなければなりません. 1つは, 要素の中には, 3.4 添え字の配置要素またはmmfracといった, 暗黙のうちにそれらの引数の内いくつかのフォントの大きさをより小さく切り替えるものがあることです. 同様に, mstyleは現在のフォントの大きさを明確に変更するために利用できます. そのような場合, それらの要素の中のemexの効果的な値は, 外側とは異なるでしょう. 2つ目の点は, 属性値で利用されるemexの有効な値は, 現在のフォントの大きさの変更に影響されるであろうことです. よって, mathsizescriptlevelといった現在のフォントの大きさに影響する属性は, 他の長さの値を持つ属性が評価される前に処理されなければなりません.

Two additional aspects of relative units must be clarified, however. First, some elements such as 3.4 Script and Limit Schemata or mfrac implicitly switch to smaller font sizes for some of their arguments. Similarly, mstyle can be used to explicitly change the current font size. In such cases, the effective values of an em or ex inside those contexts will be different than outside. The second point is that the effective value of an em or ex used for an attribute value can be affected by changes to the current font size. Thus, attributes that affect the current font size, such as mathsize and scriptlevel, must be processed before evaluating other length valued attributes. 属性の既定値
Default values of attributes

MathML属性に対する既定値は, 一般にこの文書の特定の要素の詳細な説明で一緒に示されています. 要素の属性の表で装飾されていない文字で示された既定値は文字列の値ですが, 下線付き太字(注釈:原文では斜体となっているものを日本語訳では下線付き太字で記載)で示された例のときは既定値がどのように計算されるかという説明です.

Default values for MathML attributes are, in general, given along with the detailed descriptions of specific elements in the text. Default values shown in plain text in the tables of attributes for an element are literal, but when italicized are descriptions of how default values can be computed.

継承すると述べられている既定値は, 3.3.4 書式の変更 <mstyle>で述べられている描画環境から引き継がれます. または, (個別に説明されている)いくつかの場合, 周囲を囲んでいる要素の他の属性の値やそれらの値の一部から引き継がれます. 使用される値は, やろうと思えば, いつも明確に指定しておくことができる値でしょう. その値は, 同じ要素の内容や属性には依存せず, 環境にのみ依存します. (しかしながら, それが何を意味しているのか, いつ使われるのかというと, それらの属性や内容に依存します.)

Default values described as inherited are taken from the rendering environment, as described in 3.3.4 Style Change <mstyle>, or in some cases (which are described individually) taken from the values of other attributes of surrounding elements, or from certain parts of those values. The value used will always be one which could have been specified explicitly, had it been known; it will never depend on the content or attributes of the same element, only on its environment. (What it means when used may, however, depend on those attributes or the content.)

自動と述べられている既定値は, MathML描画ソフトウェアによって, 良質な描画を提供するであろう方法に従って計算されます. どのように計算されるかは, 通常MathML仕様書では指定していません. 計算される値は, やろうと思えば, いつも明確に指定しておくことができる値でしょう. ただし, その値は, 通常は要素の内容や, もしかすると要素が描画される文脈に依存するでしょう.

Default values described as automatic should be computed by a MathML renderer in a way which will produce a high-quality rendering; how to do this is not usually specified by the MathML specification. The value computed will always be one which could have been specified explicitly, had it been known, but it will usually depend on the element content and possibly on the context in which the element is rendered.

属性の表に現れた既定値の他の下線付き太字(注釈:原文では斜体となっているものを日本語訳では下線付き太字で記載)の説明は, それぞれの属性ごとに説明しています.

Other italicized descriptions of default values which appear in the tables of attributes are explained individually for each attribute.

XMLの開始タグの中の属性値の周りに必要とされる一重引用符や二重引用符は, それぞれの要素の属性値の構文の表では示されませんが, この文書の例の中の属性値の周りには付けますし, 示されたコードの部分部分は正しいです.

The single or double quotes which are required around attribute values in an XML start tag are not shown in the tables of attribute value syntax for each element, but are around attribute values in examples in the text, so that the pieces of code shown are correct.

一般に, 継承されたり, 自動で計算されたりする属性を指定しなかった場合の効果がどうなるか, 検証する仕組みがMathMLにはないことに注意して下さい. inherited(訳注:"継承")またはautomatic(訳注:"自動")という言葉を明確に示すことは, 効果がなく一般に認められません. さらに, mstyle要素(3.3.4 書式の変更 <mstyle>)は, その子要素の表示属性の既定値を変更するために使うことができます.

Note that, in general, there is no mechanism in MathML to simulate the effect of not specifying attributes which are inherited or automatic. Giving the words inherited or automatic explicitly will not work, and is not generally allowed. Furthermore, the mstyle element (3.3.4 Style Change <mstyle>) can even be used to change the default values of presentation attributes for its children.

これらの既定値は, 属性が提供されていないときのMathMLソフトウェアの挙動についても述べていることに注意して下さい. それらの挙動は, ときどきDTDに基づいた仕様書によって委任されているXML処理プログラムによって埋め込まれる値を明確にはしていません.

Note also that these defaults describe the behavior of MathML applications when an attribute is not supplied; they do not indicate a value that will be filled in by an XML parser, as is sometimes mandated by DTD-based specifications.

一般に, 文書全体の特性, または少なくとも大きな文書のその節の特性であると思われている, 数々のMathML描画の特性があります. 例としては, mathsize(数学のフォントの大きさ, 3.2.2 素子要素に共通の数学書式属性参照), または積分や総和といった演算子の添え字に設定された挙動(例えば, movablelimitsまたはdisplaystyle), もしくは行の途中での式の改行(例えば, linebreakstyle)があるでしょう. そのような属性は, 3.2 素子要素の中の様々な要素で見られます. これらの値は, 要素を含んでいる範囲の何かから継承されると思われるでしょう. ちょうど上で継承自動の場合のMathML属性の既定値の設定について書いたとおりです. MathMLを描画する際の挙動についての汎用的な既定値を設定する第三者の資源である, MathML演算子辞書があります. 既定値の例はB. 演算子辞書で提供しています. このことは3. 演算子辞書でも論じられており, 例は3. 辞書に基づく属性で示しています.

In general, there are a number of properties of MathML rendering that may be thought of as overall properties of a document, or at least of sections of a large document. Examples might be mathsize (the math font size: see 3.2.2 Mathematics style attributes common to token elements), or the behavior in setting limits on operators such as integrals or sums (e.g., movablelimits or displaystyle), or upon breaking formulas over lines (e.g. linebreakstyle); for such attributes see several elements in 3.2 Token Elements. These may be thought to be inherited from some such containing scope. Just above we have mentioned the setting of default values of MathML attributes as inherited or automatic; there is a third source of global default values for behavior in rendering MathML, a MathML operator dictionary. A default example is provided in B. Operator Dictionary. This is also discussed in The operator dictionary and examples are given in Dictionary-based attributes.

2.1.6 全てのMathML要素で利用される属性
Attributes Shared by all MathML Elements

それぞれの要素に対して特別に説明されている属性に加え, 次の表の属性が全ての要素で利用できます. xml:langといたXML名前空間の属性や, 通常は無視されるMathMLとは別の名前空間の属性も利用できます.

In addition to the attributes described specifically for each element, the attributes in the following table are allowed on every MathML element. Also allowed are attributes from the xml namespace, such as xml:lang, and attributes from namespaces other than MathML, which are ignored by default.


id id 無し
リンク, 相互参照, 並列のマークアップに対応するために, 要素と結び付けられた唯一の識別子を確立します. xref5.2.9 並列のマークアップを参照して下さい.
Establishes a unique identifier associated with the element to support linking, cross-references and parallel markup. See xref and 5.2.9 Parallel Markup.
xref 参照先のid
文書の中の他の要素を参照します. id5.2.9 並列のマークアップを参照して下さい.
References another element within the document. See id and 5.2.9 Parallel Markup.
class 文字列
要素を[CSS21]を利用して書式の種類の集合と結び付けます. MathMLとCSSの相互作用の議論については, 6.5 MathMLと一緒にCSSを利用するを参照して下さい.
Associates the element with a set of style classes for use with [CSS21]. See 6.5 Using CSS with MathML for discussion of the interaction of MathML and CSS.
style 文字列
書式情報を[CSS21]を利用して要素と結び付けます. MathMLとCSSの相互作用の議論については, 6.5 MathMLと一緒にCSSを利用するを参照して下さい.
Associates style information with the element for use with [CSS21]. See 6.5 Using CSS with MathML for discussion of the interaction of MathML and CSS.
href URI 無し
Can be used to establish the element as a hyperlink to the specified URI.

全てのMathMLプレゼンテーション要素は, 意図を指定するのを手助けするintent属性とarg属性を受け入れます. これらの属性は, 5.1 intent属性でより詳細に説明されています.

All MathML presentation elements accept intent and arg attributes to support specifying intent. These are more fully described in 5.1 The intent attribute.


intent intentの式
intent expression
intent属性は, 5.1 intent属性でより詳細に説明されています. この属性は, プレゼンテーション要素において, 式の意図している意味についての情報を示したり, 主に音声や点字のアクセシビリティに配慮した表現を導入したりするのに使用されるでしょう.
The intent attribute is more fully described in 5.1 The intent attribute. It may be used on presentation elements to give information about the intended meaning of the expression, mainly for guiding audio or braille accessible renderings.
arg 名前
arg属性は, 5.1 intent属性でより詳細に説明されています. この属性は, 祖先要素のintentの式から参照する要素に名前を付けるのに使用されるでしょう.
The arg attribute is more fully described in 5.1 The intent attribute. It may be used to name an element to be referenced from an intent expression on an ancestor element.

また, ほとんどのプレゼンテーション素子要素で利用できるMathML属性の一覧については, 3.2.2 素子要素に共通の数学書式属性も参照して下さい.

See also 3.2.2 Mathematics style attributes common to token elements for a list of MathML attributes which can be used on most presentation token elements.

属性otherは, 他の名前空間の属性の利用が望ましいことから非推奨(D.3 指定されていないデータのための属性)となっています.

The attribute other is deprecated (D.3 Attributes for unspecified data) in favor of the use of attributes from other namespaces.


other 文字列
非推奨, ただしMathML1.0では利用されていました.
DEPRECATED but in MathML 1.0.

2.1.7 入力された空白を縮小する
Collapsing Whitespace in Input

MathMLにおいて, 空白はXMLのように単純な空白, タブ, 改行, 復帰, すなわち, それぞれ16進数のユニコードの文字コードU+0020, U+0009, U+000A, U+000Dの文字を意味します. [XML]の第3節の空白の説明も参照して下さい.

In MathML, as in XML, whitespace means simple spaces, tabs, newlines, or carriage returns, i.e., characters with hexadecimal Unicode codes U+0020, U+0009, U+000A, or U+000D, respectively; see also the discussion of whitespace in Section 2.3 of [XML].

MathMLは素子要素の外にある空白を無視します. 空白ではない文字はそこでは認められません. 素子要素の中の空白は, <cs>を除いて, 次のように標準化されます. 内容の最初と最後の全ての空白は取り除かれ, 要素の内容の途中の空白は正当に縮小され, すなわち, 1文字以上の空白の文字列は, 1文字の空白(U+0020, よく空白文字と呼ばれる)に置き換えられます.

MathML ignores whitespace occurring outside token elements. Non-whitespace characters are not allowed there. Whitespace occurring within the content of token elements, except for <cs>, is normalized as follows. All whitespace at the beginning and end of the content is removed, and whitespace internal to content of the element is collapsed canonically, i.e., each sequence of 1 or more whitespace characters is replaced with one space character (U+0020, sometimes called a blank character).

例えば, <mo> ( </mo><mo>(</mo>に等しく, また,

For example, <mo> ( </mo> is equivalent to <mo>(</mo>, and

Theorem 1:

は, <mtext>Theorem 1:</mtext>または<mtext>Theorem&#x20;1:</mtext>に等しいです.

is equivalent to <mtext>Theorem 1:</mtext> or <mtext>Theorem&#x20;1:</mtext>.

素子の最初と最後の空白文字をコード化したり, または単独の空白でない空白文字列をコード化したりしようとする場合, それらを無視させないには, 改行しない空白U+00A0(またはnbsp), もしくは取り除かれることのない他の記述されない文字を使用しなければなりません. 例えば, 上のmtext要素の利用と下の例を比べるとします.

Authors wishing to encode white space characters at the start or end of the content of a token, or in sequences other than a single space, without having them ignored, must use non-breaking space U+00A0 (or nbsp) or other non-marking characters that are not trimmed. For example, compare the above use of an mtext element with

&#x00A0;<!--nbsp-->Theorem &#x00A0;<!--nbsp-->1:
 Theorem  1:

最初の例は, Theoremの前に何も無く, Theorem1:の間にユニコードの空白文字があり, 1:の後に何も無いように描画されます. 2番目の例では, 単独の空白がTheoremの前に描画され, 2つの空白である, ユニコードの空白文字1つとユニコードの改行しない空白文字1つが1:の前に描画され, 1:の後に何も描画されません.

When the first example is rendered, there is nothing before Theorem, one Unicode space character between Theorem and 1:, and nothing after 1:. In the second example, a single space character is to be rendered before Theorem; two spaces, one a Unicode space character and one a Unicode no-break space character, are to be rendered before 1:; and there is nothing after the 1:.

xml:space属性の値はこの状況では関係ないことに注意して下さい. なぜなら, XML処理プログラムは素子の中の空白をMathML処理プログラムに渡すためです. 空白を取り除いたり, 縮小したりすることは, MathMLの処理で必要とされています.

Note that the value of the xml:space attribute is not relevant in this situation since XML processors pass whitespace in tokens to a MathML processor; it is the requirements of MathML processing which specify that whitespace is trimmed and collapsed.

素子要素mi, mn, mo, ms, mtext, ci, cn, cs, csymbol, annotationの中身の外側の空白については, 空白の実体のみを含むことができるmtextではなく, mspace要素が使われるべきです.

For whitespace occurring outside the content of the token elements mi, mn, mo, ms, mtext, ci, cn, cs, csymbol and annotation, an mspace element should be used, as opposed to an mtext element containing only whitespace entities.

2.2 一番上の<math>要素
The Top-Level <math> Element

MathMLは, 唯一の一番上のルート要素であるmath要素を指定しています. math要素は, 文書の中のMathMLマークアップの各要素を包み込みます. 全ての他のMathMLの内容は, mathの中に含まれなければなりません. 言い換えれば, 全ての有効なMathMLの式は外側の<math>タグで包まれています. math要素はいつもMathMLの式の一番外側の要素です. あるmath要素が他のmath要素を含んでいたらエラーになります. これらの考慮すべき点は, 切り取り貼り付けといった操作のように, ソフトウェア間で式が受け渡されるときにも適用されます. 6.3 MathMLを受け渡すを参照して下さい.

MathML specifies a single top-level or root math element, which encapsulates each instance of MathML markup within a document. All other MathML content must be contained in a math element; in other words, every valid MathML expression is wrapped in outer <math> tags. The math element must always be the outermost element in a MathML expression; it is an error for one math element to contain another. These considerations also apply when sub-expressions are passed between applications, such as for cut-and-paste operations; see 6.3 Transferring MathML.

math要素は, 任意の数の子要素を含むことができます. それらの要素は, 通常mrow要素に含まれているかのように描画されます.

The math element can contain an arbitrary number of child elements. They render by default as if they were contained in an mrow element.

2.2.1 属性

math要素は, 2.1.6 全てのMathML要素で利用される属性で指定した共通の属性を含め, 3.3.4 書式の変更 <mstyle>で設定できる全ての属性を持ちます. 特に, 文章全体の方向を設定するdir属性を持っています. math要素は, 普通, 方向を指定するのに最も利用しやすい場所にあります(詳しい議論については3.1.5 方向参照). math要素におけるdir属性の既定値はltrであることに注意して下さい(ただし, dir属性を持つことができる全ての他の要素に継承される場合にです). これは, 方向の概念を持たない以前のMathML2.0との互換性を提供するためです. また, mstyleや他のプレゼンテーション要素と同じ意味合いでmathbackground属性を持ちます. この属性は, 属性の既定値を指定するというより, むしろ全体の描画領域の背景色を指定します(3.1.9 プレゼンテーション要素に共通の数学書式属性参照).

The math element accepts any of the attributes that can be set on 3.3.4 Style Change <mstyle>, including the common attributes specified in 2.1.6 Attributes Shared by all MathML Elements. In particular, it accepts the dir attribute for setting the overall directionality; the math element is usually the most useful place to specify the directionality (see 3.1.5 Directionality for further discussion). Note that the dir attribute defaults to ltr on the math element (but inherits on all other elements which accept the dir attribute); this provides for backward compatibility with MathML 2.0 which had no notion of directionality. Also, it accepts the mathbackground attribute in the same sense as mstyle and other presentation elements to set the background color of the bounding box, rather than specifying a default for the attribute (see 3.1.9 Mathematics attributes common to presentation elements).

これらの属性に加えて, math要素は次の属性を持ちます.

In addition to those attributes, the math element accepts:


display "block" | "inline" inline
囲っているMathMLの式が, 縦に分けられたblock(領域)(ディスプレイ形式), または隣接した文章に揃えられるinline(インライン形式)のどちらで描画されるべきか指定します(TEXの一般的な呼び方にならってディスプレイ形式, インライン形式と訳しています). display=blockの場合, displaystyletrueで初期化されます. 一方, display=inlineの場合, displaystylefalseで初期化されます. どちらの場合でも, scriptlevelは0で初期化されます. (3.1.6 displaystyleとscriptlevel参照). さらに, math要素が大きな文書の中に埋め込まれた場合, blockのmath要素は文書の形式にふさわしい領域要素として(典型的に新しい縦の領域として)扱われるべきで, 一方, inlineのmath要素は行の一部として(典型的に実際に標準の文書の中の一連の言葉であるかのように)扱われるべきです. 特に, この属性は間隔の取り方や改行に影響します. 例えば, inlineのmath要素の中に空白や改行を挿入したり, 何らかの直接の区切りを挿入したりすべきではありません. display属性が無い場合, 描画プログラムが文脈に沿って適切な値に初期化するのは自由です.
specifies whether the enclosed MathML expression should be rendered as a separate vertical block (in display style) or inline, aligned with adjacent text. When display=block, displaystyle is initialized to true, whereas when display=inline, displaystyle is initialized to false; in both cases scriptlevel is initialized to 0 (see 3.1.6 Displaystyle and Scriptlevel). Moreover, when the math element is embedded in a larger document, a block math element should be treated as a block element as appropriate for the document type (typically as a new vertical block), whereas an inline math element should be treated as inline (typically exactly as if it were a sequence of words in normal text). In particular, this applies to spacing and linebreaking: for instance, there should not be spaces or line breaks inserted between inline math and any immediately following punctuation. When the display attribute is missing, a rendering agent is free to initialize as appropriate to the context.
maxwidth 長さ
available width
改行のために使用する最大の幅を指定します. 既定値は, 周囲を囲っている環境で利用可能な最大の幅です. この属性値を決められない場合, 描画ソフトウェアは描画できる無限の幅であると仮定すべきです.
specifies the maximum width to be used for linebreaking. The default is the maximum width available in the surrounding environment. If that value cannot be determined, the renderer should assume an infinite rendering width.
overflow "linebreak" | "scroll" | "elide" | "truncate" | "scale" linebreak
式が利用可能な幅に収まるには長過ぎる状況で, 望ましい扱い方を指定します. 後の議論を参照して下さい.
specifies the preferred handing in cases where an expression is too long to fit in the allowed width. See the discussion below.
altimg URI 無し
埋め込まれたMathMLに対応していない利用者のプログラムの代替手段として, 表示する画像を参照するURIを提供します.
provides a URI referring to an image to display as a fall-back for user agents that do not support embedded MathML.
altimg-width 長さ
width of altimg
画像を拡大・縮小させることが必要な場合のaltimgを表示する幅を指定します. altimg-heightを参照して下さい.
specifies the width to display altimg, scaling the image if necessary; see altimg-height.
altimg-height 長さ
height of altimg
画像を拡大・縮小させることが必要な場合のaltimgを表示する高さを指定します. 属性altimg-widthaltimg-heightの一方だけが与えられた場合, 画像はアスペクト比を保ったまま, 拡大・縮小されます. 属性がどちらも与えられない場合, 画像は元の大きさのまま表示されるべきです.
specifies the height to display altimg, scaling the image if necessary; if only one of the attributes altimg-width and altimg-height are given, the scaling should preserve the image's aspect ratio; if neither attribute is given, the image should be shown at its natural size.
altimg-valign 長さ | "top" | "middle" | "bottom"
隣接する行の中の要素に対する縦方向の位置揃えを指定します. altimg-valignの正の値は画像の下端を現在の欧文ベースライン(訳注:欧文書体で水平の基準線で大文字の下端の位置)から上にずらし, 負の値は下にずらします. 値"top"は画像の上端を隣接する行の中の要素の上端に合わせます. "center"は画像の中心を隣接する行の中の要素の中心に合わせます. "bottom"は画像の下端を隣接する行の中の要素の下端(必ずしも欧文ベースラインでなくて良い)に合わせます. この属性は, display=inlineの場合のみ効果があります. 既定値では, 画像の下端が欧文ベースラインに揃うことになります.
specifies the vertical alignment of the image with respect to adjacent inline material. A positive value of altimg-valign shifts the bottom of the image above the current baseline, while a negative value lowers it. The keyword "top" aligns the top of the image with the top of adjacent inline material; "center" aligns the middle of the image to the middle of adjacent material; "bottom" aligns the bottom of the image to the bottom of adjacent material (not necessarily the baseline). This attribute only has effect when display=inline. By default, the bottom of the image aligns to the baseline.
alttext 文字列
埋め込まれたMathMLまたは画像に対応していない利用者のプログラムの代替手段として, 代替の文字列を提供します.
provides a textual alternative as a fall-back for user agents that do not support embedded MathML or images.
cdgroup URI 無し
このmath要素の中のcsymbol, annotation, annotation-xml要素のOpenMathコンテント辞書の位置の基となるCDの目録として働くCDグループファイルを指定します. 4.2.3 コンテントマークアップの記号 <csymbol>を参照して下さい. cdgroup属性が何も明確に指定されていない場合, このmath要素に埋め込まれた文書形式は, 基となるCDを決める方法を提供してもよいです. そうでない場合, システムは基となるCDを決めなければなりません. 特定の情報がない場合, http://www.openmath.org/cdcsymbol, annotation, annotation-xml要素の基となるCDと仮定されます. この属性は, OpenMath協会が管理している標準のCDの集合を基としたCDです.
specifies a CD group file that acts as a catalogue of CD bases for locating OpenMath content dictionaries of csymbol, annotation, and annotation-xml elements in this math element; see 4.2.3 Content Symbols <csymbol>. When no cdgroup attribute is explicitly specified, the document format embedding this math element may provide a method for determining CD bases. Otherwise the system must determine a CD base; in the absence of specific information http://www.openmath.org/cd is assumed as the CD base for all csymbol, annotation, and annotation-xml elements. This is the CD base for the collection of standard CDs maintained by the OpenMath Society.

大きさの調整が不可能または失敗した場合(例えば, 式が利用可能な幅に収まるのに長過ぎる場合), overflow属性は, 描画ソフトウェアに処理する方法を提案するのに提供されます. 利用可能な値は次のとおりです.

In cases where size negotiation is not possible or fails (for example in the case of an expression that is too long to fit in the allowed width), the overflow attribute is provided to suggest a processing method to the renderer. Allowed values are:

"linebreak" 式は複数の行に分割されるでしょう. より詳しい議論は3.1.7 式の改行を参照して下さい.
TThe expression will be broken across several lines. See 3.1.7 Linebreaking of Expressions for further discussion.
"scroll" 数式の大きな完全な表示の一部を見せるウィンドウを提供します. 見せる部分の位置を別の場所に動かすことができるように, 必要なら水平または鉛直のスクロールバーがウィンドウに加えられます.
The window provides a viewport into the larger complete display of the mathematical expression. Horizontal or vertical scroll bars are added to the window as necessary to allow the viewport to be moved to a different position.
"elide" 残った部分がウィンドウに収まるのに必要なだけ, 一部を取り除いて表示を省略します. 例えば, 大きい多項式は, 最初と最後の項とその間に+ ... +を付けて表示されるかもしれません. 進歩した描画ソフトウェアは, 省略された範囲を拡大・縮小する機能を提供するかもしれません.
The display is abbreviated by removing enough of it so that the remainder fits into the window. For example, a large polynomial might have the first and last terms displayed with + ... + between them. Advanced renderers may provide a facility to zoom in on elided areas.
"truncate" 右と下の端を切り詰めることで表示を省略します. 見る人に切り詰めたことをそれとなく示すことが推奨されます.
The display is abbreviated by simply truncating it at the right and bottom borders. It is recommended that some indication of truncation is made to the viewer.
"scale" 数式を表示するのに使われているフォントを, ウィンドウに式全体が収まるように選びます. フォントの変更は式が大き過ぎる場合しか起こりません. 必要以上にウィンドウが大きい場合, 式は標準の大きさで大きなウィンドウの中に描画されます.
The fonts used to display the mathematical expression are chosen so that the full expression fits in the window. Note that this only happens if the expression is too large. In the case of a window larger than necessary, the expression is shown at its normal size within the larger window.

3. プレゼンテーションマークアップ
Presentation Markup

3.1 導入

この章は, 数学表記の配置構造を説明するために利用可能な, MathMLのプレゼンテーション要素についての仕様を定めています.

This chapter specifies the presentation elements of MathML, which can be used to describe the layout structure of mathematical notation.

ほとんどのプレゼンテーションマークアップは, [MathMLコア]に含まれます. その仕様書は, ウェブブラウザで表示する際の, コアの一部である要素や属性を表示する, 正確な方法について助言するものです. ウェブブラウザ以外では, MathMLプレゼンテーション要素は, 媒体に依存した描画と個別の書式の選択を認めるために, 描画の特定の方法を提案するのみ(すなわち, 必要としない)です. ブラウザに基づかない描画ソフトウェアは, その描画方法が理解できる限り, 独自の配置の決まりを使用するのは自由です.

Most of Presentation Markup is included in [MathML-Core]. That specification should be consulted for the precise details of displaying the elements and attributes that are part of core when displayed in web browsers. Outside of web browsers, MathML presentation elements only suggest (i.e. do not require) specific ways of rendering in order to allow for medium-dependent rendering and for individual preferences of style. Non browser-based renderers are free to use their own layout rules as long as the renderings are intelligible.

プレゼンテーション要素で使用される名前は, それらの視覚的な配置を連想させます. しかしながら, 数学表記は, 新しい概念が開発されるたびに, 再利用されて来た長い歴史を持ちます. そのため, mfracといった要素は, 実際のところ分数でなくてもよく, intent属性が音声表現の情報を提供するのに使われるべきです.

The names used for presentation elements are suggestive of their visual layout. However, mathematical notation has a long history of being reused as new concepts are developed. Because of this, an element such as mfrac may not actually be a fraction and the intent attribute should be used to provide information for auditory renderings.

この章は, 全てのプレゼンテーション要素と属性を, 利用方法を明確にするであろう例と一緒に説明しています.

This chapter describes all of the presentation elements and attributes of MathML along with examples that might clarify usage.

3.1.1 プレゼンテーションMathMLの構造
Presentation MathML Structure

プレゼンテーション要素は, 題名, 節, 段落が人間に近い水準で文章の構造をうまく再現したのと概ね同じ方法で, 数学表記の構文構造を表現するためのものです. このため, 識別子と演算子から成る単独の行はよく, 単独のmrow要素ではなく, 幾重にも入れ子になったmrow要素として表現されるでしょう. 例えば, x+a/bは典型的に次のように表されます.

The presentation elements are meant to express the syntactic structure of mathematical notation in much the same way as titles, sections, and paragraphs capture the higher-level syntactic structure of a textual document. Because of this, a single row of identifiers and operators will often be represented by multiple nested mrow elements rather than a single mrow. For example, x+a/b typically is represented as:

  <mi> x </mi>
  <mo> + </mo>
    <mi> a </mi>
    <mo> / </mo>
    <mi> b </mi>
x + a / b

同様に, 上付き添え字は, ただ前の文字に続くというよりは, 基を構成している式全体にくっつけられます. この構造は, 特に画面の幅といった描画環境の詳細を文章の著者が前もって分からない場合に, 数学のより良質な描画を可能にします. また, この構造は, 表現された数学構造の自動解釈を大いに楽にします.

Similarly, superscripts are attached to the full expression constituting their base rather than to the just preceding character. This structure permits better-quality rendering of mathematics, especially when details of the rendering environment, such as display widths, are not known ahead of time to the document author. It also greatly eases automatic interpretation of the represented mathematical structures.

ある特定の文字は, 伝統的な表現において他の記号と同じように描画されたり, 表示されないように表現されたりする識別子や演算子に名前を付けるのに使用されます. 例えば, 文字U+2146, U+2147, U+2148は, それぞれ微分記号d, 自然対数の底e, 虚数iを表し, 単純な変数として使用される同じ文字とは意味的に異なります. 同様に, 文字U+2061, U+2062, U+2063, U+2064は, 関数の適用, 見えない掛ける, 見えない区切り記号, 見えないプラスを表します. それらは, 通常表示されませんが, 視覚的な間隔や改行に影響してもよい重要な情報を表現しており, 異なる音声表現を持ってもよいです. したがって, 著者は, 適用できる場合はいつでも, それらの文字(または, 対応する実体)を使用すべきです.

Certain characters are used to name identifiers or operators that in traditional notation render the same as other symbols or are rendered invisibly. For example, the characters U+2146, U+2147 and U+2148 represent differential d, exponential e and imaginary i, respectively and are semantically distinct from the same letters used as simple variables. Likewise, the characters U+2061, U+2062, U+2063 and U+2064 represent function application, invisible times, invisible comma and invisible plus . These usually render invisibly but represent significant information that may influence visual spacing and linebreaking, and may have distinct spoken renderings. Accordingly, authors should use these characters (or corresponding entities) wherever applicable.


The complete list of MathML entities is described in [Entities].

3.1.2 この章で使用する用語
Terminology Used In This Chapter

プレゼンテーション要素は2つの種類に分けられます. 素子要素は個々の記号, 名前, 数字, 番号等を表します. 配置要素は部分部分から式を構築し, 要素のみを内容として持つことができます. 配置要素はさらに一般的な配置要素, 添え字の配置要素, 表のような配置要素, 初等数学の配置要素に分けられます. また, これらの配置要素と共にだけ用いられる若干の空要素もあります.

The presentation elements are divided into two classes. Token elements represent individual symbols, names, numbers, labels, etc. Layout schemata build expressions out of parts and can have only elements as content. These are subdivided into General Layout, Script and Limit, Tabular Math and Elementary Math schemata. There are also a few empty elements used only in conjunction with certain layout schemata.

数式の中の個々の記号はMathML素子要素(例えば, <mn>24</mn>)として表されるべきです. 主要なMathML素子要素の種類は, 識別子(mi, 例えば, 変数や関数名), 数字(mn), 演算子(mo, かっこといった囲い文字やコンマといった区切り文字を含む)です. また, 数学の意味より美しさを優先するための, 文章や空白を表すのに使用される素子要素や, 数式処理システムとの互換性のために文字列を表す要素もあります.

All individual symbols in a mathematical expression should be represented by MathML token elements (e.g., <mn>24</mn>). The primary MathML token element types are identifiers (mi, e.g. variables or function names), numbers (mn), and operators (mo, including fences, such as parentheses, and separators, such as commas). There are also token elements used to represent text or whitespace that has more aesthetic than mathematical significance and other elements representing string literals for compatibility with computer algebra systems.

配置要素は, 分数や添え字付きの式といった大きい式を, 小さい式から構築する方法を指定しています. 配置要素の子要素は, 配置要素の引数とも呼ばれます. 上記の定義の結果として, 配置要素の中身は, 厳密に0個以上の引数となる要素が連なったものから構成されます.

The layout schemata specify the way in which sub-expressions are built into larger expressions such as fraction and scripted expressions. Layout schemata attach special meaning to the number and/or positions of their children. A child of a layout schema is also called an argument of that element. As a consequence of the above definitions, the content of a layout schema consists exactly of a sequence of zero or more elements that are its arguments.

3.1.3 必要な引数
Required Arguments

ここで説明する要素の多くは, 特定の数(たいてい1個, または2個, または3個)の引数を必要とします. 後で示す要素の構文の詳細な説明において, 必要な引数の数は, 暗黙のうちに様々な位置にある引数に対して与えられた名前によって示唆されています. 要素の中にはわずかに, 個々の要素に応じて説明される引数の数や型といった追加の決まりを持っているものもあります。例えば, 要素の中には0個以上の一連の引数を受け入れるものもあり, そのことは, それらの要素に引数が結局無くてもよいことを認めています.

Many of the elements described herein require a specific number of arguments (always 1, 2, or 3). In the detailed descriptions of element syntax given below, the number of required arguments is implicitly indicated by giving names for the arguments at various positions. A few elements have additional requirements on the number or type of arguments, which are described with the individual element. For example, some elements accept sequences of zero or more arguments — that is, they are allowed to occur with no arguments at all.

描画される空白をコード化しているMathML要素は, それらが現れた場所の要素の引数と見なされることに注意して下さい. そのような空白に似た要素の適切な利用に関する議論については, 3.2.7 空白 <mspace/>を参照して下さい.

Note that MathML elements encoding rendered space do count as arguments of the elements in which they appear. See 3.2.7 Space <mspace/> for a discussion of the proper use of such space-like elements. 省略された<mrow>
Inferred <mrow>s

次の一覧で示す 1* の引数を必要としている要素(msqrt, mstyle, merror, mpadded, mphantom, menclose, mtd, mscarry, math)は, 概念上は単独の引数を受け入れますが, 実際のところ任意の数の子要素を受け入れます. 子要素の数が0個の場合, もしくは1個より大きい場合, それらの要素は, それらの中身を全ての子要素から形作られる単独の省略されたmrowとして扱い, そのmrowを引数として扱います.

The elements listed in the following table as requiring 1* argument (msqrt, mstyle, merror, mpadded, mphantom, menclose, mtd, mscarry, and math) conceptually accept a single argument, but actually accept any number of children. If the number of children is 0 or is more than 1, they treat their contents as a single inferred mrow formed from all their children, and treat this mrow as the argument.


For example,

  <mo> - </mo>
  <mn> 1 </mn>
- 1


is treated as if it were

    <mo> - </mo>
    <mn> 1 </mn>
- 1

この機能は, MathMLのデータが, その機能がなければ必要となるたくさんのmrow要素を含まなくてもよいように(著者が同様に必要となるたくさんのmrow要素を省略してもよいように)します.

This feature allows MathML data not to contain (and its authors to leave out) many mrow elements that would otherwise be necessary. 必要な引数の表
Table of argument requirements

便利なように, それぞれの要素の引数がいくつ必要かと, 個々の引数の役割が確立している場合の役割について, 表で示します. 1* という引数の数は上で述べた省略されたmrowを意図しています. math要素はプレゼンテーション要素ではありませんが, 完全に網羅できるように下の表に挙げています.

For convenience, here is a table of each element's argument count requirements and the roles of individual arguments when these are distinguished. An argument count of 1* indicates an inferred mrow as described above. Although the math element is not a presentation element, it is listed below for completeness.

Required argument count
Argument roles (when these differ by position)
mrow 0以上
0 or more
mfrac 2 分子 分母
numerator denominator
msqrt 1*
mroot 2 基となる式 指数
base index
mstyle 1*
merror 1*
mpadded 1*
mphantom 1*
mfenced 0以上
0 or more
menclose 1*
msub 2 基となる式 下付き添え字
base subscript
msup 2 基となる式 上付き添え字
base superscript
msubsup 3 基となる式 下付き添え字 上付き添え字
base subscript superscript
munder 2 基となる式 下側添え字
base underscript
mover 2 基となる式 上側添え字
base overscript
munderover 3 基となる式 下側添え字 上側添え字
base underscript overscript
mmultiscripts 1以上
1 or more
基となる式 (下付き添え字 上付き添え字)* [<mprescripts/> (前置の下付き添え字 前置の上付き添え字)*]
base (subscript superscript)* [<mprescripts/> (presubscript presuperscript)*]
mtable 0以上の行
0 or more rows
0 or more mtr or mlabeledtr elements
mlabeledtr 1以上
1 or more
a label and 0 or more mtd elements
mtr 0以上
0 or more
0 or more mtd elements
mtd 1*
mstack 0以上
0 or more
mlongdiv 3以上
3 or more
除数 被除数 (msrow | msgroup | mscarries | msline)*
divisor result dividend (msrow | msgroup | mscarries | msline)*
msgroup 0以上
0 or more
msrow 0以上
0 or more
mscarries 0以上
0 or more
mscarry 1*
maction 1以上
1 or more
depend on actiontype attribute
math 1*

3.1.4 特別な挙動の要素
Elements with Special Behaviors

ある特定のMathMLプレゼンテーション要素は, ある文脈の中で特別な挙動を示します. そのような特別な挙動については, 後で述べる詳細な要素の説明で論じます. しかしながら, 便利なように特別な挙動の大変重要な種類について, いくつかここで挙げます.

Certain MathML presentation elements exhibit special behaviors in certain contexts. Such special behaviors are discussed in the detailed element descriptions below. However, for convenience, some of the most important classes of special behavior are listed here.

ある特定の要素は空白のようだと見なされます. これらの要素は3.2.7 空白 <mspace/>で定義されています. この定義は, mo要素(3.2.5 演算子, かっこ, 区切り, アクセント <mo>)の提案されている描画の決まりに影響を与えます.

Certain elements are considered space-like; these are defined in 3.2.7 Space <mspace/>. This definition affects some of the suggested rendering rules for mo elements (3.2.5 Operator, Fence, Separator or Accent <mo>).

ある特定の要素, 例えばmsupは, その最初の引数である演算子を装飾することができます. これらの要素は, 3.2.5 演算子, かっこ, 区切り, アクセント <mo>の中で一覧にされています. その節は, 正確に装飾された演算子を定義し, それらが引き伸ばされた演算子に対する, 提案された描画の決まりにどのように影響するか説明しています.

Certain elements, e.g. msup, are able to embellish operators that are their first argument. These elements are listed in 3.2.5 Operator, Fence, Separator or Accent <mo>, which precisely defines an embellished operator and explains how this affects the suggested rendering rules for stretchy operators.

3.1.5 方向

ほとんどの読者に知られた表記において, 全体的な配置と文章のような記号は, 両方とも左から右(LTR)に整えられています. しかし, 導入部分で示唆したように, ヘブライ語で書かれた数学, またはモロッコやペルシャといった地域の数学は全体の配置は変わりませんが, (たいていヘブライ語またはアラビア語の)埋め込まれた記号は右から左(RTL)で書かれています. さらに, アラビア語を話す世界のほとんどは, 表記は完全に右から左(RTL)で整えられています. そのため, 上付き添え字は上に付いていますが, 基の部分の右側ではなく左側に付いています.

In the notations familiar to most readers, both the overall layout and the textual symbols are arranged from left to right (LTR). Yet, as alluded to in the introduction, mathematics written in Hebrew or in locales such as Morocco or Persia, the overall layout is used unchanged, but the embedded symbols (often Hebrew or Arabic) are written right to left (RTL). Moreover, in most of the Arabic speaking world, the notation is arranged entirely RTL; thus a superscript is still raised, but it follows the base on the left rather than the right.

そのため, MathML 3.0は, 2つの別々の方向, 素子要素の中の文章や記号の方向と配置要素で表現される数式全体の方向が存在することを認めています. この2つの側面について次で論じます.

MathML 3.0 therefore recognizes two distinct directionalities: the directionality of the text and symbols within token elements and the overall directionality represented by Layout Schemata. These two facets are discussed below.


おそらく, ここに縦方向の言語に対する若干の議論を加える必要があります(なお, 現在, それらへの対応は行われておりません).

Probably need to add a little discussion of vertical languages here (and their current lack of support) 数式全体の方向
Overall Directionality of Mathematics Formulas

数式に対する全体の方向, 基本的に配置要素の方向は, 全体を囲っているmath要素(2.2 一番上の<math>要素参照)のdir属性によって指定されます. 既定値はltrです. dir=rtlが用いられる場合, 配置はヨーロッパの慣例的な配置に対して単純に鏡のような形になります. つまり, 字下げ等は変わりませんが, 配置の向きは右から左になります.

The overall directionality for a formula, basically the direction of the Layout Schemata, is specified by the dir attribute on the containing math element (see 2.2 The Top-Level <math> Element). The default is ltr. When dir=rtl is used, the layout is simply the mirror image of the conventional European layout. That is, shifts up or down are unchanged, but the progression in laying out is from right to left.

例えば, 右から左(RTL)の配置においては, 上付き添え字と下付き添え字は, 基となる式の左に現れます. 根号は右に, 基となる式の左端まで続く上の横線を伴って現れます. 方向に依存する要素に対する配置の詳細については, 要素の説明で述べます. その説明の中で, 前に来ると後ろに来るというの用語は, 方向に依存して用いられる式の横側を指定するのに使われます. 前に来るは左から右(LTR)では左を意味しますが, 右から左(RTL)では右を意味します. 他の場合の左と右という用語は, 左と右を意味すると想定して問題ないでしょう.

For example, in a RTL layout, sub- and superscripts appear to the left of the base; the surd for a root appears at the right, with the bar continuing over the base to the left. The layout details for elements whose behavior depends on directionality are given in the discussion of the element. In those discussions, the terms leading and trailing are used to specify a side of an object when which side to use depends on the directionality; i.e. leading means left in LTR but right in RTL. The terms left and right may otherwise be safely assumed to mean left and right.

全体の方向は通常mathによって設定されますが, mrow要素またはmstyle要素のdir属性を利用して個々の式の部分について切り替えてもよいです. 指定されない限り, 全ての要素はそれらを囲っている要素の方向を継承します.

The overall directionality is usually set on the math, but may also be switched for an individual subexpression by using the dir attribute on mrow or mstyle elements. When not specified, all elements inherit the directionality of their container. 素子要素における双方向の配置
Bidirectional Layout in Token Elements

文字の方向は, 文字を含むことができるMatthML要素(mtext, mo, mi, mn, ms)の方向と見なすことになり, その文字のユニコードの特性によって決められます. 全体として左から右(LTR)もしくは右から左(RTL)の文字を含んでいる素子要素は, 与えられた方向にまっすぐに表示されます. 右から左(RTL)のアラビア語と左から右(LTR)の数字が混合しているといった具合に方向が混合され複雑な状況にある場合, ユニコードの双方向のアルゴリズム[Bidi]が適用されます. このアルゴリズムは, どのように同じ方向の文字の並びを処理するか, どのように文字の並びを並べるのか(並べ直すのか)を指定します. 基となる, もしくは初期の方向は, 上で述べた全体の方向( 数式全体の方向)によって決められ, 弱い方向の文字(訳注:周囲の文字の方向に左右される文字で例えばかっこ"(")をどのように扱うのか, どのように並びを入れ子にするのかに影響します. (そのため, dir属性は素子要素でごく稀に必要となる初期の方向を指定することができます.) 素子要素と一緒に現れる何らかのmglyph要素やmalignmark要素は, 効果的に中立で並びに影響がありません.

The text directionality comes into play for the MathML token elements that can contain text (mtext, mo, mi, mn and ms) and is determined by the Unicode properties of that text. A token element containing exclusively LTR or RTL characters is displayed straightforwardly in the given direction. When a mixture of directions is involved, such as RTL Arabic and LTR numbers, the Unicode bidirectional algorithm [Bidi] should be applied. This algorithm specifies how runs of characters with the same direction are processed and how the runs are (re)ordered. The base, or initial, direction is given by the overall directionality described above ( Overall Directionality of Mathematics Formulas) and affects how weakly directional characters are treated and how runs are nested. (The dir attribute is thus allowed on token elements to specify the initial directionality that may be needed in rare cases.) Any mglyph or malignmark elements appearing within a token element are effectively neutral and have no effect on ordering.

注意すべき重要なことは, 双方向のアルゴリズムはそれぞれの素子要素の内容に独立して適用されることです. それぞれの素子要素は文字の独立した並びです.

The important thing to notice is that the bidirectional algorithm is applied independently to the contents of each token element; each token element is an independent run of characters.

ユニコードや文字列の考慮されるべき他の機能は, ‘鏡文字化’と‘字形の整形’です. ユニコード文字の中には, 右から左(RTL)の文脈の中での表現で鏡文字にできることが示されているものもあります. すなわち, その文字は, 鏡文字にされたり, 対応する文字で置換されたりしたかのように描かれます. よって, 始めのかっこ‘(’は, 右から左(RTL)では‘)’と表わされます. 逆に斜線(/ U+002F)は, 鏡文字にできるとされていません. よって, 行の中の割り算で反転させた斜線を表示させたいアラビア語の著者は, はっきりと反転した斜線(\ U+005C)か, 反転した割算の斜線(U+2215)といった代替文字を使用すべきです.

Other features of Unicode and scripts that should be respected are ‘mirroring’ and ‘glyph shaping’. Some Unicode characters are marked as being mirrored when presented in a RTL context; that is, the character is drawn as if it were mirrored or replaced by a corresponding character. Thus an opening parenthesis, ‘(’, in RTL will display as ‘)’. Conversely, the solidus (/ U+002F) is not marked as mirrored. Thus, an Arabic author that desires the slash to be reversed in an inline division should explicitly use reverse solidus (\ U+005C) or an alternative such as the mirroring DIVISION SLASH (U+2215).

加えて, アラビア語と混ぜた文字や一連の文字を一緒にした綴り文字といった, 書道のような文字は外観が変わります. これらの文字は美しさと同じように読みやすさに重要な影響があるので, 可能な限りそういった形の整形を適用することが重要です. 方向のような字形の整形は, それぞれの素子要素の内容に個別に適用されます.

Additionally, calligraphic scripts such as Arabic blend, or connect sequences of characters together, changing their appearance. As this can have a significant impact on readability, as well as aesthetics, it is important to apply such shaping if possible. Glyph shaping, like directionality, applies to each token element's contents individually.

ヘブライ文字で表現される超限数に対し, アルファベットのよく似たコードポイントではなく, MathMLではU+2135-U+2138のコードポイント(アレフ記号, べト記号, ギメル記号, ダレット記号)が使用されるべきことに注意して下さい. それらのコードポイントは, 強い(訳注:周囲の文字の方向に左右されない)左から右の文字です.

Note that for the transfinite cardinals represented by Hebrew characters, the code points U+2135-U+2138 (ALEF SYMBOL, BET SYMBOL, GIMEL SYMBOL, DALET SYMBOL) should be used in MathML, not the alphabetic look-alike code points. These code points are strong left-to-right.

3.1.6 displaystyleとscriptlevel
Displaystyle and Scriptlevel

いわゆる‘ディスプレイ形式の’式は, それら自身が行の中に現れる場合は, 典型的にインライン形式の式より大きな縦の空間を使用します. それらの式は, 隣接する行へ侵入するのではなく, 付近の文章と調和すべきです. 例えば, ディスプレイ形式の総和において, 添え字は総和記号の上下に置かれますが, それらがインライン形式で現れた場合, 添え字は下付き添え字や上付き添え字の位置に現れます. 同じような理由で, 下付き添え字または上付き添え字, 入れ子になった分数やその他の構築要素は, 典型的に数式の主要な部分より小さく表示されます. MathMLは暗黙のうちに各々のプレゼンテーション要素と, より広々とした縦の配置を適用するかどうかを表すdisplaystyleとや, 要素の中身を書く際の大きさの水準を表すscriptlevelとを結びつけます.

So-called ‘displayed’ formulas, those appearing on a line by themselves, typically make more generous use of vertical space than inline formulas, which should blend into the adjacent text without intruding into neighboring lines. For example, in a displayed summation, the limits are placed above and below the summation symbol, while when it appears inline the limits would appear in the sub- and superscript position. For similar reasons, sub- and superscripts, nested fractions and other constructs typically display in a smaller size than the main part of the formula. MathML implicitly associates with every presentation node a displaystyle and scriptlevel reflecting whether a more expansive vertical layout applies and the level of scripting in the current context.

これらの値は, math要素によってdisplay属性に従って初期化されます. それらの値は, 様々な添え字の配置要素や, 典型的にdisplaystyleをfalseに設定し, 引数の一部もしくは全部のscriptlevelを増大させるmfracmroot要素によって自動的に調整されます. (使用される特定の決まりについては, それぞれの要素の説明を参照して下さい.) また, それらの値は, mstyle要素のdisplaystyle属性やscriptlevel属性, またはmtable要素のdisplaystyle属性をはっきりと経由して設定されるでしょう. 他の全ての状況において, それらの値は要素の親要素から継承されます.

These values are initialized by the math element according to the display attribute. They are automatically adjusted by the various script and limit schemata elements, and the elements mfrac and mroot, which typically set displaystyle false and increment scriptlevel for some or all of their arguments. (See the description for each element for the specific rules used.) They also may be set explicitly via the displaystyle and scriptlevel attributes on the mstyle element or the displaystyle attribute of mtable. In all other cases, they are inherited from the node's parent.

displaystyleは式を配置するのに使われる縦の空間の量に影響します. trueの場合, ディスプレイ形式のより広々した配置が使用され, 一方, falseの場合, インライン形式のより密な配置が使用されます. displaystyleは第一に, mo要素のlargeopmovablelimitsの解釈に影響を与えます. しかしながら, より洗練された描画ソフトウェアが, より密に, もしくはより粗く描画するのに, これらの属性を利用するかは自由です.

The displaystyle affects the amount of vertical space used to lay out a formula: when true, the more spacious layout of displayed equations is used, whereas when false a more compact layout of inline formula is used. This primarily affects the interpretation of the largeop and movablelimits attributes of the mo element. However, more sophisticated renderers are free to use this attribute to render more or less compactly.

主要なscriptlevelの効果は, フォントの大きさを制御することです. 典型的に, scriptlevelが高いほどフォントの大きさが小さくなります. (視覚的でない表現ソフトウェアは, その媒体に応じた類似した方法でフォントの大きさに対応するでしょう.) scriptlevelが変更されるたびに, 自動的であっても明示的であっても, そのフォントの大きさはscriptsizemultiplierの値に, scriptlevel変更回数の乗数を掛けたものになります. ただし, scriptlevelの変更によるフォントの大きさの変更は, 読めないくらい文字が小さくなるのを防ぐために, scriptminsizeより下の値にならないようにすべきです. scriptsizemultiplierの既定値は1/2の平方根であり, 一方, scriptminsizeの既定値は8ポイントです. これらの値はmstyle要素によって変更されるかもしれません. 3.3.4 書式の変更<mstyle>を参照して下さい. mstyle要素のscriptlevel属性は, フォントの大きさを増大させることになる負の値も含め, scriptlevelの利用できる任意の値を認めていることに注意して下さい.

The main effect of scriptlevel is to control the font size. Typically, the higher the scriptlevel, the smaller the font size. (Non-visual renderers can respond to the font size in an analogous way for their medium.) Whenever the scriptlevel is changed, whether automatically or explicitly, the current font size is multiplied by the value of scriptsizemultiplier to the power of the change in scriptlevel. However, changes to the font size due to scriptlevel changes should never reduce the size below scriptminsize to prevent scripts becoming unreadably small. The default scriptsizemultiplier is approximately the square root of 1/2 whereas scriptminsize defaults to 8 points; these values may be changed on mstyle; see 3.3.4 Style Change <mstyle>. Note that the scriptlevel attribute of mstyle allows arbitrary values of scriptlevel to be obtained, including negative values which result in increased font sizes.

scriptlevelによるフォントの大きさの変更は, 要素の‘外側’から課されていると見なされるべきです. このことは, scriptlevelの効果はmfracの子要素である素子要素において, 明確なmathsize(3.2.2 素子要素に共通の数学書式属性参照)の前に適用されることを意味します. よって, mathsizeは効果的にscriptlevelを上書きできます. ただし, scriptlevelの変更はemの長さ( 長さの値の属性参照)の意味に影響する現在のフォントの大きさを変更するので, scriptlevelは効果が上書きされる場合であっても影響があります. mathsizescriptminsizeによって影響されないので, 効果を上書きするフォントの大きさの変更は, scriptminsizeより小さくすることができることにも注意して下さい.

The changes to the font size due to scriptlevel should be viewed as being imposed from ‘outside’ the node. This means that the effect of scriptlevel is applied before an explicit mathsize (see 3.2.2 Mathematics style attributes common to token elements) on a token child of mfrac. Thus, the mathsize effectively overrides the effect of scriptlevel. However, that change to scriptlevel changes the current font size, which affects the meaning of an em length (see Length Valued Attributes) and so the scriptlevel still may have an effect in such cases. Note also that since mathsize is not constrained by scriptminsize, such direct changes to font size can result in scripts smaller than scriptminsize.

現在のフォントの大きさを直接変更することは, CSSによる場合でも, mathsize(3.2.2 素子要素に共通の数学書式属性参照)による場合であっても, scriptlevelに何の影響もないことに注意して下さい.

Note that direct changes to current font size, whether by CSS or by the mathsize attribute (see 3.2.2 Mathematics style attributes common to token elements), have no effect on the value of scriptlevel.

TEXの\displaystyle, \textstyle, \scriptstyle, \scriptscriptstyleはそれぞれ, displaystylescriptlevelの組合せtrue0, false0, false1, false2に相当します. よってmathdisplay=blockは\displaystyleに, display=inlineは \textstyleに相当します.

TEX's \displaystyle, \textstyle, \scriptstyle, and \scriptscriptstyle correspond to displaystyle and scriptlevel as true and 0, false and 0, false and 1, and false and 2, respectively. Thus, math's display=block corresponds to \displaystyle, while display=inline corresponds to \textstyle.

3.1.7 式の改行
Linebreaking of Expressions 改行の制御
Control of Linebreaks

MathMLは, 過度に長い式をいくつかの行に分割するために, 自動と手動(強制的)両方の式の改行の対応を提供しています. 全てのそのような改行は, mrow(省略されたmrowを含む. 省略された<mrow>参照)またはmfencedの中で行われます. 改行は典型的にmo要素の場所や, 従来との互換性からmspace要素の場所で行われます. 描画ソフトウェアは, 隣接したmi要素の間, または素子要素の中といった他の箇所で自動で改行することを選ぶかもしれません. MathMLはそのような改行を指定する手段を提供していませんが, 描画ソフトウェアがそのような場所で改行することを選ぶのであれば, そのような場所でも効果のある字下げの属性によって次の行を字下げすべきです.

MathML provides support for both automatic and manual (forced) linebreaking of expressions to break excessively long expressions into several lines. All such linebreaks take place within mrow (including inferred mrow; see Inferred <mrow>s) or mfenced. The breaks typically take place at mo elements and also, for backwards compatibility, at mspace. Renderers may also choose to place automatic linebreaks at other points such as between adjacent mi elements or even within a token element such as a very long mn element. MathML does not provide a means to specify such linebreaks, but if a renderer chooses to linebreak at such a point, it should indent the following line according to the indentation attributes that are in effect at that point.

囲っているmath要素がoverflow=linebreakで, 描画エンジンが式全体を表示するのに十分な空間がないと判断したとき, 自動の改行が起こります. よって利用可能な幅が描画ソフトウェアに知られていなければなりません. 書式の特性のように, 改行の特性はMathML要素が存在する環境から継承されるとしています. 幅が決められなかった場合, 無限の幅であると見なされます. mtableの中で各列はいくらか幅を持っています. この幅は属性として指定され, 内容によって決まります. この幅は, 改行のためには行全体の幅として使われるべきで, mtableの各要素は必要に応じて幅を持っています.

Automatic linebreaking occurs when the containing math element has overflow=linebreak and the display engine determines that there is not enough space available to display the entire formula. The available width must therefore be known to the renderer. Like font properties, one is assumed to be inherited from the environment in which the MathML element lives. If no width can be determined, an infinite width should be assumed. Inside of an mtable, each column has some width. This width may be specified as an attribute or determined by the contents. This width should be used as the line wrapping width for linebreaking, and each entry in an mtable is linewrapped as needed.

課題304: MathML 4で非推奨となる可能性のあるプレゼンテーションMathMLの一部
Issue 304: Potential presentation MathML items to deprecate in MathML 4
(mspace's @linebreak)

強制的な改行は, mo要素またはmspace要素のlinebreak=newlineを利用して指定されます. 自動と手動の改行は, 両方とも同じ数式の中で起こっても良いです.

Forced linebreaks are specified by using linebreak=newline on an mo or mspace element. Both automatic and manual linebreaking can occur within the same formula.

mfrac, msqrt, mroot, mencloseの中の式や様々な添え字の要素の自動的な改行は不要です. 描画ソフトウェアは, それらの要素の中に強制的な改行がある場合, その改行を無視しても良いです.

Automatic linebreaking of subexpressions of mfrac, msqrt, mroot and menclose and the various script elements is not required. Renderers are free to ignore forced breaks within those elements if they choose.

mo要素や, 場合によってはmspace要素の属性は, 改行や次の行の字下げを制御します. 制御可能な改行の性質は次のとおりです.

Attributes on mo and possibly on mspace elements control linebreaking and indentation of the following line. The aspects of linebreaking that can be controlled are:

  • 場所 ― 属性は, 特定の演算子や空白での改行が望ましいか, 特に改行が必要か禁止か決めます. これらの属性は, mo要素やmspace要素でのみ設定できます. ( 改行の属性を参照して下さい.)

    Where — attributes determine the desirability of a linebreak at a specific operator or space, in particular whether a break is required or inhibited. These can only be set on mo and mspace elements. (See Linebreaking attributes.)

  • 演算子の表示/位置 ― 改行されたときに, 属性は, 行の最後か, 次の行の最初か, その両方の場所か, どこに演算子が現れるべきか決めます. これらの属性は, mo要素で設定されるか, mstyle要素またはmath要素から継承されるかします. ( 改行の属性を参照して下さい.)

    Operator Display/Position — when a linebreak occurs, determines whether the operator will appear at the end of the line, at the beginning of the next line, or in both positions; and how much vertical space should be added after the linebreak. These attributes can be set on mo elements or inherited from mstyle or math elements. (See Linebreaking attributes.)

  • 字下げ ― 属性は, 次の行を前の行のどこかと揃えるための字下げすを含め, 改行に続く行の字下げの方法を決めます. これらの属性は, mo要素で設定されるか, mstyle要素またはmath要素から継承されるかします. ( 改行の属性を参照して下さい.)

    Indentation — determines the indentation of the line following a linebreak, including indenting so that the next line aligns with some point in a previous line. These attributes can be set on mo elements or inherited from mstyle or math elements. (See Indentation attributes.)

math要素が行の中の文脈で現れたとき, math要素は文章の描画エンジンによって段落を描くどんな決まりを用いられようと, その決まりに従うでしょう. そのような決まりは必然的にこの仕様書の対象外です. 代わりに, math要素のoverflow属性の値を用いるでしょう. (2.2.1 属性を参照して下さい.)

When a math element appears in an inline context, it may obey whatever paragraph flow rules are employed by the document's text rendering engine. Such rules are necessarily outside of the scope of this specification. Alternatively, it may use the value of the math element's overflow attribute. (See 2.2.1 Attributes.) 改行の例
Examples of Linebreaking

次に示す例は, 強制的な改行と強制的な位置揃えを明確にしています.

The following example demonstrates forced linebreaks and forced alignment:

 <mrow> <mi>f</mi> <mo>&#x2061;<!--ApplyFunction--></mo> <mo>(</mo> <mi>x</mi> <mo>)</mo> </mrow>
 <mo id='eq1-equals'>=</mo>
   <mrow> <mo>(</mo> <mrow> <mi>x</mi> <mo>+</mo> <mn>1</mn> </mrow> <mo>)</mo> </mrow>
  <mo linebreak='newline' linebreakstyle='before'
      indentalign='id' indenttarget='eq1-equals'>=</mo>
   <msup> <mi>x</mi> <mn>4</mn> </msup>
   <mo id='eq1-plus'>+</mo>
   <mrow> <mn>4</mn> <mo>&#x2062;<!--InvisibleTimes--></mo> <msup> <mi>x</mi> <mn>3</mn> </msup> </mrow>
   <mrow> <mn>6</mn> <mo>&#x2062;<!--InvisibleTimes--></mo> <msup> <mi>x</mi> <mn>2</mn> </msup> </mrow>
   <mo linebreak='newline' linebreakstyle='before'
       indentalignlast='id' indenttarget='eq1-plus'>+</mo>
   <mrow> <mn>4</mn> <mo>&#x2062;<!--InvisibleTimes--></mo> <mi>x</mi> </mrow>


This displays as

example with equal and plus signs aligned

indentalignlastの既定値はindentalignなので, 上の例ではindentalignindentalignlastの場所で使うことができることに注意して下さい. また, linebreakstyle='before'が既定値なのでその値を指定する必要もないです.

Note that because indentalignlast defaults to indentalign, in the above example indentalign could have been used in place of indentalignlast. Also, the specifying linebreakstyle='before' is not needed because that is the default value.

3.1.8 プレゼンテーション要素の概要
Summary of Presentation Elements 素子要素
Token Elements
mi 識別子
mn 数字
mo 演算子, かっこ, 区切り
operator, fence, or separator
mtext 文章
mspace 空白
ms 文字列
string literal

これらに加えて, mglyph要素が, 標準でない記号を画像として表現するのに, 素子要素と一緒に使用されてもよいです.

Additionally, the mglyph element may be used within Token elements to represent non-standard symbols as images. 一般的な配置要素
General Layout Schemata
mrow 水平に任意の数の式をまとめる
group any number of sub-expressions horizontally
mfrac 2つの式から分数を構成する
form a fraction from two sub-expressions
msqrt 平方根(指数無しの根号)を構成する
form a square root (radical without an index)
mroot 特定の指数の根を構成する
form a radical with specified index
mstyle 書式を変更する
style change
merror 処理前のエラーメッセージ構文を囲む
enclose a syntax error message from a preprocessor
mpadded 周囲の余白を調整する
adjust space around content
mphantom 大きさを保ったまま見えなくする
make content invisible but preserve its size
mfenced かっこの組で囲む
surround content with a pair of fences
menclose 割り算の筆算の記号のような引き伸ばした記号で囲う
enclose content with a stretching symbol such as a long division sign 添え字の配置要素
Script and Limit Schemata
msub 下付き添え字を基となる式に付け加える
attach a subscript to a base
msup 上付き添え字を基となる式に付け加える
attach a superscript to a base
msubsup 下付き添え字と上付き添え字の組を基となる式に付け加える
attach a subscript-superscript pair to a base
munder 下側添え字を基となる式に付け加える
attach an underscript to a base
mover 上側添え字を基となる式に付け加える
attach an overscript to a base
munderover 下側添え字と上側添え字の組を基となる式に付け加える
attach an underscript-overscript pair to a base
mmultiscripts 前置の添え字やテンソル添え字を基となる式に付け加える
attach prescripts and tensor indices to a base 表と行列
Tables and Matrices
mtable 表や行列
table or matrix
mlabeledtr 表や行列の, 行番号や数式の番号と一緒に用いる行
row in a table or matrix with a label or equation number
mtr 表や行列の行
row in a table or matrix
mtd 表や行列の要素
one entry in a table or matrix
maligngroupmalignmark 位置揃えの記号
alignment markers 初等数学の配置
Elementary Math Layout
mstack 揃えられた文字列の縦の並び
columns of aligned characters
mlongdiv 除数や商を加えたmsgroupに類似したまとまり
similar to msgroup, with the addition of a divisor and result
msgroup 同じ量ずらしたmstackの中の行のまとまり
a group of rows in an mstack that are shifted by similar amounts
msrow mstackの中の行
a row in an mstack
mscarries mstackの中の, 繰り上がりや繰り下がりを表している行
row in an mstack whose contents represent carries or borrows
mscarry mscarriesの要素
one entry in an mscarries
msline mstackの中の水平線
horizontal line inside of mstack 式に動きを付ける
Enlivening Expressions
maction 式の一部に動作を結び付ける
bind actions to a sub-expression

3.1.9 プレゼンテーション要素に共通の数学属性
Mathematics attributes common to presentation elements

2.1.6 全てのMathML要素で利用できる属性で一覧にした属性に加えて, 全てのMathMLプレゼンテーション要素は次の種類の属性を持っています.

In addition to the attributes listed in 2.1.6 Attributes Shared by all MathML Elements, all MathML presentation elements accept the following classes of attribute. MathMLコア属性
MathML Core Attributes

プレゼンテーション要素は, [MathMLコア]で指定された全ての共通の属性も受け入れます.

Presentation elements also accept all the Global Attributes specified by [MathML-Core].

次の2つの属性を含むこれらの属性は, 特に視覚的な分野を想定したものです. これらの属性は, 表示された式の意図している意味に影響を与えないものとされていますが, 式の一部を強調したり, 注意を引いたりするのに利用されます. 例えば, 異なるmathvariantを持つ変数とは対照的に, 赤い"x"は黒い"x"と意味が違うとは考えません(3.2.2 素子要素に共通の数学書式属性参照).

These attributes include the following two attributes that are primarily intended for visual media. They are not expected to affect the intended semantics of displayed expressions, but are for use in highlighting or drawing attention to the affected subexpressions. For example, a red "x" is not assumed to be semantically different than a black "x", in contrast to variables with different mathvariant values (see 3.2.2 Mathematics style attributes common to token elements).


素子要素の内容, 線, 根号, その他の装飾といった要素の中身を描画する際に使用する文字等の色を指定します. また, 配置要素で利用された場合, 子要素のmathcolorの既定値を定めます.
Specifies the foreground color to use when drawing the components of this element, such as the content for token elements or any lines, surds, or other decorations. It also establishes the default mathcolor used for child elements when used on a layout element.
mathbackground | "transparent"
要素とその子要素の領域を塗り潰すのに使用する背景色を指定します. 既定値の"transparent"は, 一般に現在描画している文章の中の背景色を透けて見えるように設定します.
Specifies the background color to be used to fill in the bounding box of the element and its children. The default, "transparent", lets the background color, if any, used in the current rendering context to show through.

MathMLの式は, HTMLのような文章データフォーマットによく埋め込まれることから, MathML描画ソフトウェアは, MathMLが現れた場所の文章で利用されている色を継承すべきです. しかしながら, ([MathMLコア]と対照的に)MathMLは描画環境から書式情報を継承する仕組みを特定していないことに注意して下さい. 詳細については3.2.2 素子要素に共通の数学書式属性を参照して下さい.

Since MathML expressions are often embedded in a textual data format such as HTML, the MathML renderer should inherit the foreground color used in the context in which the MathML appears. Note, however, that MathML (in contrast to [MathML-Core]) doesn't specify the mechanism by which style information is inherited from the rendering environment. See 3.2.2 Mathematics style attributes common to token elements for more details.

提案されているMathMLの視覚的描画の決まりは, 次の場合を除いて, mathbackground属性の影響を受ける, 背景の領域の正確な範囲を定義していないことに注意して下さい. それは, 内容が負の領域を持っておらず, 周囲との間隔が負であることによって描画領域が他の描画領域と重なるべきでない場合です. その場合の領域は内容を表示する描画領域全ての背後となるべきですが, 周囲を取り囲んでいる式を表示する描画領域の前面には来るべきです. mathbackground属性の影響が及ぶ領域の範囲において, 周囲との間隔が負であることにより描画領域が重なった場合の影響は, MathMLの描画の決まりによって定義されてはいません.

Note that the suggested MathML visual rendering rules do not define the precise extent of the region whose background is affected by the mathbackground attribute, except that, when the content does not have negative dimensions and its drawing region should not overlap with other drawing due to surrounding negative spacing, should lie behind all the drawing done to render the content, and should not lie behind any of the drawing done to render surrounding expressions. The effect of overlap of drawing regions caused by negative spacing on the extent of the region affected by the mathbackground attribute is not defined by these rules.

3.2 素子要素
Token Elements

プレゼンテーションマークアップの素子要素は, ざっくり言うと, 意味を伝達する数学表記の最小の単位を表すよう意図されています. 素子は, おおまかに言って, 文章の中の言葉と似ています. ただし, 数学表記の精密で象徴的な特性から, 素子要素の様々な種類や性質がMathMLマークアップの中で重要な役割を果たします. 対照的に, 文章データの中では, 個々の言葉は, めったにマークアップされたり, 特別な書式にされたりする必要はありません.

Token elements in presentation markup are broadly intended to represent the smallest units of mathematical notation which carry meaning. Tokens are roughly analogous to words in text. However, because of the precise, symbolic nature of mathematical notation, the various categories and properties of token elements figure prominently in MathML markup. By contrast, in textual data, individual words rarely need to be marked up or styled specially.

素子要素は, 識別子(mi), 数字(mn), 演算子(mo), 文章(mtext), 文字列(ms), 空白(mspace)を表します. mglyph要素は標準でない記号を画像で表すのに素子要素と一緒に使われるてもよいです. 前に述べた個々の要素の詳しい説明に関して, 次の2つの小節で素子要素の中身として認められている内容や共通の属性について論じます.

Token elements represent identifiers (mi), numbers (mn), operators (mo), text (mtext), strings (ms) and spacing (mspace). The mglyph element may be used within token elements to represent non-standard symbols by images. Preceding detailed discussion of the individual elements, the next two subsections discuss the allowable content of token elements and the attributes common to them.

3.2.1 素子要素の内容となる文字, <mglyph/>
Token Element Content Characters, <mglyph/>

MathMLの記述における文字データは, 素子要素の内容の一部となることのみ認められています. 要素間の空白は無視されます. 空のmspace要素を除いて, 素子要素は0個以上のユニコード文字の文字列, mglyph要素またはmalignmark要素を含むことができます. mglyph要素は, 標準でない文字や記号を画像で表すのに使われます. malignmark要素は, 表の構成を利用する際に位置揃えの基準を確立するのに用いられ, 表示されない要素です(3.5.5 位置揃えの記号 <maligngroup/>, <malignmark/>参照).

Character data in MathML markup is only allowed to occur as part of the content of token elements. Whitespace between elements is ignored. With the exception of the empty mspace element, token elements can contain any sequence of zero or more Unicode characters, or mglyph or malignmark elements. The mglyph element is used to represent non-standard characters or symbols by images; the malignmark element establishes an alignment point for use within table constructs, and is otherwise invisible (see 3.5.5 Alignment Markers <maligngroup/>, <malignmark/>).

文字は, 直接ユニコードの文字データとして表されるか、間接的に数値文字参照または文字実体参照を使用して表されるでしょう. ユニコードは, 数々の非常によく似た文字を含んでいます. どの状況でどの文字を使用するのが適切かの議論については, [MathMLメモ]を参照して下さい.

Characters can be either represented directly as Unicode character data, or indirectly via numeric or character entity references. Unicode contains a number of look-alike characters. See [MathML-Notes] for a discussion of which characters are appropriate to use in which circumstance.

(mspace以外の)素子要素は, 中身があればその中身として描画されるべきです(すなわち, 視覚的表現では, 素子要素の中身である文字に対する標準的な字形やmglyphに対する画像を水平に密集させた列として描画されます). mspace要素は, 属性によって決められた幅の空白として描画されます. 描画アルゴリズムは, 下記で説明する数学書式属性も考慮すべきです. また, 決まりや素子要素の種類それぞれに固有な属性によって周囲の空白は修正されます. 中身の向きの特徴も尊重されるべきです( 素子要素における双方向の配置参照).

Token elements (other than mspace) should be rendered as their content, if any (i.e. in the visual case, as a closely-spaced horizontal row of standard glyphs for the characters or images for the mglyphs in their content). An mspace element is rendered as a blank space of a width determined by its attributes. Rendering algorithms should also take into account the mathematics style attributes as described below, and modify surrounding spacing by rules or attributes specific to each type of token element. The directional characteristics of the content must also be respected (see Bidirectional Layout in Token Elements). 記号の表示に画像を利用する <mglyph/>
Using images to represent symbols <mglyph/> 説明

mglyph要素は, 標準でない記号を表現するために画像を表示する仕組みを提供します. そして, 存在しているユニコード文字が十分でないときに, 素子要素mi, mn, mo, mtext, msの中身として利用されてもよいです.

The mglyph element provides a mechanism for displaying images to represent non-standard symbols. It may be used within the content of the token elements mi, mn, mo, mtext or ms where existing Unicode characters are not adequate.

ユニコードは, 数学で利用されるたくさんの数の文字を定義しており, また, ほとんどの場合にこれらの文字を表す字形は様々なフォントで広く利用できます. これらの文字がほぼ全ての利用者の必要性に対応すべきであるとはいえ, MathMLは, 数学は静的なものではなく新しい文字や記号が便利であるように加えられると認識しています. よく利用される文字は, おそらく最終的にユニコードコンソーシアムや他の標準化団体に受け入れられるでしょうが, それらはしばしば長い時間を要します.

Unicode defines a large number of characters used in mathematics and, in most cases, glyphs representing these characters are widely available in a variety of fonts. Although these characters should meet almost all users needs, MathML recognizes that mathematics is not static and that new characters and symbols are added when convenient. Characters that become well accepted will likely be eventually incorporated by the Unicode Consortium or other standards bodies, but that is often a lengthy process.

字形のsrc属性はmglyphを唯一のものとして特定することに注意して下さい. つまり, 同じsrcの値を持つ2つのmglyphは, 2つの文字や字形が同一かどうかを決めるソフトウェアによって同一と見なされるべきです.

Note that the glyph's src attribute uniquely identifies the mglyph; two mglyphs with the same values for src should be considered identical by applications that must determine whether two characters/glyphs are identical. 属性

mglyph要素は, 3.1.9 プレゼンテーション要素に共通の数学属性で一覧にされている属性を持っていします. ただし, mathcolorは効果がないことに注意して下さい. 背景の色であるmathbackgroundによって, 指定の画像が透過であるならば, 塗り潰されるべきです.

The mglyph element accepts the attributes listed in 3.1.9 Mathematics attributes common to presentation elements, but note that mathcolor has no effect. The background color, mathbackground, should show through if the specified image has transparency.


mglyph also accepts the additional attributes listed here.


src URI 必要
画像の場所を指定します. 通常, MathML部分の基準となるURIからの相対パスとなります.
Specifies the location of the image resource; it may be a URI relative to the base-URI of the source of the MathML, if any.
width 長さ
from image
字形の要求される幅を指定します. heightを参照して下さい.
Specifies the desired width of the glyph; see height.
height 長さ
from image
字形の要求される高さを指定します. widthheightの一方だけが与えられた場合, 画像はアスペクト比を保ったまま, 拡大・縮小されます. どちらも与えられない場合, 画像は元の大きさのまま表示されるべきです.
Specifies the desired height of the glyph. If only one of width and height are given, the image should be scaled to preserve the aspect ratio; if neither are given, the image should be displayed at its natural size.
valign 長さ
画像のベースライン(訳注:欧文書体で水平の基準線で大文字の下端の位置)を通常のベースラインからどれだけずらすかを指定します. 正の値のときは画像の下端をベースラインから上げ, 負の値のときは下げます. 0の値(既定値)は, 画像のベースラインを画像の下端にすることを意味します.
Specifies the baseline alignment point of the image with respect to the current baseline. A positive value shifts the bottom of the image above the current baseline while a negative value lowers it. A value of 0 (the default) means that the baseline of the image is at the bottom of the image.
alt 文字列
字形に対する代用の名前を提供します. 指定された画像が見つからなかったり, 表示できなかったりした場合, 表示ソフトウェアはこの名前を警告メッセージや字形が見つからないという注意で利用するでしょう. この名前は, 聴覚表現ソフトウェアや記号を処理するソフトウェアで利用されるでしょう. また, 説明のために選ばれるべきでしょう.
Provides an alternate name for the glyph. If the specified image can't be found or displayed, the renderer may use this name in a warning message or some unknown glyph notation. The name might also be used by an audio renderer or symbol processing system and should be chosen to be descriptive.

次に示す例は, 研究者が組み紐の組合せを表記するのに, 複数の画像で構成されたmglyphをどのように利用するのかを描いています.

The following example illustrates how a researcher might use the mglyph construct with a set of images to work with braid group notation.

  <mi><mglyph src="my-braid-23" alt="2 3 braid"/></mi>
  <mi><mglyph src="my-braid-132" alt="1 3 2 braid"/></mi>
  <mi><mglyph src="my-braid-13" alt="1 3 braid"/></mi>


This might render as:


3.2.2 素子要素に共通の数学書式属性
Mathematics style attributes common to token elements

全てのプレゼンテーション要素に対して定義されている属性(3.1.9 プレゼンテーション要素に共通の数学属性)に加えて, MathMLは, 全てのプレゼンテーション素子要素やmath要素, mstyle要素に有効な, 2つの数学書式属性や方向を表す属性を含んでいます. なお, dirmrow要素でも有効です. これらの属性は次のとおりです.

In addition to the attributes defined for all presentation elements (3.1.9 Mathematics attributes common to presentation elements), MathML includes two mathematics style attributes as well as a directionality attribute valid on all presentation token elements, as well as the math and mstyle elements; dir is also valid on mrow elements. The attributes are:


mathvariant "normal" | "bold" | "italic" | "bold-italic" | "double-struck" | "bold-fraktur" | "script" | "bold-script" | "fraktur" | "sans-serif" | "bold-sans-serif" | "sans-serif-italic" | "sans-serif-bold-italic" | "monospace" | "initial" | "tailed" | "looped" | "stretched" normal (<mi>を除く)
(except on <mi>)
素子の論理的な種類を指定します. この種類は書式の種類というわけなく, 典型的に意図した意味を伝えるものであることに注意して下さい. 下記の議論を参照して下さい.
Specifies the logical class of the token. Note that this class is more than styling, it typically conveys semantic intent; see the discussion below.
mathsize "small" | "normal" | "big" | 長さ
素子の中身を表示する大きさを指定します. smallまたはbigという値は, 現在のフォントサイズより小さいまたは大きいということを表します. ただし, 実際の比率は指定されておらず任されています. normalは完全性のために用意されていますが, 100%1emと同じであり効果はありません.
Specifies the size to display the token content. The values small and big choose a size smaller or larger than the current font size, but leave the exact proportions unspecified; normal is allowed for completeness, but since it is equivalent to 100% or 1em, it has no effect.
dir "ltr" | "rtl" 継承する
素子の中の文字の初期の方向を指定します. ltr(左から右)またはrtl(右から左). この属性は, 弱い文字(訳注:周囲の文字の方向に左右される文字で例えばかっこ"(")または中立の文字(訳注:周囲の文字の方向がどちらでも同じように表示される文字で例えば空白" ")を含む特殊な場合に必要になります. より詳しい議論については, 数式全体の方向を参照して下さい. mspaceに対しては何の効果も与えません.
specifies the initial directionality for text within the token: ltr (Left To Right) or rtl (Right To Left). This attribute should only be needed in rare cases involving weak or neutral characters; see Overall Directionality of Mathematics Formulas for further discussion. It has no effect on mspace.

mathvariant属性は, 素子要素の論理的な種類を定義しています. それぞれの種類は, 植字に関係した記号的な素子の集合を提供します. 各素子は与えられた数式の中で特定の意味を持っています. そのため, 各素子は視覚的に表現され, 不意に意味を変えてしまうような文書全体の書式の変更から保護される必要があります. 各素子は, mathvariant属性の値と素子要素内の文字データの組合せによって特定されます.

The mathvariant attribute defines logical classes of token elements. Each class provides a collection of typographically-related symbolic tokens. Each token has a specific meaning within a given mathematical expression and, therefore, needs to be visually distinguished and protected from inadvertent document-wide style changes which might change its meaning. Each token is identified by the combination of the mathvariant attribute value and the character data in the token element.

CSSが利用可能な環境でMathMLを描画する場合, 数学書式属性はCSS書式の規則のための定義済の選択子と見なされます. MathMLとCSSの相互作用の議論については, 6.5 MathMLと一緒にCSSを利用するを参照して下さい. また, CSSを利用してMathMLを描画する際の議論やCSSスタイルシートの例については[MathMLforCSS]を参照して下さい. CSSが利用できない場合, 論理的に異なる種類を描き分けるのは, 描画ソフトウェア内部の書式の仕組み次第です. ほとんどのMathML描画ソフトウェアはおそらく, 追加の, 内部の書式処理アルゴリズムをいくらか当てにしようしています. 特に, mathvariant属性は, CSSの継承の仕組みに従っていません. 既定値は, 単独の文字の内容を持つmiを除いて, 全ての要素でnormal(斜体でない)です. 詳細については, 3.2.3 識別子<mi>を参照して下さい.

When MathML rendering takes place in an environment where CSS is available, the mathematics style attributes can be viewed as predefined selectors for CSS style rules. See 6.5 Using CSS with MathML for discussion of the interaction of MathML and CSS. Also, see [MathMLforCSS] for discussion of rendering MathML by CSS and a sample CSS style sheet. When CSS is not available, it is up to the internal style mechanism of the rendering application to visually distinguish the different logical classes. Most MathML renderers will probably want to rely on some degree on additional, internal style processing algorithms. In particular, the mathvariant attribute does not follow the CSS inheritance model; the default value is normal (non-slanted) for all tokens except for mi with single-character content. See 3.2.3 Identifier <mi> for details.

描画ソフトウェアは, 数学書式属性をどの描画特性に当てはめるか完全に自由です. しかしながら, 実際は, 数学書式属性の名前と値は明らかな植字の特性を暗示しており, 描画ソフトウェアは可能な限りその自然な実装を尊重するよう試みます. 例えば, mathvariant属性の値がsans-serifである素子をHelveticaフォントやArialフォントで描画することは妥当です. しかし, Times Romanフォントでその素子を描画することは本当に誤解を招くことになり, 避けるべきです.

Renderers have complete freedom in mapping mathematics style attributes to specific rendering properties. However, in practice, the mathematics style attribute names and values suggest obvious typographical properties, and renderers should attempt to respect these natural interpretations as far as possible. For example, it is reasonable to render a token with the mathvariant attribute set to sans-serif in Helvetica or Arial. However, rendering the token in a Times Roman font could be seriously misleading and should be avoided.

原則として, 特定の記号の素子を定義するのに, どのmathvariantの値も, どの文字データとも一緒に利用できます. 実際は, 文字データとmathvariantの値の特定の組合せのみ, 与えられた描画ソフトウェアによって視覚的に表現されます, 例えば, "フラクタルのアルファ"や"太字の斜体の漢字"といった文字は明確に存在せず, また, "initial", "tailed", "looped", "stretched"といったmathvariantの値はアラビア文字に対してのみ適切です.

In principle, any mathvariant value may be used with any character data to define a specific symbolic token. In practice, only certain combinations of character data and mathvariant values will be visually distinguished by a given renderer. For example, there is no clear-cut rendering for a "fraktur alpha" or a "bold italic Kanji" character, and the mathvariant values "initial", "tailed", "looped", and "stretched" are appropriate only for Arabic characters.

文字データとmathvariantの値の特定の組合せは, 数学用英数字記号を表すよう割り当てられたユニコードコードポイントと同じ働きをします. これらのユニコードコードポイントは, ユニコード標準で一覧にされたアラビア文字の数学用英数字記号のブロックU+1EE00からU+1EEFFや数学用英数字記号のブロックU+1D400からU+1D7FF, 7.2 数学用英数字記号で一覧にされたSMPにおける"穴"を表す文字のような記号の範囲U+2100からU+214Fです. これらの文字について, 詳細はUTR #25の第2.2節で説明しています. ユニコード標準におけるそのような文字それぞれの説明では, mathvariantの値に対応して書式が変更になる場合を除いて, 同一と見なされる書式のない文字を提供します. 書式のない文字と対応するmathvariantの値の組合せを利用している素子要素は, mathvariant属性を用いないで数学用英数字記号を利用している素子要素と同一と見なされます. 数学用英数字記号の外観は周囲のmathvariantや他の書式の宣言によって変更されるべきではないことに注意して下さい.

Certain combinations of character data and mathvariant values are equivalent to assigned Unicode code points that encode mathematical alphanumeric symbols. These Unicode code points are the ones in the Arabic Mathematical Alphabetic Symbols block U+1EE00 to U+1EEFF, Mathematical Alphanumeric Symbols block U+1D400 to U+1D7FF, listed in the Unicode standard, and the ones in the Letterlike Symbols range U+2100 to U+214F that represent "holes" in the alphabets in the SMP, listed in 7.2 Mathematical Alphanumeric Symbols. These characters are described in detail in section 2.2 of UTR #25. The description of each such character in the Unicode standard provides an unstyled character to which it would be equivalent except for a font change that corresponds to a mathvariant value. A token element that uses the unstyled character in combination with the corresponding mathvariant value is equivalent to a token element that uses the mathematical alphanumeric symbol character without the mathvariant attribute. Note that the appearance of a mathematical alphanumeric symbol character should not be altered by surrounding mathvariant or other style declarations.

描画ソフトウェアは, ユニコード文字に一致する文字データとmathvariantの値の組合せに対応すべきです. また, それらの組合せは利用可能なフォントを用いて視覚的に表現できるでしょう. 描画ソフトウェアは, 一致する割り当てられたユニコードコードポイントがない場合, 文字データとmathvariantの値の組合せを無視してもよいですし, 対応してもよいです. また, MathMLを書く人は, 一致する割り当てられたユニコードコードポイントがない数学記号への対応は, 描画ソフトウェアによって異なることを認識すべきです.

Renderers should support those combinations of character data and mathvariant values that correspond to Unicode characters, and that they can visually distinguish using available font characters. Renderers may ignore or support those combinations of character data and mathvariant values that do not correspond to an assigned Unicode code point, and authors should recognize that support for mathematical symbols that do not correspond to assigned Unicode code points may vary widely from one renderer to another.

MathMLによる表現はHTMLのような文章データフォーマットの中に組み込まれるので, 周囲の文章とMathMLはフォントサイズのような描画属性を共有しなければならず, そのために表現される書式は互いに尊重されるでしょう. このことから, ほとんどの文章の描画に影響する属性の値は, 上述の表の既定値の列に見られるように描画環境から継承されます. (周囲の文章とMathMLが別々のソフトウェア, 例えば, ブラウザとプラグインで描画された場合, MathML描画ソフトウェアに, MathML属性で指定されない周囲の文字のベースラインの位置といった追加情報を提供することも描画環境にとって重要です.) ただし, MathMLは描画環境から書式情報を継承する仕組みを指定していないことに注意して下さい.

Since MathML expressions are often embedded in a textual data format such as HTML, the surrounding text and the MathML must share rendering attributes such as font size, so that the renderings will be compatible in style. For this reason, most attribute values affecting text rendering are inherited from the rendering environment, as shown in the default column in the table above. (In cases where the surrounding text and the MathML are being rendered by separate software, e.g. a browser and a plug-in, it is also important for the rendering environment to provide the MathML renderer with additional information, such as the baseline position of surrounding text, which is not specified by any MathML attributes.) Note, however, that MathML doesn't specify the mechanism by which style information is inherited from the rendering environment.

利用しているフォントの要求されたmathsizeが利用できない場合, 描画ソフトウェアは, 最も分かりやすく, 最も高い質の描画となるよう適切な方法でフォントサイズを近付けるべきです. MathMLの要素の多くは, その子要素に応じてフォントサイズを自動的に変更することに注意して下さい. 3.1.6 displaystyleとscriptlevelの議論を参照して下さい.

If the requested mathsize of the current font is not available, the renderer should approximate it in the manner likely to lead to the most intelligible, highest quality rendering. Note that many MathML elements automatically change the font size in some of their children; see the discussion in 3.1.6 Displaystyle and Scriptlevel. MathMLの中にHTMLを埋め込む
Embedding HTML in MathML

MathMLは, 6.4 MathMLと他の言語を組合せるで述べているように, 他の言語と組合せることができます. 仕様書は, MathMLに他のフォーマットを埋め込むのに, mtext要素の子要素や, 式の中で埋め込む役割を果たすのに適切な他の葉要素の子要素に, 追加の要素を認めるようMathML構文を拡張しました(3.2.3 識別子 <mi>, 3.2.4 数字 <mn>, 3.2.5 演算子, かっこ, 区切り, アクセント <mo>参照). 方向, フォントサイズ, その他のフォントの属性は, それらを含む葉要素の文字に使用される属性を継承すべきです(3.2.2 素子要素に共通の数学書式属性参照).

MathML can be combined with other formats as described in 6.4 Combining MathML and Other Formats. The recommendation is to embed other formats in MathML by extending the MathML schema to allow additional elements to be children of the mtext element or other leaf elements as appropriate to the role they serve in the expression (see 3.2.3 Identifier <mi>, 3.2.4 Number <mn>, and 3.2.5 Operator, Fence, Separator or Accent <mo>). The directionality, font size, and other font attributes should inherit from those that would be used for characters of the containing leaf element (see 3.2.2 Mathematics style attributes common to token elements).


Here is an example of embedding SVG inside of mtext in an HTML context:

   <mtext><input type="text" placeholder="what shape is this?"/></mtext>
    <svg xmlns="http://www.w3.org/2000/svg" width="4cm" height="4cm" viewBox="0 0 400 400">
     <rect x="1" y="1" width="398" height="398" style="fill:none; stroke:blue"/>
     <path d="M 100 100 L 300 100 L 200 300 z" style="fill:red; stroke:blue; stroke-width:3"/>

3.2.3 識別子 <mi>
Identifier <mi> 説明

mi要素は, 識別子として表示されるべき記号の名前や何らかの文字列を表します. 識別子には, 変数, 関数名, 定数の記号が含まれます. 典型的な画像描画ソフトウェアは, mi要素を(隣接する要素に関連する空白以外の)周囲の空白を取り除いて, その中身として描画します(3.2.1 素子要素の内容となる文字, <mglyph/>参照).

An mi element represents a symbolic name or arbitrary text that should be rendered as an identifier. Identifiers can include variables, function names, and symbolic constants. A typical graphical renderer would render an mi element as its content (see 3.2.1 Token Element Content Characters, <mglyph/>), with no extra spacing around it (except spacing associated with neighboring elements).

数学の識別子全てがmi要素によって表現されるわけではありません. 例えば, 添え字が付いたり, プライムが付いたりした変数は, それぞれmsubmsupを用いて表現されるべきです. 逆に, (級数の和における省略といった)の役割をする何らかの文字列は, mi要素を利用して表現すべきです.

Not all mathematical identifiers are represented by mi elements — for example, subscripted or primed variables should be represented using msub or msup respectively. Conversely, arbitrary text playing the role of a term (such as an ellipsis in a summed series) should be represented using an mi element.

miはプレゼンテーション要素であることを強調しておきます. そのこと自体は, 要素の中身が識別子として描画されることを単に表しています. 大半の場合, miの中身は実際のところ, 変数や関数名といった数学の識別子を表すでしょう. しかしながら, 前の段落で示したように, 識別子として描画されるべき表記と, 実際に数学の識別子を表すことを意図している表記との対応は完全ではありません. 要素の意味が識別子そのものであることが保証されている要素については, 4. コンテントマークアップciの説明を参照して下さい.

It should be stressed that mi is a presentation element, and as such, it only indicates that its content should be rendered as an identifier. In the majority of cases, the contents of an mi will actually represent a mathematical identifier such as a variable or function name. However, as the preceding paragraph indicates, the correspondence between notations that should render as identifiers and notations that are actually intended to represent mathematical identifiers is not perfect. For an element whose semantics is guaranteed to be that of an identifier, see the description of ci in 4. Content Markup. 属性

mi要素は, 3.2.2 素子要素に共通の数学書式属性で一覧にした属性を持っています. ただし, 1つだけ既定値が異なります.

mi elements accept the attributes listed in 3.2.2 Mathematics style attributes common to token elements, but in one case with a different default value:


mathvariant "normal" | "bold" | "italic" | "bold-italic" | "double-struck" | "bold-fraktur" | "script" | "bold-script" | "fraktur" | "sans-serif" | "bold-sans-serif" | "sans-serif-italic" | "sans-serif-bold-italic" | "monospace" | "initial" | "tailed" | "looped" | "stretched" (内容に依存. 下記の説明を参照して下さい.)
(depends on content; described below)
素子の論理的な種類を指定します. 中身が単一の文字の場合を除いて, 既定値はnormal(斜体でない)です. 中身が単一の文字の場合, 既定値はitalicです.
Specifies the logical class of the token. The default is normal (non-slanted) unless the content is a single character, in which case it would be italic.

数学用英数字記号文字(7.2 数学用英数字記号参照)と等しいことを決定するために, mathvariant属性の値は, 上で述べた特別な既定の挙動を含め, 最初に解決すべきです.

Note that for purposes of determining equivalences of Math Alphanumeric Symbol characters (see 7.2 Mathematical Alphanumeric Symbols) the value of the mathvariant attribute should be resolved first, including the special defaulting behavior described above.
<mi mathvariant='script'>L</mi>

中身の無いmi要素は認められています. <mi></mi>は, 例えば, 数式編集ツールで(数学における型通りの構文によれば)を必要とするMathMLの式で, まだ項が1つも含まれていないときに位置を表すのに使用されるでしょう.

An mi element with no content is allowed; <mi></mi> might, for example, be used by an expression editor to represent a location in a MathML expression which requires a term (according to conventional syntax for mathematics) but does not yet contain one.

識別子はsinのような関数の名前を含みます. sin xのような式では, 下記に示す文字U+2061(実体afまたは実体ApplyFunction)を用いて書かれるべきです. 見えない演算子についての議論は3.2.5 演算子, かっこ, 区切り, アクセント <mo>を参照して下さい.

Identifiers include function names such as sin. Expressions such as sin x should be written using the character U+2061 (entity af or ApplyFunction) as shown below; see also the discussion of invisible operators in 3.2.5 Operator, Fence, Separator or Accent <mo>.

  <mi> sin </mi>
  <mo> &#x2061;<!--ApplyFunction--> </mo>
  <mi> x </mi>
sin x

として扱われるべきいろいろな文章は, 次のようにmi要素を用いて表すこともできます.

Miscellaneous text that should be treated as a term can also be represented by an mi element, as in:

  <mn> 1 </mn>
  <mo> + </mo>
  <mo> + </mo>
  <mi> n </mi>
1 + + n

miがそのような例外の状況で利用される場合, はっきりとmathvariant属性を設定することで, 描画ソフトウェアの通常の挙動より良い出力結果を得られるでしょう.

When an mi is used in such exceptional situations, explicitly setting the mathvariant attribute may give better results than the default behavior of some renderers.

記号の定数の名前は, mi要素として表現されるべきです.

The names of symbolic constants should be represented as mi elements:

<mi> π </mi>

3.2.4 数字 <mn>
Number <mn> 説明

mn要素は, 数値の文字列や数値の文字列として描画されるべき他のデータを表します. 一般に言って, 数値の文字列は数字の列で, 場合によっては小数点を含み, 符号の付かない整数または実数を表します. 典型的な画像描画ソフトウェアは, mn要素を(moのような隣接する要素との間の空白以外の)周囲の空白を取り除いて, その中身を描画します(3.2.1 素子要素の内容となる文字, <mglyph/>参照). mn要素は典型的に, 傾いていない字形で描画されます.

An mn element represents a numeric literal or other data that should be rendered as a numeric literal. Generally speaking, a numeric literal is a sequence of digits, perhaps including a decimal point, representing an unsigned integer or real number. A typical graphical renderer would render an mn element as its content (see 3.2.1 Token Element Content Characters, <mglyph/>), with no extra spacing around them (except spacing from neighboring elements such as mo). mn elements are typically rendered in an unslanted font.

"数字"の数学上の概念は, 完全にあいまいで複雑な内容になるでしょう. 結果として, 全ての数学の数字が, mnを用いて表されるべきということではありません. 違った表現とされるべき数学の数字の例は下記に示すもので, 複素数, 分数として表される数字の比率, 数値の定数の名前を含みます.

The mathematical concept of a number can be quite subtle and involved, depending on the context. As a consequence, not all mathematical numbers should be represented using mn; examples of mathematical numbers that should be represented differently are shown below, and include complex numbers, ratios of numbers shown as fractions, and names of numeric constants.

反対に, mnはプレゼンテーション要素であるので, mnの中身が何らかの文字を含んでいることが望ましい場合がわずかにあります. 文字列としての数字の特に標準的なコード化によれば, 中身が数字として明確に解釈されない場合であっても, mnは単に数値の文字列として描画されるべきです. 一般的な決まりとして, mn要素は、中身が何らかの方法で実際に数値的な量を表そうとしてる状況に当てられるべきです. 要素の意味が数学の数字の特定の種類であることが保証されている要素については, 4. コンテントマークアップcnの説明を参照して下さい.

Conversely, since mn is a presentation element, there are a few situations where it may be desirable to include arbitrary text in the content of an mn that should merely render as a numeric literal, even though that content may not be unambiguously interpretable as a number according to any particular standard encoding of numbers as character sequences. As a general rule, however, the mn element should be reserved for situations where its content is actually intended to represent a numeric quantity in some fashion. For an element whose semantics are guaranteed to be that of a particular kind of mathematical number, see the description of cn in 4. Content Markup. 属性

mn要素は, 3.2.2 素子要素に共通の数学書式属性で一覧にした属性を持っています.

mn elements accept the attributes listed in 3.2.2 Mathematics style attributes common to token elements.
<mn> 2 </mn>
<mn> 0.123 </mn>
<mn> 1,000,000 </mn>
<mn> 2.1e10 </mn>
<mn> 0xFFEF </mn>
<mn> MCMLXIX </mn>
<mn> twenty-one </mn>
twenty-one <mn>単独で書かれるべきではない数字
Numbers that should not be written using <mn> alone

多くの数学の数字は, mn単独ではなく, プレゼンテーション要素を使用して表されるべきです. それらの数字は, 複素数, 負の数, 分数として表される数字の比率, 数値の定数の名前を含みます.

Many mathematical numbers should be represented using presentation elements other than mn alone; this includes complex numbers, negative numbers, ratios of numbers shown as fractions, and names of numeric constants. 数字の複雑な表現の例
Examples of complex representations of numbers
  <mn> 2 </mn>
  <mo> + </mo>
    <mn> 3 </mn>
    <mo> &#x2062;<!--InvisibleTimes--> </mo>
2 + 3
<mfrac> <mn> 1 </mn> <mn> 2 </mn> </mfrac>
1 2
<mi> π </mi>

3.2.5 演算子, かっこ, 区切り, アクセント <mo> ~ H. 作業部会メンバーおよび謝辞


I. 変更点

I.1 MathML3.0第2版とMathML4.0の間の変更点
Changes between MathML 3.0 Second Edition and MathML 4.0

Changes to the Frontmatter

  • 新しいW3C仕様書の決まりに合致し, 特に目次の書式に影響する新しいW3CCSS書式を使用するよう, 参照を変更.
    Changes to the references to match new W3C specification rules, and to use the new W3C CSS formatting style, most notably affecting the table of contents styling.
  • 最新のW3C発行物で要求されている, 特にhttpsを使用し, GitHub Issuesページを参照するよう, この文章の位置付けを更新.
    Update the Status of This Document, in particular using https and referencing the GitHub Issues page as required for current W3C publications.
  • MathMLの色や長さを表す属性値を, CSS3で提供された定義を利用するのと同様の, [MathMLコア]で使用される構文に明確に基づくように修正.
    Modified the definition of MathML color and length valued attributes to be explicitly based on the syntax used in [MathML-Core] which in turn uses definitions provided by CSS3.
  • <math>からmode属性とmacros属性を削除しました. これらの属性は, MathML 2から非推奨となっていました. macrosは挙動が何も定義されておらず, modedisplayを使用したより適切な形に置き換えることができます. mathml4-legacy構文は, 従来のアプリケーションソフトウェアで必要ならば, それらの属性を有効にします.
    Remove the mode and macros attributes from <math>. These have been deprecated since MathML 2. macros had no defined behaviour, and mode can be replaced by suitable use of display. The mathml4-legacy schema makes these valid if needed for legacy applications.
  • の例を, 描画されるごとに現れるように分割.
    Separate the examples in Examples and Examples to improve their appearance when rendered.
  • 負の数がはっきりとmo演算子と一緒に記述されるべきであることを, <mn>単独で書かれるべきではない数字の中で明確化.
    Clarify that negative numbers should be marked up with an explicit mo operator in Numbers that should not be written using <mn> alone.
  • 属性の割り算の名称の訂正.
    Correct the long division notation names in Attributes.
  • 3.4.7 前置の添え字とテンソル添え字 <mmultiscripts>, <mprescripts/>, <none/> <munder>の中で, 添え字の水平方向の位置揃えを基となる式の方向であることを明確化, 新しい例の追加.
    Clarify that the horizontal alignment of scripts in 3.4.7 Prescripts and Tensor Indices <mmultiscripts>, <mprescripts/>, <none/> <munder> is towards the base, and add a new example.
  • 素子要素の非推奨のMathML 1属性fontfamily, fontweight, fontstyle, fontsize, color, backgroundを削除し, mathvariant, mathsize, mathcolor, mathbackgroundを利用するようにしました. これらの属性は, mstyleでもはや有効ではありません. mathml4-legacy構文は, 従来のアプリケーションソフトウェアで必要ならば, それらの属性を有効にします.
    The deprecated MathML 1 attributes on token elements: fontfamily, fontweight, fontstyle, fontsize, color and background are removed in favor of mathvariant, mathsize, mathcolor and mathbackground. These attributes are also no longer valid on mstyle. The mathml4-legacy schema makes these valid if needed for legacy applications.
  • MathMLで画像を含むためにまだ残されているmglyphから, 全ての非推奨のフォントに関連する属性が削除されました.
    All the deprecated font related attributes have been dropped from mglyph which is still retained to include images in MathML.
  • (newlineと等価だった)indentingnewlineの値は, mspaceではもはや有効ではありません.
    The value indentingnewline is no longer valid for mspace (it was equivalent to newline).
  • MathMLの表では, 行や要素はmtrmtdではっきり記述しなければなりません. [MathML1]は, 行の記述が省略された場合に, その記述を推測する実装を必要としていました.
    In MathML table rows and cells must be explicitly marked wih mtr and mtd. The [MathML1] required that an implementation infer the row markup if it was omitted.
  • malignmarkの利用が, 既存の実装で実装された機能に合致する場合に限定され, 単純化されました. 表におけるgroupalign属性には, もはや対応していません.
    The use of malignmark has been restricted and simplified, matching the features implemented in existing implementations. The groupalign attribute on table elements is no longer supported.
  • 数式に対するマークアップ言語の混在から名前が変わった章.
    Renamed Chapter from Mixing Markup Languages for Mathematical Expressions
  • intent属性について説明する新しい節5.1 intent属性の導入.
    Introduced new section 5.1 The intent attribute describing the intent attribute.
  • プレゼンテーションMathMLとコンテントMathMLを混在させるために<semantics>要素を利用する場合についての既存の文章は, 2番目の節で維持管理されている一方, 規範的でない文章と例を[MathMLメモ]に移動させることで減らされました.
    The existing text on using the <semantics> element to mix Presentation and Content MathML is maintained in the second section, although reduced with some non normative text and examples moved to [MathML-Notes].
  • MathML 3は, <semantics>におけるencodingdefinitionURLの利用を非推奨にしていました. それらの属性は, この仕様書では無効です. mathml4-legacy構文は, 従来のアプリケーションソフトウェアで必要ならば, それらの属性を有効にします.
    MathML 3 deprecated the use of encoding and definitionURL on <semantics>. They are invalid in this specification. The mathml4-legacy schema may be used if these attributes need to be validated for a legacy application.
  • メディアタイプ登録がこの仕様書の付録から, 分割された文書[MathMLメディアタイプ]に移行されたことから, 一部文書を書き直したり, 参照を調整したりしました.
    Some rewriting of the text and adjusting references as the Media type registrations have been moved from an Appendix of this specification to a separate document, [MathML-Media-Types].

Changes to Media Types

  • メディアタイプ登録は, この仕様書の付録から, 分割された文書[MathMLメディアタイプ]に移行しました.
    Media type registrations have been moved from an Appendix of this specification to a separate document, [MathML-Media-Types].
  • 構文は, MathML4に合致するよう更新されました.
    The schema was updated to match MathML4
  • 構文は, mathml4-presentationの基礎として使用され, [MathMLコア]に合致する新しいmathml4-core構文や, [MathML3]に合致する文書の既存の主要部分を有効とするのに使用される新しいmathml4-legacy構文に再整理されました.
    The schema was refactored with a new mathml4-core schema matching [MathML-Core] being used as the basis for mathml4-presentation, and a new mathml4-legacy schema that can be used to validate an existing corpus of documents matching [MathML3].
  • 要素の優先度や周囲の空白の大きさが, 再検討され, 調整されました.
    The spacing values and priorities of the elements were reviewed and adjusted.
  • 新しいcompact表現が, 以前から使われていた表の表現と同様に提供されました.
    A new compact presentation is provided as well as the tabular presentation used previously.
  • 基礎となるデータのファイルがユニコード14/15に更新されました.
    The underlying data files were updated to Unicode 14/15.
  • この新しい節は, アクセシビリティに関連する要件や課題を1箇所にまとめました.
    This new appendix collects together requirements and issues related to accessibility.
  • この新しい節は, OpenMathの構文の表やOpenMathとの対応, また, 以前4. コンテントマークアップの至る所で説明されていた書き換えの決まりを1箇所にまとめました.
    These new appendices collect together the syntax tables, mappings to OpenMath and rewrite rules that were previously distributed throughout 4. Content Markup.

J. 参考文献

J.1 規範となる参考文献
Normative references

ユニコード双方向アルゴリズム. Mark Davis, Aharon Lanin, Andrew Glass 著. ユニコードコンソーシアム. 2021年8月27日. Unicode Standard Annex #9(訳注:"ユニコード標準付録#9"という意味). URL: https://www.unicode.org/reports/tr9/tr9-44.html
Unicode Bidirectional Algorithm. Mark Davis; Aharon Lanin; Andrew Glass. Unicode Consortium. 27 August 2021. Unicode Standard Annex #9. URL: https://www.unicode.org/reports/tr9/tr9-44.html
CSS Color Module Level 3(訳注:"CSS色モジュール"の意味). Tantek Çelik; Chris Lilley, David Baron 著. W3C. 2022年1月18日. W3C勧告. URL: https://www.w3.org/TR/css-color-3/
CSS Color Module Level 3. Tantek Çelik; Chris Lilley; David Baron. W3C. 18 January 2022. W3C Recommendation. URL: https://www.w3.org/TR/css-color-3/
CSS Values and Units Module Level 3(訳注:"CSS値と単位モジュール"の意味). Tab Atkins Jr., Elika Etemad 著. W3C. 2019年6月6日. W3C勧告候補. URL: https://www.w3.org/TR/css-values-3/
CSS Values and Units Module Level 3. Tab Atkins Jr.; Elika Etemad. W3C. 6 June 2019. W3C Candidate Recommendation. URL: https://www.w3.org/TR/css-values-3/
Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. Bert Bos, Tantek Çelik, Ian Hickson, Håkon Wium Lie 著. W3C. 2011年6月7日. W3C勧告. URL: https://www.w3.org/TR/CSS21/
Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. Bert Bos; Tantek Çelik; Ian Hickson; Håkon Wium Lie. W3C. 7 June 2011. W3C Recommendation. URL: https://www.w3.org/TR/CSS21/
NIST Digital Library of Mathematical Functions, Release 1.1.5(訳注:"NIST 数学関数の電子辞書 1.1.5版"の意味). F. W. J. Olver, A. B. Olde Daalhuis, D. W. Lozier, B. I. Schneider, R. F. Boisvert, C. W. Clark, B. R. Miller, B. V. Saunders; H. S. Cohl, M. A. McClain 著. 2022年03月15日. URL: http://dlmf.nist.gov/
NIST Digital Library of Mathematical Functions, Release 1.1.5. F. W. J. Olver; A. B. Olde Daalhuis; D. W. Lozier; B. I. Schneider; R. F. Boisvert; C. W. Clark; B. R. Miller; B. V. Saunders; H. S. Cohl; M. A. McClain. 2022-03-15. URL: http://dlmf.nist.gov/
文字に対するXML実体の定義(第2版). David Carlisle, Patrick D F Ion 著. W3C. 2014年4月10日. W3C勧告. URL: https://www.w3.org/TR/xml-entity-names/
XML Entity Definitions for Characters (2nd Edition). David Carlisle; Patrick D F Ion. W3C. 10 April 2014. W3C Recommendation. URL: https://www.w3.org/TR/xml-entity-names/
HTML Standard(訳注:"HTML標準"の意味). Anne van Kesteren, Domenic Denicola, Ian Hickson, Philip Jagenstedt, Simon Pieters 著. WHATWG. Living Standard(訳注:"日々更新される基準"の意味). URL: https://html.spec.whatwg.org/multipage/
HTML Standard. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
ハイパーテキスト転送プロトコル (HTTP/1.1): メッセージの構文と経路制御. R. Fielding, Ed., J. Reschke, Ed.著. IETF. 2014年7月. 標準化への提唱. URL: https://httpwg.org/specs/rfc7230.html
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html
Infra Standard(訳注:"基盤標準"の意味). Anne van Kesteren, Domenic Denicola 著. WHATWG. Living Standard(訳注:"日々更新される基準"の意味). URL: https://infra.spec.whatwg.org/
Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
国際化資源識別子(IRIs). M. Duerst, M. Suignard 著. IETF. 2005年1月. 標準化への提唱. URL: https://www.rfc-editor.org/rfc/rfc3987
Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. January 2005. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc3987
MathMLアクセシビリティAPIの対応付け 1.0. W3C. W3C編集者草案. URL: https://w3c.github.io/mathml-aam/
MathML Accessiblity API Mappings 1.0. W3C. W3C Editor's Draft. URL: https://w3c.github.io/mathml-aam/
MathMLコア. David Carlisle, Frédéric Wang 著. W3C. 2022年5月4日. W3C草案. URL: https://www.w3.org/TR/mathml-core/
MathML Core. David Carlisle; Frédéric Wang. W3C. 4 May 2022. W3C Working Draft. URL: https://www.w3.org/TR/mathml-core/
MathMLメディアタイプ宣言. W3C. W3C編集者草案. URL: https://w3c.github.io/mathml-docs/mathml-media-types/
MathML Media-type Declarations. W3C. W3C Editor's Draft. URL: https://w3c.github.io/mathml-docs/mathml-media-types/
XML名前空間(第3版). Tim Bray, Dave Hollander, Andrew Layman, Richard Tobin, Henry Thompson, 他 著. W3C. 2009年12月8日. W3C勧告. URL: https://www.w3.org/TR/xml-names/
Namespaces in XML 1.0 (Third Edition). Tim Bray; Dave Hollander; Andrew Layman; Richard Tobin; Henry Thompson et al. W3C. 8 December 2009. W3C Recommendation. URL: https://www.w3.org/TR/xml-names/
The OpenMath Standard(訳注:"OpenMath標準 "という意味). S. Buswell, O. Caprotti, D. P. Carlisle, M. C. Dewar, M. Gaëtano, M. Kohlhase, J. H. Davenport, P. D. F. Ion, T. Wiesing 著. OpenMath協会. 2019年7月. URL: https://openmath.org/standard/om20-2019-07-01/omstd20.html
The OpenMath Standard. S. Buswell; O. Caprotti; D. P. Carlisle; M. C. Dewar; M. Gaëtano; M. Kohlhase; J. H. Davenport; P. D. F. Ion; T. Wiesing. The OpenMath Society. July 2019. URL: https://openmath.org/standard/om20-2019-07-01/omstd20.html
情報技術 -- 文書スキーマ定義言語(DSDL) -- 第2部: 正規文法に基づく妥当性検証 -- RELAX NG. ISO/IEC. 2008年. URL: http://standards.iso.org/ittf/PubliclyAvailableStandards/c052348_ISO_IEC_19757-2_2008(E).zip
Information technology -- Document Schema Definition Language (DSDL) -- Part 2: Regular-grammar-based validation -- RELAX NG. ISO/IEC. 2008. URL: http://standards.iso.org/ittf/PubliclyAvailableStandards/c052348_ISO_IEC_19757-2_2008(E).zip
多目的インターネットメール拡張(MIME)第1部: インターネットメッセージ本体のフォーマット. N. Freed, N. Borenstein 著. IETF. 1996年11月. 標準化への草稿. URL: https://www.rfc-editor.org/rfc/rfc2045
Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. N. Freed; N. Borenstein. IETF. November 1996. Draft Standard. URL: https://www.rfc-editor.org/rfc/rfc2045
多目的インターネットメール拡張(MIME)第1部: メディア型. N. Freed, N. Borenstein 著. IETF. 1996年11月. 標準化への草稿. URL: https://www.rfc-editor.org/rfc/rfc2046
Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed; N. Borenstein. IETF. November 1996. Draft Standard. URL: https://www.rfc-editor.org/rfc/rfc2046
要求レベル指示のためのRFC用キーワード. S. Bradner著. IETF. 1997年3月. 現時点における最善の実践(ベストカレントプラクティス). URL: https://www.rfc-editor.org/rfc/rfc2119
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
統一資源識別子(URI): 一般的構文. T. Berners-Lee, R. Fielding, L. Masinter著. IETF. 2005年1月. インターネット標準. URL: https://www.rfc-editor.org/rfc/rfc3986
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3986
XMLメディアタイプ. H. Thompson, C. Lilley著. IETF. 2014年7月. 標準化への提唱. URL: https://www.rfc-editor.org/rfc/rfc7303
XML Media Types. H. Thompson; C. Lilley. IETF. July 2014. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7303
RFC 2119キーワードの大文字と小文字のあいまいさ. B. Leiba 著. IETF. 2017年5月. 現時点における最善の実践(ベストカレントプラクティス). URL: https://www.rfc-editor.org/rfc/rfc8174
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
Scalable Vector Graphics (SVG) 1.1 (第2版). Erik Dahlström, Patrick Dengler, Anthony Grasso, Chris Lilley, Cameron McCormack, Doug Schepers, Jonathan Watt, Jon Ferraiolo, Jun Fujisawa, Dean Jackson 他 著. W3C. 2011年8月16日. W3C 勧告. URL: https://www.w3.org/TR/SVG11/
Scalable Vector Graphics (SVG) 1.1 (Second Edition). Erik Dahlström; Patrick Dengler; Anthony Grasso; Chris Lilley; Cameron McCormack; Doug Schepers; Jonathan Watt; Jon Ferraiolo; Jun Fujisawa; Dean Jackson et al. W3C. 16 August 2011. W3C Recommendation. URL: https://www.w3.org/TR/SVG11/
ユーザーエージェントアクセシビリティガイドライン(UAAG) 2.0. James Allan, Greg Lowney, Kimberly Patch, Jeanne F Spellman 著. W3C. 2015年12月15日. W3C作業部会メモ. URL: https://www.w3.org/TR/UAAG20/
User Agent Accessibility Guidelines (UAAG) 2.0. James Allan; Greg Lowney; Kimberly Patch; Jeanne F Spellman. W3C. 15 December 2015. W3C Working Group Note. URL: https://www.w3.org/TR/UAAG20/
ユニコード標準. ユニコードコンソーシアム. URL: https://www.unicode.org/versions/latest/
The Unicode Standard. Unicode Consortium. URL: https://www.unicode.org/versions/latest/
ウェブコンテンツアクセシビリティガイドライン(WCAG) 2.1. Andrew Kirkpatrick, Joshue O'Connor, Alastair Campbell, Michael Cooper 著. W3C. 2018年6月5日. W3C勧告. URL: https://www.w3.org/TR/WCAG21/
Web Content Accessibility Guidelines (WCAG) 2.1. Andrew Kirkpatrick; Joshue O'Connor; Alastair Campbell; Michael Cooper. W3C. 5 June 2018. W3C Recommendation. URL: https://www.w3.org/TR/WCAG21/
拡張可能なマーク付け言語(XML)1.0(第5版). Tim Bray, Jean Paoli, Michael Sperberg-McQueen, Eve Maler, François Yergeau 他 著. W3C. 2008年11月26日. W3C勧告. URL: https://www.w3.org/TR/xml/
Extensible Markup Language (XML) 1.0 (Fifth Edition). Tim Bray; Jean Paoli; Michael Sperberg-McQueen; Eve Maler; François Yergeau et al. W3C. 26 November 2008. W3C Recommendation. URL: https://www.w3.org/TR/xml/
XMLスキーマ 第2部: データ型 第2版. Paul V. Biron, Ashok Malhotra 著. W3C. 2004年10月28日. W3C勧告. URL: https://www.w3.org/TR/xmlschema-2/
XML Schema Part 2: Datatypes Second Edition. Paul V. Biron; Ashok Malhotra. W3C. 28 October 2004. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema-2/
XML スキーマ 第1部: 構造 第2版. Henry Thompson, David Beech, Murray Maloney, Noah Mendelsohn 他 著. W3C. 2004年10月28日. W3C勧告. URL: https://www.w3.org/TR/xmlschema-1/
XML Schema Part 1: Structures Second Edition. Henry Thompson; David Beech; Murray Maloney; Noah Mendelsohn et al. W3C. 28 October 2004. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema-1/

J.2 有益な参考文献
Informative references

MathMLにおけるメモ. W3C. メモ. URL: https://w3c.github.io/mathml-docs/notes-on-mathml/
Notes on MathML. W3C. note. URL: https://w3c.github.io/mathml-docs/notes-on-mathml/
MathML 2.0における構造化された型. Stan Devitt, Michael Kohlhase, Max Froumentin 著. W3C. 2003年11月10日. W3C作業部会メモ. URL: https://www.w3.org/TR/mathml-types/
Structured Types in MathML 2.0. Stan Devitt; Michael Kohlhase; Max Froumentin. W3C. 10 November 2003. W3C Working Group Note. URL: https://www.w3.org/TR/mathml-types/
数学用マークアップ言語(MathML)1.0仕様書. Patrick D F Ion, Robert R Miner 著. W3C. 1998年4月7日. W3C勧告. URL: https://www.w3.org/TR/1998/REC-MathML-19980407/
Mathematical Markup Language (MathML) 1.0 Specification. Patrick D F Ion; Robert R Miner. W3C. 7 April 1998. W3C Recommendation. URL: https://www.w3.org/TR/1998/REC-MathML-19980407/
数学用マークアップ言語 (MathML) ヴァージョン 3.0 第2版. David Carlisle, Patrick D F Ion, Robert R Miner 著. W3C. 2014年4月10日. W3C勧告. URL: https://www.w3.org/TR/MathML3/
Mathematical Markup Language (MathML) Version 3.0 2nd Edition. David Carlisle; Patrick D F Ion; Robert R Miner. W3C. 10 April 2014. W3C Recommendation. URL: https://www.w3.org/TR/MathML3/
XHTML™ モジュール化 1.1. Daniel Austin, Subramanian Peruvemba, Shane McCarron, Masayasu Ishikawa, Mark Birbeck 他 著. W3C. 2008年8月8日. W3C勧告. URL: https://www.w3.org/TR/2008/REC-xhtml-modularization-20081008/
XHTML™ Modularization 1.1. Daniel Austin; Subramanian Peruvemba; Shane McCarron; Masayasu Ishikawa; Mark Birbeck et al. W3C. 8 October 2008. W3C Recommendation. URL: https://www.w3.org/TR/2008/REC-xhtml-modularization-20081008/
Resource Description Framework (RDF): 概念および抽象構文. Graham Klyne, Jeremy Carroll 著. W3C. 2004年2月10日. W3C勧告. URL: https://www.w3.org/TR/rdf-concepts/
Resource Description Framework (RDF): Concepts and Abstract Syntax. Graham Klyne; Jeremy Carroll. W3C. 10 February 2004. W3C Recommendation. URL: https://www.w3.org/TR/rdf-concepts/
XHTML™ 1.0 拡張可能ハイパーテキストマークアップ言語(第2版). Steven Pemberton 著. W3C. 2018年3月27日. W3C勧告. URL: https://www.w3.org/TR/xhtml1/
XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition). Steven Pemberton. W3C. 27 March 2018. W3C Recommendation. URL: https://www.w3.org/TR/xhtml1/
An XHTML + MathML + SVG Profile. Masayasu Ishikawa 著. W3C. 2002年8月9日. W3C草案. URL: https://www.w3.org/TR/XHTMLplusMathMLplusSVG/
An XHTML + MathML + SVG Profile. Masayasu Ishikawa. W3C. 9 August 2002. W3C Working Draft. URL: https://www.w3.org/TR/XHTMLplusMathMLplusSVG/
XML リンク言語 (XLink) ヴァージョン 1.0. Steven DeRose, Eve Maler, David Orchard 著. W3C. 2001年6月27日. W3C勧告. URL: https://www.w3.org/TR/xlink/
XML Linking Language (XLink) Version 1.0. Steven DeRose; Eve Maler; David Orchard. W3C. 27 June 2001. W3C Recommendation. URL: https://www.w3.org/TR/xlink/