math ElementMathMLは[XML]、すなわち拡張可能マークアップ言語のアプリケーションであり、従ってXML構文規則に支配されます。 XML構文は、ルート(根)を有するラベル付き平面木のための表記です。 ここで、平面とは、ノードの子が自然な順序で解釈されることを意味し、MathMLもこの順序に従います。
MathMLの基本的な「構文」は、このようにXMLによって定義されています。 その上で、許容される要素やその順序、その親子関係といった規則としての「文法」や、属性値に関する追加的な構文規則を重ねています。 これらの規則は本仕様で定義され、RelaxNGスキーマ [RELAX-NG] によって形式化されます。 標準的なものはRelaxNGスキーマですが、DTD(文書型定義)及びXMLスキーマ[XMLSchemas]も継続性の観点から提供されています(DTD及びXMLスキーマはMathML2においては標準の一部でした)。 付録A MathMLのパースもご覧ください。
XMLボキャブラリーであるMathMLの文字集合は、Unicode [Unicode]で規定される有効な文字でなければなりません。 Unicode文字の数学における利用については、 第7章 文字、実体及び書体 で論じています。
以下の節では、MathMLの文法の一般的な側面について論じるとともに、属性値に使われる構文について述べています。
XML名前空間[Namespaces]とは、URIによって特定可能な名前の集合です。 MathML名前空間のURIは、
http://www.w3.org/1998/Math/MathML
です。
名前空間を宣言するためには、xmlns属性を用いるか、属性にxmlns接頭辞を付した属性を用います。
xmlns属性が単独で用いられた場合、その要素のデフォルトの名前空間が設定され、その子要素にも適用されます。
たとえば:
<math xmlns="http://www.w3.org/1998/Math/MathML"> <mrow>...</mrow> </math>
xmlns属性が接頭辞として使われる場合、他の要素や属性を特定の名前空間に明示的に結びつけられる接頭辞を宣言することになります。
たとえば、MathMLをXHTML中に埋め込む場合、以下のように使うことができます:
<body xmlns:m="http://www.w3.org/1998/Math/MathML"> ... <m:math><m:mrow>...</m:mrow></m:math> ... </body>
ほとんどのMathML要素は「コンテナー」として振る舞います。
つまり、ある要素の子は、子のリストの個々の要素として以外、他の子と区別することができません。
一般的には要素が持ちうる子の数には制限がなく、これはほとんどのプレゼンテーション要素やsetのようなコンテンツ要素の一部に当てはまります。
しかし、特定の数の子を要するMathML要素も多く存在し、特定の位置の子に特別な意味を持たせています。
そうした要素は数学オブジェクトのコンストラクターを表現するものと考えるのが最適で、従って、その子に対する「機能」として考えることができます。
このため、MathML要素の子は、しばしば単なる子ではなく引数と呼ばれます。
これらの例は、たとえば 第3.1.3節 必須引数 などにあります。
概念的には引数を一つだけとるものの、便利のため、子をいくつでもとれるよう書かれているプレゼンテーション要素もあります。
この場合、暗黙のmrowがこれらの子を含んで、当該要素への引数として振る舞うものとします。
第3.1.3.1節 暗黙の<mrow>もご覧ください。
それぞれの要素についての構文の詳細な議論、子と引数の対応、必要な引数の数とその順序、及び内容に関する制限等は、MathML仕様のいたる所で明確化しています。 この情報は、プレゼンテーション要素については、第3.1.3節 必須引数で一覧表になっています。
MathMLのプレゼンテーション要素は、特定のレンダリング方法を推奨しますが必須ではありません。 このことにより、メディア依存のレンダリングや個人の好みのスタイルの利用が可能になっています。
そうは言うものの、本仕様の一部では、推奨される視覚的レンダリング規則について詳細に述べています。 これらの記述においては、用いられるレンダリングモデルがよく定義された「現在のレンダリング環境」（つまり、特に現在の書体、現在のディスプレイ（ピクセルサイズなど）、現在のベースライン等）をサポートするものとみなされています。 「現在の書体」は、グリフの特定の計量プロパティ及び符号化を提供するものです。
MathML要素は、要素の意味や効果をさらに特徴付ける属性値をとります。
本文書を通し、属性名は等幅の書体で示されています。
属性の意味及びその許容する値は、それぞれの要素の仕様の中で述べられています。
本節で説明する構文表記は、許容する値を明示するのに用いられます。
仕様によって明示的に禁止されている場合を除き、MathMLの属性値はXML勧告によって指定されるどんな文字をも含むことができます。 詳しくは、第7章 文字、実体及び書体 をご覧ください。
属性値のMathML固有の構文を表現するため、以下の表記法がこの文書の多くの属性に用いられています。 以下で、U+から始まる表記はUnicode文字を指しており、これはUnicodeによって推奨される手法です。 ([Unicode] page xxviii をご覧ください)
| 表記 | 該当するもの |
|---|---|
| decimal-digit | U+0030からU+0039までの範囲にある10進の数字 |
| hexadecimal-digit | U+0030からU+0039まで、U+0041からU+0046まで、及びU+0061からU+0066までの範囲にある16進の数字 |
| unsigned-integer | decimal-digitからなる文字列で、非負整数を表すもの |
| positive-integer | decimal-digitからなる文字列で、"0" (U+0030)のみのものを含まない、正の整数を表すもの |
| integer | 省略可能な "-" (U+002D)及びそれに続くdecimal digitからなる文字列で、整数を表すもの |
| unsigned-number | decimal digit及び最大1つの小数点 (U+002E) を含む文字列で、非負の有限小数（有理数の一種）を表すもの |
| number | 省略可能な "-" (U+002D)及びそれに続く非負数unsigned numberで、有限小数（有理数の一種）を表すもの |
| character | 1個の空白ではない文字 |
| string | 任意で、空ではなく有限のcharacterの列 |
| length | 長さ。以下第2.1.5.2節 長さを値にとる属性で説明される |
| unit | 単位。主として長さの一部に使われる。以下第2.1.5.2節 長さを値にとる属性で説明される |
| namedlength | 名前付き長さ。以下第2.1.5.2節 長さを値にとる属性で説明される |
| color | 色。以下第2.1.5.3節 色を値にとる属性で説明される |
| id | 識別子で、文書中で固有なもの。XML勧告[XML]のNAME構文を満たさなければならない |
| idref | 文書中の他の要素を参照する識別子。XML勧告[XML]のNAME構文を満たさなければならない |
| URI | 統一資源識別子(Uniform Resource Identifier) [RFC3986]。 属性値がanyURIによるスキーマで記載され、XML文字のいかなる順序も許容することに注意してください。 この文字列をURIとして利用する必要のあるシステムは、URIとして使えない文字をUTF-8符号化した各バイトを、%HH符号化(HHは16進数のバイト値)により符号化しなければなりません。 このことにより、属性値をIRI、より一般的にはLEIRIとして解釈できるようになります。 [IRI]を参照してください。 |
| italicized word | それぞれの属性のテキストで説明される値。 第2.1.5.4節 属性のデフォルト値を参照してください。 |
| "literal" | 引用された記号で、属性値の中で文字通り表現されるもの (例: "+" または '+') |
以上で述べた「型」は、stringを除き、下表の演算子を用いて複合的なパターンを構成することができます。 マークアップ文書中では、属性値は、一重引用符(')または二重引用符(")で囲まなければなりません。 二重引用符は、この仕様書中ではリテラル表現のマークアップに使われることに注意してください。 たとえば、上の表中第5行における "-" などです。
下表では、fという形式は、上の表で述べた型のインスタンスを意味します。 結合演算子は優先順に、最も高いものから低いものまで示されています:
| 表記 | 該当するもの |
|---|---|
| ( f ) | f と同じ |
f? |
省略可能なfのインスタンス |
f * |
f の0個以上のインスタンスで、空白文字により区切られる。 |
| f + | f の1個以上のインスタンスで、空白文字により区切られる。 |
| f1 f2 ... fn | fiそれぞれのインスタンス1つずつを並べたもの。空白文字で区切らない。 |
| f1, f2, ..., fn | fiそれぞれのインスタンス1つずつを並べたもの。空白文字により区切られる(コンマは使わない)。 |
| f1 | f2 | ... | fn | 指定された形式fiのいずれか一つ。 |
ここで使われている表記は、MathMLの基本的なスキーマに使われるRelaxNGの構文表記のスタイルです。 付録A MathMLのパースをご覧ください。
一部のアプリケーションでは空白の正規化について統一されていないので、相互運用性の観点から、属性値の中で値を区切る場合は、空白を一つのみ用いることが推奨されます。 さらに、属性値の前後の空白は避けられるべきです。
数値の属性のほとんどは、表現可能な値の範囲に含まれるものしか意味を持ちません。 つまり、この範囲外の値は、他所で指定される場合を除いてエラーにはならず、 レンダラーの判断によって、許容される範囲内のもっとも近い値に丸められるでしょう。 許容される値の範囲はレンダラーに依存しており、MathMLの定めるものではありません。
上で述べた属性値構文でマイナス記号 ('-') を含むことが許容されていると宣言されている数字の値、
たとえば numberやinteger については、
負の値が意味を持たない場合でも、その値自体は構文エラーにはなりません。
むしろその値は処理アプリケーションによって前段落で述べたように扱われるべきです。
明示的な正の符号 ('+') は、 (引用符付きの '+' または "+" として) 構文に明示的に含まれている場合を除き、数字の値としては認められません。
また、その出現は属性値の意味を変えることがあります (符号を許容する属性ごとに文書化されています)。
多くのプレゼンテーション要素は、サイズやスペーシング等のプロパティに用いるため、長さを表現する値をとる属性を持ちます。 長さの構文は、以下のように規定されます。
| 型 | 構文 |
|---|---|
| length | number | number unit | namedspace |
数字と長さの単位の間には、空白を含めるべきではありません。
取り得る unit 及び namedspace、及びその解釈を以下に示します。
単位及びその意味はCSSから派生していますが、その構文は同じではないことに注意してください。
MathML要素の中には、追加的なキーワードを含むことのできる長さの属性を持つものがあります。
これらは、疑単位と呼ばれ、特定の要素の説明の中で規定されています。
たとえば、第3.3.6節 Adjust Space Around Content <mpadded>をご覧ください。
属性値の最後の "%" は、デフォルト値の百分率を表します。 デフォルト値またはその求め方は、それぞれの要素の属性の表に記載しています。 (第2.1.5.4節 属性のデフォルト値もご覧ください。) 単位のない数は、デフォルト値の倍数として解釈されます。 この形式は主として後方互換性のためのものであり、避けるべきで、明確化のため単位を明記することが望ましいです。
場合によっては、特定の属性がとれる値の範囲が制限されているかも知れません。 この場合、近い値への丸め方の実装は自由です。
MathMLにおいて利用できるunitは、以下の通りです。
| 単位 | 説明 |
|---|---|
em |
em (書体関連の単位で、伝統的には水平方向の長さを表す単位) |
ex |
ex (書体関連の単位で、伝統的には垂直方向の長さを表す単位) |
px |
ピクセル。現在のディスプレイにおけるピクセル数 |
in |
インチ (1 インチ = 2.54 センチメートル) |
cm |
センチメートル |
mm |
ミリメートル |
pt |
ポイント (1 ポイント = 1/72 インチ) |
pc |
ピカ (1 ピカ = 12 ポイント) |
% |
デフォルト値の百分率 |
単位の追加的な事項について、さらに 第2.1.5.2.1節 単位に関する補足 で論じています。
以下の定数及びnamedspaceは、長さが必要とされる箇所で用いることができます。 これらは一般的にはトークンのスペーシングまたはパディングに用いられます。 これらの定数の推奨されるデフォルト値が示されていますが、実際のスペーシングは実装依存です。
| namedspace | 推奨されるデフォルト |
|---|---|
veryverythinmathspace |
1/18em |
verythinmathspace |
2/18em |
thinmathspace |
3/18em |
mediummathspace |
4/18em |
thickmathspace |
5/18em |
verythickmathspace |
6/18em |
veryverythickmathspace |
7/18em |
negativeveryverythinmathspace |
-1/18em |
negativeverythinmathspace |
-2/18em |
negativethinmathspace |
-3/18em |
negativemediummathspace |
-4/18em |
negativethickmathspace |
-5/18em |
negativeverythickmathspace |
-6/18em |
negativeveryverythickmathspace |
-7/18em |
MathMLでは、長さはプレゼンテーションのためのみに用いられます。
そしてプレゼンテーションは、最終的には何らかのメディア上でのレンダリングを伴います。
視覚メディアでは、ディスプレイコンテキストはレンダーが利用できるプロパティを持つものと見なされます。
意味のある範囲内で、1 pxはディスプレイ上の1ピクセルに対応します。
ディスプレイ装置の解像度は、ピクセル数とin、cm、mm、pt及びpcの単位との関係に影響します。
さらに、ディスプレイコンテキストからは、デフォルトの書体サイズが得られます。
この書体のパラメータは、単位em及びexの解釈に用いられる初期値を決定するものであり、namedspaceの大きさを間接的に決定します。
これらの単位はディスプレイコンテキスト、特に利用者の表示設定に従うので、一般的には相対的な単位であるem及びexの方がpxやcmといった絶対的な単位よりも好まれます。
しかしここで相対単位の2つの側面について注意が必要でしょう。
まず、第3.4節 Script and Limit Schemataやmfrac等の要素は、その引数に対して、暗黙のうちに小さめの書体サイズを使うことがあります。
同様に、書体サイズを明示的に変更するためにmstyleが用いられることがあります。
このような場合、emやexの実効値は、これらのコンテキストの内外で異なることになります。
第二に、属性値に用いられるemやexの実効値は、書体サイズの変更に影響を受けるということです。
従って、書体サイズを変更することのある属性、たとえばmathsizeやscriptlevel等は、他の長さを持つ属性値よりも先に評価されなければなりません。
視覚メディア以外のメディアにおいて長さがどのように表現されるかは、実装依存です。
プレゼンテーション要素の色、あるいは(つまり?)背景色は、以下の構文を用いてcolorにより指定することができます。
| 型 | 構文 |
|---|---|
| color | #RGB | #RRGGBB | html-color-name |
色は、"#" に続けて赤・緑・青の要素を表す16進の値(空白を含めない)で指定するか、あるいはhtml-color-nameにより指定することができます。
各色の要素は、1桁または2桁のいずれかで指定できますが、赤緑青の3要素すべてが同じ桁数で表現されなければなりません。
各要素は、0 (当該要素を含まない) から FF (当該要素が完全に含まれる) までとることができます。
[CSS21]の色の桁数に関する規定により、たとえば、#123は#112233の短縮形と見なされることに注意してください。
色の値は、html-color-name、すなわち[HTML4] で定義される色名のキーワード（"aqua"、"black"、"blue"、"fuchsia"、"gray"、"green"、"lime"、"maroon"、"navy"、"olive"、"purple"、"red"、"silver"、"teal"、"white"、及び"yellow"）で指定することもできます。 CSS及びHTMLとの互換性のため、他のMathMLの属性値のキーワードとは異なり、これらの色名のキーワードは大文字・小文字が区別されないことに注意してください。
colorが要素に適用されるのは、そのトークンの内容がレンダリングされる際の色です。
加えてこの色は、親要素やMathML表現の周囲の環境から承継される場合、mfracやmtable、msqrtの線や根号記号等、MathML要素によるすべての描画の色を制御します。
背景色の指定に用いられる場合、キーワード「transparent」を用いることも許容されます。
The recommended MathML visual rendering rules do not define the
precise extent of the region whose background is affected by using the
background attribute on an element,
except that, when the element's content does not have
negative dimensions and its drawing region is not overlapped by other
drawing due to surrounding negative spacing, this region should lie
behind all the drawing done to render the content of the
element, but 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 background attribute is not
defined by these rules.
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.
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.)
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.
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.
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.
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.
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.
| Name | 値 | デフォルト |
|---|---|---|
| id | id | none |
Establishes a unique identifier associated with the element
to support linking, cross-references and parallel markup.
See xref and 第5.4節 Parallel Markup.
|
||
| xref | idref | none |
References another element within the document.
See id and 第5.4節 Parallel Markup.
|
||
| class | string | none |
| Associates the element with a set of style classes for use with [XSLT] and [CSS21]. Typically this would be a space separated sequence of words, but this is not specified by MathML. See 第6.5節 Using CSS with MathML for discussion of the interaction of MathML and CSS. | ||
| style | string | none |
| Associates style information with the element for use with [XSLT] and [CSS21]. This typically would be an inline CSS style, but this is not specified by MathML. See 第6.5節 Using CSS with MathML for discussion of the interaction of MathML and CSS. | ||
| href | URI | none |
| Can be used to establish the element as a hyperlink to the specfied URI. | ||
Note that MathML 2 had no direct support for linking, and instead
followed the W3C Recommendation "XML Linking Language"
[XLink] in defining links using the
xlink:href attribute. This has changed, and MathML 3 now
uses an href attribute. However, particular compound
document formats may specify the use of XML linking with MathML
elements, so user agents that support XML linking should continue to
support the use of the xlink:href attribute with MathML 3
as well.
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.
The attribute other,
is deprecated
(第2.3.3節 Attributes for unspecified data) in favor of the use of
attributes from other namespaces.
| Name | 値 | デフォルト |
|---|---|---|
| other | string | none |
| DEPRECATED but in MathML 1.0. | ||
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 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).
For example, <mo> ( </mo> is equivalent to
<mo>(</mo>, and
<mtext> Theorem 1: </mtext>
is equivalent to
<mtext>Theorem 1:</mtext>
or
<mtext>Theorem 1:</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 (U+00A0)
or other non-marking characters that are not trimmed.
For example, compare the above use of an mtext element
with
<mtext>  <!--NO-BREAK SPACE-->Theorem  <!--NO-BREAK SPACE-->1: </mtext>
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:".
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.
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.
math Element
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節 MathMLの移動.
The math element can contain an arbitrary number
of child elements. They render by default as if they
were contained in an mrow element.
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節 すべてのMathML要素に共通の属性.
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節 方向 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.10節 Mathematics style attributes common to presentation elements)
In addition to those attributes, the math element accepts:
| Name | 値 | デフォルト |
|---|---|---|
| display | "block" | "inline" | inline |
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 | length | 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 | none |
| provides a URI referring to an image to display as a fall-back for user agents that do not support embedded MathML. | ||
| altimg-width | length | width of altimg |
specifies the width to display altimg, scaling the image if necessary;
See altimg-height.
|
||
| altimg-height | length | height of altimg |
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 | length | "top" | "middle" | "bottom" | 0ex |
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 | string | none |
| provides a textual alternative as a fall-back for user agents that do not support embedded MathML or images. | ||
| cdgroup | URI | none |
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.
|
||
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:
| Value | Meaning |
|---|---|
| "linebreak" | The 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. |
The following attributes of math are deprecated:
| Name | 値 | デフォルト |
|---|---|---|
| macros | URI * | none |
| intended to provide a way of pointing to external macro definition files. Macros are not part of the MathML specification. | ||
| mode | "display" | "inline" | inline |
specified whether the enclosed MathML expression should be rendered in
a display style or an inline style.
This attribute is deprecated in
favor of the display attribute.
|
||
Information nowadays is commonly generated, processed and rendered by software tools. The exponential growth of the Web is fueling the development of advanced systems for automatically searching, categorizing, and interconnecting information. In addition, there are increasing numbers of Web services, some of which offer technically based materials and activities. Thus, although MathML can be written by hand and read by humans, whether machine-aided or just with much concentration, the future of MathML is largely tied to the ability to process it with software tools.
There are many different kinds of MathML processors: editors for authoring MathML expressions, translators for converting to and from other encodings, validators for checking MathML expressions, computation engines that evaluate, manipulate, or compare MathML expressions, and rendering engines that produce visual, aural, or tactile representations of mathematical notation. What it means to support MathML varies widely between applications. For example, the issues that arise with a validating parser are very different from those for an equation editor.
This section gives guidelines that describe different types of MathML support and make clear the extent of MathML support in a given application. Developers, users, and reviewers are encouraged to use these guidelines in characterizing products. The intention behind these guidelines is to facilitate reuse by and interoperability of MathML applications by accurately setting out their capabilities in quantifiable terms.
The W3C Math Working Group maintains MathML Compliance Guidelines. Consult this document for future updates on conformance activities and resources.
A valid MathML expression is an XML construct determined by the MathML RelaxNG Schema together with the additional requirements given in this specification.
We shall use the phrase "a MathML processor" to mean any application that can accept or produce a valid MathML expression. A MathML processor that both accepts and produces valid MathML expressions may be able to "round-trip" MathML. Perhaps the simplest example of an application that might round-trip a MathML expression would be an editor that writes it to a new file without modifications.
Three forms of MathML conformance are specified:
A MathML-input-conformant processor must accept all valid MathML expressions; it should appropriately translate all MathML expressions into application-specific form allowing native application operations to be performed.
A MathML-output-conformant processor must generate valid MathML, appropriately representing all application-specific data.
A MathML-round-trip-conformant processor must preserve MathML equivalence. Two MathML expressions are "equivalent" if and only if both expressions have the same interpretation (as stated by the MathML Schema and specification) under any relevant circumstances, by any MathML processor. Equivalence on an element-by-element basis is discussed elsewhere in this document.
Beyond the above definitions, the MathML specification makes no demands of individual processors. In order to guide developers, the MathML specification includes advisory material; for example, there are many recommended rendering rules throughout 第3章 プレゼンテーションマークアップ. However, in general, developers are given wide latitude to interpret what kind of MathML implementation is meaningful for their own particular application.
To clarify the difference between conformance and interpretation of what is meaningful, consider some examples:
In order to be MathML-input-conformant, a validating parser needs only to accept expressions, and return "true" for expressions that are valid MathML. In particular, it need not render or interpret the MathML expressions at all.
A MathML computer-algebra interface based on content markup might choose to ignore all presentation markup. Provided the interface accepts all valid MathML expressions including those containing presentation markup, it would be technically correct to characterize the application as MathML-input-conformant.
An equation editor might have an internal data representation that makes it easy to export some equations as MathML but not others. If the editor exports the simple equations as valid MathML, and merely displays an error message to the effect that conversion failed for the others, it is still technically MathML-output-conformant.
As the previous examples show, to be useful, the concept of MathML conformance frequently involves a judgment about what parts of the language are meaningfully implemented, as opposed to parts that are merely processed in a technically correct way with respect to the definitions of conformance. This requires some mechanism for giving a quantitative statement about which parts of MathML are meaningfully implemented by a given application. To this end, the W3C Math Working Group has provided a test suite.
The test suite consists of a large number of MathML expressions categorized by markup category and dominant MathML element being tested. The existence of this test suite makes it possible, for example, to characterize quantitatively the hypothetical computer algebra interface mentioned above by saying that it is a MathML-input-conformant processor which meaningfully implements MathML content markup, including all of the expressions in the content markup section of the test suite.
Developers who choose not to implement parts of the MathML specification in a meaningful way are encouraged to itemize the parts they leave out by referring to specific categories in the test suite.
For MathML-output-conformant processors, information about currently available tools to validate MathML is maintained at the W3C MathML Validator. Developers of MathML-output-conformant processors are encouraged to verify their output using this validator.
Customers of MathML applications who wish to verify claims as to which parts of the MathML specification are implemented by an application are encouraged to use the test suites as a part of their decision processes.
MathML 3.0 contains a number of features of earlier MathML which are now deprecated. The following points define what it means for a feature to be deprecated, and clarify the relation between deprecated features and current MathML conformance.
In order to be MathML-output-conformant, authoring tools may not generate MathML markup containing deprecated features.
In order to be MathML-input-conformant, rendering and reading tools must support deprecated features if they are to be in conformance with MathML 1.x or MathML 2.x. They do not have to support deprecated features to be considered in conformance with MathML 3.0. However, all tools are encouraged to support the old forms as much as possible.
In order to be MathML-round-trip-conformant, a processor need only preserve MathML equivalence on expressions containing no deprecated features.
MathML 3.0 defines three basic extension mechanisms: the mglyph
element provides a way of displaying glyphs for non-Unicode
characters, and glyph variants for existing Unicode characters; the
maction element uses attributes from other namespaces to obtain
implementation-specific parameters; and content markup makes use of
the definitionURL attribute, as well as
Content Dictionaries and the cd attribute, to point to external
definitions of mathematical semantics.
These extension mechanisms are important because they provide a way
of encoding concepts that are beyond the scope of MathML 3.0 as presently
explicitly specified, which
allows MathML to be used for exploring new ideas not yet susceptible
to standardization. However, as new ideas take hold, they may become
part of future standards. For example, an emerging character that
must be represented by an mglyph element today may be
assigned a Unicode code point in the future. At that time,
representing the character directly by its Unicode code point would be
preferable. This transition into Unicode has
already taken place for hundreds of characters used for mathematics.
Because the possibility of future obsolescence is inherent in the
use of extension mechanisms to facilitate the discussion of new ideas,
MathML can reasonably make
no conformance requirements concerning the use of
extension mechanisms, even when alternative standard markup is
available. For example, using an mglyph element to represent
an 'x' is permitted. However, authors and implementers are
strongly encouraged to use standard markup whenever possible.
Similarly, maintainers of documents employing MathML 3.0 extension
mechanisms are encouraged to monitor relevant standards activity
(e.g., Unicode, OpenMath, etc.) and to update documents as more
standardized markup becomes available.
If a MathML-input-conformant application receives
input containing one or more elements with an illegal number or type
of attributes or child schemata, it should nonetheless attempt to
render all the input in an intelligible way, i.e., to render normally
those parts of the input that were valid, and to render error messages
(rendered as if enclosed in an merror element) in place of
invalid expressions.
MathML-output-conformant applications such as
editors and translators may choose to generate merror
expressions to signal errors in their input. This is usually
preferable to generating valid, but possibly erroneous, MathML.
The MathML attributes described in the MathML specification are intended to allow for good presentation and content markup. However it is never possible to cover all users' needs for markup. Ideally, the MathML attributes should be an open-ended list so that users can add specific attributes for specific renderers. However, this cannot be done within the confines of a single XML DTD or in a Schema. Although it can be done using extensions of the standard DTD, say, some authors will wish to use non-standard attributes to take advantage of renderer-specific capabilities while remaining strictly in conformance with the standard DTD.
To allow this, the MathML 1.0 specification [MathML1]
allowed the attribute other on all elements, for use as a hook to pass
on renderer-specific information. In particular, it was intended as a hook for
passing information to audio renderers, computer algebra systems, and for pattern
matching in future macro/extension mechanisms. The motivation for this approach to
the problem was historical, looking to PostScript, for example, where comments are
widely used to pass information that is not part of PostScript.
In the next period of evolution of MathML the
development of a general XML namespace mechanism
seemed to make the use of the other
attribute obsolete. In MathML 2.0, the other attribute is
deprecated in favor of the use of
namespace prefixes to identify non-MathML attributes. The
other attribute remains deprecated in MathML 3.0.
For example, in MathML 1.0, it was recommended that if additional information
was used in a renderer-specific implementation for the maction element
(第3.7.1節 Bind Action to Sub-Expression
<maction>),
that information should be passed in using the other attribute:
<maction actiontype="highlight" other="color='#ff0000'"> expression </maction>
From MathML 2.0 onwards, a color
attribute from another namespace would be used:
<body xmlns:my="http://www.example.com/MathML/extensions"> ... <maction actiontype="highlight" my:color="#ff0000"> expression </maction> ... </body>
Note that the intent of allowing non-standard attributes is not to encourage software developers to use this as a loophole for circumventing the core conventions for MathML markup. Authors and applications should use non-standard attributes judiciously.