<math>要素<math> ElementMathMLの基本となる‘構文’は, XML構文を用いて定義されていますが, 番号付きのツリー構造をコード化できる他の構文も利用可能です. 特にHTML処理プログラムは, MathMLと一緒に利用されるかもしれません. この構文の上に, 要素が現れる順番やどのように要素がお互いの中に含まれるかといった要素に示された決まりや, 属性の値についての追加の構文上の決まりとなる‘文法’を重ねます. それらの決まりはこの仕様書で定義されており, RelaxNGスキーマ[RELAX-NG]により書かれています. RelaxNGスキーマが標準ですが, DTD(文書型宣言)やXMLスキーマ[XMLスキーマ]が継続性のために提供されています(それらはMathML2で標準でした). 付録A MathMLの処理を参照して下さい.
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 [RELAX-NG]. The RelaxNG Schema is normative, but a DTD (Document Type Definition) and an XML Schema [XMLSchemas] are provided for continuity (they were normative for MathML2). See Appendix A Parsing MathML.
MathMLの文字セットはユニコード[ユニコード]で指定された, XMLで利用できな文字により制限された正当な文字から構成されています. 数学でのユニコードの利用については, 第7章 文字, 実体, 書式で論じています.
MathML's character set consists of legal characters as specified by Unicode [Unicode], further restricted by the characters not allowed in XML. The use of Unicode characters for mathematics is discussed in Chapter 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.
XML名前空間[名前空間]はURIによって特定された名前の集合です. MathML名前空間に対するURIは次のとおりです.
An XML namespace [Namespaces] is a collection of names identified by a URI. The URI for the MathML namespace is:
http://www.w3.org/1998/Math/MathML
MathMLのXMLシリアル化(訳注:"名前を一意に定める機能"を意図)を利用した場合に名前空間を宣言するには, xmlns属性を利用するか, もしくはxmlns接頭辞で始まる属性を利用します. 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.
When the xmlns attribute is used alone, it sets
the default namespace for the element on which it
appears, and for any child elements. For example:
<math xmlns="http://www.w3.org/1998/Math/MathML"> <mrow>...</mrow> </math>
xmlns属性を接頭辞として利用する場合, 他の要素と属性を, 特定の名前空間と明確に結び付けるのに利用できる接頭辞を宣言します. XHTMLに埋め込まれた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 XHTML, one might use:
<body xmlns:m="http://www.w3.org/1998/Math/MathML"> ... <m:math><m:mrow>...</m:mrow></m:math> ... </body>
HTMLは同じ方法で名前空間を拡張することに対応しておらず, HTML処理プログラムはHTML, SVG, MathML名前空間について元々組み込まれている情報のみ持っています. したがって, MathMLのHTMLシリアル化を利用する場合, 接頭辞の付いた要素名は使用してはなりません. xmlns="http://www.w3.org/1998/Math/MathML"がmath要素で使用されるかもしれませんが, HTML処理プログラムは無視します. HTML処理プログラムは(無効な入力やannotation-xmlに対して付録A MathMLの処理で述べられている特別な決まりではなくむしろ)いつでもmath要素とその子要素, 孫要素をMathML名前空間に置きます. 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,
which always places math elements and its descendents in the MathML namespace
(other than special rules described in Appendix A Parsing MathMLfor invalid input, and for annotation-xml.
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"> ... </math>
ほとんどのMathML要素は, ‘入れもの’としてふるまいます. そのような要素の子要素は, 子要素の一覧に示された個々の要素でない限り, お互いに区別されません. 一般に, 要素が持てるであろう子要素の数に制限はありません. これは, ほとんどのプレゼンテーション要素とsetのようないくつかのコンテント要素に当てはまります. ただし, たくさんのMathML要素は特定の数の子要素を必要としており, 場所によって子要素に特定の意味を付け加えたりします. そのような要素は, 数学における構築要素を表現すると考えるのが最適なため, その子要素による関数であると考えられます. したがって, しばしばそのようなMathML要素の子要素を単に子要素と呼ぶのではなく引数と呼びます. この例については第3.1.3節 必要な引数の中で示しています.
Most MathML elements act as ‘containers’; such an element's
children are not distinguished from each other except as individual members of the
list of children. Commonly there is no limit imposed on the number of children
an element may have. This is the case for most presentation
elements and some content elements such as set.
But many
MathML elements require a specific number of children, or
attach a particular meaning to children in certain positions.
Such elements are best considered to represent constructors of mathematical
objects, and hence thought of as functions of their children. Therefore
children of such a MathML element
will often be referred to as its arguments instead of merely as children.
Examples of this can be found, say, in Section 3.1.3 Required Arguments.
概念上は, 単独の引数しか持たないプレゼンテーション要素がありますが, 便利なように任意の数を持つように書かれてきました. その場合, 省略されたmrowが疑問にあった要素の引数としてふるまう子要素を囲っています. 第3.1.3.1節 省略された<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 Section 3.1.3.1 Inferred <mrow>s.
MathML仕様書の至るところにある要素それぞれに与えられた要素の構文の詳細な議論において, 子要素と引数の対応, 引数の数と引数の順番, 他の内容についての制約について指定されています. この情報は, 第3.1.3節 必要な引数でプレゼンテーション要素について一覧にしています.
In the detailed discussions of element syntax given with each element throughout the MathML specification, the correspondence of children with arguments, 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 Section 3.1.3 Required Arguments.
MathMLプレゼンテーション要素は, 描画の特定の方法を推奨のみしています(すなわち, 必要であるとはしていません). これは, 媒体に依存した描画や書式の個々の好みを認めるためです.
MathML presentation elements only recommend (i.e., do not require) specific ways of rendering; this is in order to allow for medium-dependent rendering and for individual preferences of style.
にもかかわらず, この仕様書の中には, 推奨している視覚的な描画の決まりを詳細に説明している部分があります. それらの説明では, 実際に利用される'最新の描画環境'の概念に利用される描画モデルが対応していると仮定しています. '最新の描画環境'とは, 特に'最新のフォント', (画素数についての)'最新の画面', '最新のベースライン'(訳注:欧文書体で水平の基準線で大文字の下端の位置)を想定しています. '最新のフォント'は, 確かな定量的な特性や字形のコード化を提供するものとしています.
Nevertheless, some parts of this specification describe these recommended visual rendering rules in detail; in those descriptions it is often assumed that the model of rendering used supports the concepts of a well-defined 'current rendering environment' which, in particular, specifies a 'current font', a 'current display' (for pixel size) and a 'current baseline'. The 'current font' provides certain metric properties and an encoding of glyphs.
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属性の値はXML勧告で指定された何らかの正当な文字を含むでしょう. より詳細については第7章 文字, 実体, 書式を参照して下さい.
Except when explicitly forbidden by the specification for an attribute, MathML attribute values may contain any legal characters specified by the XML recommendation. See Chapter 7 Characters, Entities and Fonts for further clarification.
属性の値についてMathMLで指定された構文を説明するのに, 次に示す慣習と表記がこの文書のほとんどの属性に使用されます. ユニコード文字を参照するのにユニコードで推奨されているU+で始まる表記を下では利用します[[ユニコード] xxviiiページ参照].
To describe the MathML-specific syntax of attribute values, the following conventions and notations are used for most attributes in the present document. We use below the notation beginning with U+ that is recommended by Unicode for referring to Unicode characters [see [Unicode], page xxviii].
| 表記 Notation |
何と一致するか What it matches |
|---|---|
| 10進数の数字 decimal-digit |
U+0030からU+0039の範囲の10進数の数字 a decimal digit from the range U+0030 to U+0039 |
| 16進数の数字 hexadecimal-digit |
U+0030からU+0039, U+0041からU+0046, U+0061からU+0066の範囲の16進数(基数16)の数字 a hexadecimal (base 16) digit from the ranges U+0030 to U+0039, U+0041 to U+0046 and U+0061 to U+0066 |
| 符号無し整数 unsigned-integer |
10進数の数字の文字列, 負でない整数を表す a string of decimal-digits, representing a non-negative integer |
| 正の整数 positive-integer |
10進数の数字の文字列, ただし, 単に"0"(U+0030)のみから成るものは除く, 正の整数を表す a string of decimal-digits, but not consisting solely of "0"s (U+0030), representing a positive integer |
| 整数 integer |
必須でない"-"(U+002D), それに続く10進数の数字の文字列, 整数を表す an optional "-" (U+002D), followed by a string of decimal digits, and representing an integer |
| 符号無し数 unsigned-number |
10進数の数字と1つ以下の小数点(U+002E)の文字列, 負でない10進数で終わる数(有理数の型)を表す a string of decimal digits with up to one decimal point (U+002E), representing a non-negative terminating decimal number (a type of rational number) |
| 数 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) |
| 文字 character |
単独の空白でない文字 a single non-whitespace character |
| 文字列 string |
任意の空で無く有限の文字の文字列 an arbitrary, nonempty and finite, string of characters |
| 長さ length |
長さ, 後で説明, 第2.1.5.2節 長さの値の属性 a length, as explained below, Section 2.1.5.2 Length Valued Attributes |
| 単位 unit |
単位, 典型的に長さの一部として使用, 後で説明, 第2.1.5.2節 長さの値の属性 a unit, typically used as part of a length, as explained below, Section 2.1.5.2 Length Valued Attributes |
| 名前付き長さ namedlength |
名前付き長さ, 後で説明, 第2.1.5.2節 長さの値の属性 a named length, as explained below, Section 2.1.5.2 Length Valued Attributes |
| 色 color |
色, 後で説明, 第2.1.5.3節 色の値の属性 a color, as explained below, Section 2.1.5.3 Color Valued Attributes |
| id | 文書の中で唯一である識別子, XML勧告[XML]の名前の構文を満足しなければならない an identifier, unique within the document; must satisfy the NAME syntax of the XML recommendation [XML] |
| 参照先のid idref |
文書の中の他の要素を参照する識別子, 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 |
それぞれの属性について文章で説明された値, 第2.1.5.4節 属性の既定値参照, (注釈:原文では斜体となっているものを日本語訳では太字+下線付きで記載) values as explained in the text for each attribute; see Section 2.1.5.4 Default values of attributes |
| "文字列" "literal" |
引用符で囲まれた記号, 属性値の中に文字通り現れる(例えば"+"または'+') 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:
| 表記 Notation |
何と一致するか 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, Appendix 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).
ほとんどのプレゼンテーション要素は, 大きさや間隔や似たような特性のために用いる長さを表す値を持つ属性を持っています. 長さの構文は次のように指定されています.
Most presentation elements have attributes that accept values representing lengths to be used for size, spacing or similar properties. The syntax of a length is specified as
| 型 Type |
構文 Syntax |
|---|---|
| 長さ length |
数 | 数 単位 | 名前付き空白 number | number unit | namedspace |
長さにおいては, 数と単位の間に空白を入れるべきではありません.
There should be no space between the number and the unit of a length.
利用可能な単位と名前付き空白は, それらの解釈と一緒に後で示します. 単位とその意味はCSSを基にしていますが, 長さの構文はCSSと同一ではありません. いくつかのMathML要素は, 追加の値の名前を持つ長さの属性を持っています. それらの属性は疑似単位と呼ばれ, 特定の要素の説明で指定しています. 実例については, 第3.3.6節 周囲の余白を調整する <mpadded>を参照して下さい.
The possible units and namedspaces, along with their interpretations, are
shown below. Note that although the units and their meanings are taken from
CSS, the syntax of lengths is not identical. A few MathML elements
have length attributes that accept additional keywords; these are termed pseudo-units
and specified
in the description of those particular elements; see, for instance, Section 3.3.6 Adjust Space Around Content
<mpadded>.
終わりの"%"は参照先の値の百分率を表します. 他の方法が表明されない限り, 参照先の値は既定値です. 既定値または値がどのように適用されるかは, それぞれの要素の属性の表で, 既定値と異なる場合の参照先の値と一緒に一覧にしています. (また, 第2.1.5.4節 属性の既定値も参照して下さい.) 単位を持たない数は, 参照先の値の倍数と解釈されます. この形式は以前との互換性のためのものであり, 明瞭であるように明確な単位を付ける方が好ましく, この形式は避けるべきです.
A trailing "%" represents a percent of a reference value; unless otherwise stated, the reference value is the default value. The default value, or how it is obtained, is listed in the table of attributes for each element along with the reference value when it differs from the default. (See also Section 2.1.5.4 Default values of attributes.) A number without a unit is intepreted as a multiple of the reference value. This form is primarily for backward compatibility and should be avoided, prefering explicit units for clarity.
場合によっては, 特定の属性で利用可能な値の範囲が制限されるかもしれません. 実装は, 最も近い利用可能な値に切り上げようが切り捨てようが自由です.
In some cases, the range of acceptable values for a particular attribute may be restricted; implementations are free to round up or down to the closest allowable value.
MathMLで利用可能な単位は次のとおりです.
The possible units in MathML are:
| 単位 Unit |
説明 Description |
|---|---|
em |
em (典型的に水平の長さとして利用されるフォントに関係した単位) an em (font-relative unit traditionally used for horizontal lengths) |
ex |
ex (典型的に縦の長さとして利用されるフォントに関係した単位) an ex (font-relative unit traditionally used for vertical lengths) |
px |
ピクセル, または現在の画面の画素数 pixels, or size of a pixel in the current display |
in |
インチ (1インチ = 2.54センチメートル) inches (1 inch = 2.54 centimeters) |
cm |
センチメートル centimeters |
mm |
ミリメートル millimeters |
pt |
ポイント (1ポイント = 1/72インチ) points (1 point = 1/72 inch) |
pc |
パイカ (1パイカ = 12ポイント) picas (1 pica = 12 points) |
% |
既定値の百分率 percentage of the default value |
単位についてのいくつかの側面について, 後で第2.1.5.2.1節 単位についての追加の注意点で詳しく述べています.
Some additional aspects of units are discussed further below, in Section 2.1.5.2.1 Additional notes about units.
次の定数, 名前付き空白は, 長さが必要とされる場合にも利用されるでしょう. それらは典型的に素子の間の間隔を取ったり詰めたりするのに利用されます. それらの定数に推奨される既定値を示します. 実際に使用される空白は, 実装によって指定されます.
The following constants, namedspaces, may also be used where a length is needed; they are typically used for spacing or padding between tokens. Recommended default values for these constants are shown; the actual spacing used is implementation specific.
| 名前付き空白 namedspace |
推奨される既定値 Recommended default |
|---|---|
| "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で表現のためにのみ利用され, 表現は究極的には何らかの媒体での描画を意味します. 視覚的媒体では, 表示環境は, 描画ソフトウェアで使用可能なある種の特性を持っていると考えられます. pxは, 意味を持つという観点で画面の画素に一致します. 画面機器の決定は, 単位in, cm, mm, pt, pcの画素への対応に影響するでしょう.
Lengths are only used in MathML for presentation, and presentation
will ultimately involve rendering in or on some medium. For visual media,
the display context is assumed to have certain properties available to
the rendering agent. A px corresponds to a pixel on the display, to
the extent that is meaningful. The resolution of the display device
will affect the correspondence of pixels to the units
in, cm, mm, pt and pc.
その上, 表示環境は, フォントの大きさの既定値も提供します. そのフォントの特性が単位emとexを解釈するのに使用する初期値を決め, それによって間接的に名前付き空白の大きさを決めます. これらの単位は画面環境に追随することから, 特に利用者の画面の好みの面で, 相対的な単位emやexは, 一般にpxやcmといった絶対的な単位よりも好まれます.
Moreover, the display context will also provide a default for the font size;
the parameters of this font determine the initial values used to interpret
the units em and ex, and thus indirectly the sizes
of namedspaces. Since these units track the display context, and in particular,
the user's preferences for display, the relative units em and ex
are generally to be preferred over absolute units such as px or cm.
ただし, 相対的な単位の2つの追加の側面について明らかにしておかなければなりません. 1つは, 要素の中には, 第3.4節 添え字等の配置要素またはmfracといった, 暗黙のうちにそれらの引数の内いくつかのフォントの大きさをより小さく切り替えるものがあることです. 同様に, mstyleは現在のフォントの大きさを明確に変更するために利用できます. そのような場合, それらの要素の中のemやexの効果的な値は, 外側とは異なるでしょう. 2つ目の点は, 属性値で利用されるemやexの有効な値は, 現在のフォントの大きさの変更に影響されるであろうことです. よって, mathsizeやscriptlevelといった現在のフォントの大きさに影響する属性は, 他の長さの値を持つ属性が評価される前に処理されなければなりません.
Two additional aspects of relative units must be clarified, however.
First, some elements such as Section 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.
どういった場合に, どのように長さが視覚的でない媒体に効果があるのかは, 特定の実装によります.
If, and how, lengths might affect non-visual media is implementation specific.
プレゼンテーション要素の色, または背景色は, 次の構文を使用する色として指定されるでしょう.
The color, or background color, of presentation elements may be specified as a color using the following syntax:
| 型 Type |
構文 Syntax |
|---|---|
| 色 color |
#RGB | #RRGGBB | HTML色名 #RGB | #RRGGBB | html-color-name |
色は, "#"に続く間に空白のない赤, 緑, 青の成分の16進数の値か, もしくはHTML式名によって指定されます. 色の成分は, 1桁か2桁で表されますが, 全ての成分が同じ桁でなければなりません. 成分の範囲は, 0(成分が存在しない)からFF(成分が完全に満たされている)までです. [CSS21]の色の下で指定された桁を繰り返す決まりによって, 例えば, #123は#112233を短くしたものであることに注意して下さい.
A color is specified either by "#" followed
by hexadecimal values for the red, green, and blue components,
with no intervening whitespace, or by an html-color-name.
The color components can be either 1-digit or 2-digit, but
must all have the same number of digits; the component
ranges from 0 (component not present) to FF (component fully present).
Note that, for example, by the digit-doubling rule specified under Colors in
[CSS21]
#123 is a short form for #112233.
色の値はHTML色名, つまり[HTML4]で定義された色名の値("aqua", "black", "blue", "fuchsia", "gray", "green", "lime", "maroon", "navy", "olive", "purple", "red", "silver", "teal", "white", "yellow")の1つとしても指定できます. 色名の値は状況によらず, MathMLの属性値のほとんどの値とは違い, CSSやHTMLと互換性があることに注意して下さい.
Color values can also be specified as an html-color-name, one of the color-name keywords defined in [HTML4] ("aqua", "black", "blue", "fuchsia", "gray", "green", "lime", "maroon", "navy", "olive", "purple", "red", "silver", "teal", "white", and "yellow"). Note that the color name keywords are not case-sensitive, unlike most keywords in MathML attribute values, for compatibility with CSS and HTML.
色が要素に適用される場合, その色は素子の中身が描画されるときの色になります. 加えて, 周囲を囲っている要素または完全なMathMLの式が埋め込まれた環境から継承する場合, その色はmfrac, mtable, msqrtの描画の際に描かれる線や根号も含め, MathML要素によって描かれる全てのものの色を制御します.
When a color is applied to an element,
it is the color in which the content of tokens is rendered.
Additionally, when inherited from a surrounding element or from the environment in which the complete MathML expression is
embedded, it controls the color of
all other drawing due to MathML elements, including the lines
or radical signs that can be drawn in rendering mfrac, mtable, or
msqrt.
背景の色を指定するのに使われる場合, "transparent"(訳注:"透明"の意味)という値も利用できます. 推奨されるMathMLの視覚的描画の決まりは, 次の場合を除いて要素のbackground属性を利用した場合に影響を受ける背景の領域の正確な範囲を定義してはいません. それは, 要素の内容が負の領域を持っておらず, 周囲との間隔が負であることによって描画する領域が他の描画領域と重なっていない場合です. その場合の領域は, その要素の内容を表示する描画領域全ての背後となるべきですが, 周囲を取り囲んでいる式を表示する描画領域の前面には来るべきです. background属性の影響が及ぶ領域の範囲において, 周囲との間隔が負であることにより描画領域が重なった場合の影響は, MathMLの描画の決まりによって定義されてはいません.
When used to specify a background color, the keyword "transparent"
is also allowed.
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.
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 Section 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 (Section 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を描画する際のふるまいについて汎用的な既定値を設定する3つ目の方法, MathML演算子辞書があります. 既定値の例は付録C 演算子辞書で提供しています. このことは第3.2.5.7.1節 演算子辞書でも論じられており, 例は第3.2.5.2.1節 辞書に基づく属性で示しています.
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 Section 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 Section 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 Appendix C Operator Dictionary.
This is also discussed in Section 3.2.5.7.1 The operator dictionary and examples are given in
Section 3.2.5.2.1 Dictionary-based attributes.
それぞれの要素に対して特別に説明されている属性に加え, 次の表の属性が全ての要素で利用できます. 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.
| 名前 Name |
値 values |
既定値 default |
|---|---|---|
| id | id | 無し none |
リンク, 相互参照, 並列のマークアップに対応するために, 要素と結び付けられた唯一の識別子を確立します. xrefや第5.4節 並列のマークアップを参照して下さい.Establishes a unique identifier associated with the element to support linking, cross-references and parallel markup. See xref and Section 5.4 Parallel Markup.
|
||
| xref | 参照先のid idref |
無し none |
文書の中の他の要素を参照します. idや第5.4節 並列のマークアップを参照して下さい.References another element within the document. See id and Section 5.4 Parallel Markup.
|
||
| class | 文字列 string |
無し none |
|
要素を[XSLT]や[CSS21]を利用して書式の種類の集合と結び付けます. 典型的にこの属性は空白で区切られた一連の言葉となるでしょうが, MathMLでは指定されていません. MathMLとCSSの相互作用の議論については, 第6.5節 MathMLと一緒にCSSを利用するを参照して下さい. 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 Section 6.5 Using CSS with MathML for discussion of the interaction of MathML and CSS. |
||
| style | 文字列 string |
無し none |
|
書式情報を[XSLT]や[CSS21]を利用して要素と結び付けます. この属性は典型的に行の中に埋め込まれたCSS形式となるでしょうが, MathMLでは指定されていません. MathMLとCSSの相互作用の議論については, 第6.5節 MathMLと一緒にCSSを利用するを参照して下さい. 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 Section 6.5 Using CSS with MathML for discussion of the interaction of MathML and CSS. |
||
| href | URI | 無し none |
|
要素を特定のURIへのハイパーリンクとして確立するために利用できます. Can be used to establish the element as a hyperlink to the specfied URI. |
||
MathML2はリンクに直接対応しておらず, 代わりにW3C勧告"XMLリンク言語"[XLink]に従い, xlink:href属性を利用してリンクを定義していました. このことは変更となり, MathML3では現在hrefを使用します. しかしながら, 特に混合した文書形式ではMathML要素と一緒にXMLのリンクの利用を指定することもあることから, XMLリンクに対応したソフトウェアは, MathML3でも同様にxlink:hrefへの対応を継続すべきです.
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.
また, ほとんどのプレゼンテーション素子要素で利用できるMathML属性の一覧については, 第3.2.2節 素子要素に共通の数学書式属性も参照して下さい.
See also Section 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は, 他の名前空間の属性の利用が望ましいことから非推奨(第2.3.3節 指定されていないデータのための属性)となっています.
The attribute other,
is deprecated
(Section 2.3.3 Attributes for unspecified data) in favor of the use of
attributes from other namespaces.
| 名前 Name |
値 values |
既定値 default |
|---|---|---|
| other | 文字列 string |
無し none |
|
非推奨, ただしMathML1.0では利用していました. DEPRECATED but in MathML 1.0. |
||
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
<mtext> Theorem 1: </mtext>
は, <mtext>Theorem 1:</mtext>または<mtext>Theorem 1:</mtext>に等しいです.
is equivalent to
<mtext>Theorem 1:</mtext>
or
<mtext>Theorem 1:</mtext>.
素子の最初と最後の空白文字をコード化したり, または単独の空白でない空白文字列をコード化したりしようとする場合, それらを無視させないには, (U+00A0), または取り除かれることのない他の記述されない文字を使用しなければなりません. 例えば, 上の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>
最初の例は, "Theorem"の前に何も無く, "Theorem"と"1:"の間にユニコードの空白文字があり, "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.
<math>要素<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 Section 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.
math要素は, 第2.1.6節 全てのMathML要素で利用される属性で指定した共通の属性を含め, 第3.3.4節 書式の変更 <mstyle>で設定できる全ての属性を持ちます. 特に, 文章全体の方向を設定するdir属性を持っています. math要素は, 普通, 方向を指定するのに最も利用しやすい場所にあります(詳しい議論については第3.1.5節 方向参照). math要素におけるdir属性の既定値は"ltr"であることに注意して下さい(ただし, dir属性を持つことができる全ての他の要素に継承される場合にです). これは, 方向の概念を持たない以前のMathML2.0との互換性を提供するためです. また, mstyleや他のプレゼンテーション要素と同じ意味合いでmathbackground属性を持ちます. この属性は, 属性の既定値を指定するというよりむしろ全体の描画領域の背景色を指定します(第3.1.10節 プレゼンテーション要素に共通の数学書式属性参照).
The math element accepts any of the attributes that can be set on
Section 3.3.4 Style Change <mstyle>, including the common attributes
specified in Section 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 Section 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 Section 3.1.10 Mathematics style attributes common to presentation elements)
これらの属性に加えて, math要素は次の属性を持ちます.
In addition to those attributes, the math element accepts:
| 名前 Name |
値 values |
既定値 default |
|---|---|---|
| display | "block" | "inline" | inline |
囲っているMathMLの式が, 縦に分けられたblock(領域)(広げられた形式), または隣接した文章に揃えられるinline(行の中の形式)のどちらで描画されるべきか指定します. display="block"の場合, displaystyleは"true"で初期化されます. 一方, display="inline"の場合, displaystyleは"false"で初期化されます. どちらの場合でも, scriptlevelは0で初期化されます. (第3.1.6節 広げられた場合の書き方と書く大きさの水準参照). さらに, 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 Section 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 |
|
埋め込まれた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 | 長さ length |
altimgの幅width of altimg |
画像を拡大・縮小させることが必要な場合のaltimgを表示する幅を指定します. altimg-heightを参照して下さい.specifies the width to display altimg, scaling the image if necessary;
See altimg-height.
|
||
| altimg-height | 長さ length |
altimgの高さheight of altimg |
画像を拡大・縮小させることが必要な場合のaltimgを表示する高さを指定します. 属性altimg-widthとaltimg-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" length |
0ex |
隣接する行の中の要素に対する縦方向の位置揃えを指定します. 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 | 文字列 string |
無し none |
|
埋め込まれたMathMLまたは画像に対応したいない利用者のプログラムの代替手段として, 代替の文字列を提供します. provides a textual alternative as a fall-back for user agents that do not support embedded MathML or images. |
||
| cdgroup | URI | 無し none |
このmath要素の中のcsymbol, annotation, annotation-xml要素のOpenMathコンテント辞書の位置の基となるCDの目録として働くCDグループファイルを指定します. 第4.2.3節 コンテントマークアップの記号 <csymbol>を参照して下さい. cdgroup属性が何も明確に指定されていない場合, このmath要素に埋め込まれた文書形式は, 基となるCDを決める方法を提供するかもしれません. そうでない場合, システムは基となるCDを決めなければなりません. 特定の情報がない場合, http://www.openmath.org/cdがcsymbol, 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 Section 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:
| 値 Value |
意味 Meaning |
|---|---|
| "linebreak" | 式は複数の行に分割されるでしょう. より詳しい議論は第3.1.7節 式の改行を参照して下さい. The expression will be broken across several lines. See Section 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. |
mathの次の属性は非推奨です.
The following attributes of math are deprecated:
| 名前 Name |
値 values |
既定値 default |
|---|---|---|
| macros | URI * | 無し none |
|
外部のマクロを定義しているファイルを指し示す方法を提供することを意図しています. マクロはMathML仕様書の一部ではありません. intended to provide a way of pointing to external macro definition files. Macros are not part of the MathML specification. |
||
| mode | "display" | "inline" | inline |
囲っているMathMLの式が, 広げられた形式か行の中の形式かどちらで描画されるべきか指定します. この属性は, display属性を使用する方が望ましいことから非推奨です.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.
|
||
情報は最近, 一般にソフトウェアによって生み出され, 処理され, 描画さてれています. インターネットの急成長は, 自動で情報を検索したり, 分類したり, 相互に通信したりする進歩したシステムの開発をたきつけています. 加えて, ウェブサービスの数が増えてきており, 中には資料や活動に技術的に基づくことを提案しているものもあります. したがって, MathMLは, 機械の助けを借りるか, 単にとても深い集中によって, 人の手で書かれたり, 人に読まれたりしてきたとはいえ, MathMLの将来はソフトウェアでそれらを処理することが広く可能になっていきます.
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.
たくさんの別々の種類のMathML処理プログラムがあります. MathMLの式を書く編集ツール, 他のコードへ変換またはコードから変換するソフトウェア, MathMLの式を確認する検証ツール, MathMLの式を評価, 操作, 比較する計算プログラム, 数学表記の視覚的, 聴覚的, 触覚的表現を提供する表現プログラムがあります. MathMLに対応することが何を意味するかは, ソフトウェアによって大きく異なります. 例えば, 検証処理プログラムで挙がった問題は, 数式編集ツールで挙がった問題とは大きく違うでしょう.
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.
この節は, MathMLへの対応のいろいろな種類について説明し, 与えられたソフトウェアでのMathMLへの対応の拡張を明らかにするガイドラインを示しています. 開発者, 利用者, 評価者は, 製品を特徴付けるのにこのガイドラインを利用することを促されます. このガイドラインの背景にある意図は, 数量化できる用語によって正確にMathMLソフトウェアの能力を説明することで, それらのソフトウェアの再利用や使用性を促進することです.
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.
W3C数学作業部会はMathMLコンプライアンスガイドラインを管理しています. 適合の活動や資料の将来の更新についてはその文書を調べて下さい.
The W3C Math Working Group maintains MathML Compliance Guidelines. Consult this document for future updates on conformance activities and resources.
有効なMathMLの式は, MathML RelaxNGスキーマとこの仕様書で示されている追加の仕様で決められたXMLで構成されています.
A valid MathML expression is an XML construct determined by the MathML RelaxNG Schema together with the additional requirements given in this specification.
"MathML処理プログラム"という言葉を, 有効なMathMLの式を受け入れられるか提供できる何らかのソフトウェアを意味するものとして使用するでしょう. 有効なMathMLの式の受入れと提供の両方を行うMathML処理プログラムは, MathMLを"入出力処理"可能でしょう. 場合によっては, MathMLを入出力処理するソフトウェアの単純な例は, 修飾なしで新しいファイルにMathMLを書き込む編集ツールでしょう.
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.
MathML適合の3つの形式が指定されています.
Three forms of MathML conformance are specified:
MathML入力適合処理プログラムは, 全ての有効なMathMLの式を受け入れなければなりません. そのプログラムは, 全てのMathMLの式を, ソフトウェアが機能する固有の操作で利用できる, ソフトウェア特有の形式に適切に変換できなければなりません.
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.
MathML出力適合処理プログラムは, 全てのソフトウェア特有のデータを適切に表現する, 有効なMathMLを生成しなければなりません.
A MathML-output-conformant processor must generate valid MathML, appropriately representing all application-specific data.
MathML入出力処理適合プログラムは, MathMLの等価性を維持しなければなりません. 2つのMathMLの式は, 何らかの関係した状況下で, 何らかのMathML処理プログラムによって, 両方の式が(MathML構文と仕様書で表現されている)同じ解釈を持つ場合に"等価"です. 要素どうしを基にした等価性は, この文書の他のところで論じています.
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.
上の定義の他には, MathML仕様書は個々の処理プログラムに何も要求していません. 開発者の手引きとなるために, MathML仕様書は助言となる資料を含んでいます. 例えば, 第3章 プレゼンテーションマークアップの至るところに, たくさんの推奨される描画の決まりがあります. しかしながら, 一般に開発者は, 何の種類のMathMLの定義が彼らの特定のソフトウェアに対して有意義であるかについて, 解釈するための広い許容範囲を与えられています.
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 Chapter 3 Presentation Markup. 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:
MathML入力適合のために, 検証処理プログラムは式を受け入れることのみ必要で, 有効なMathMLである式に対し"true"を返します. 特に, そのプログラムは少しもMathMLの式を描画したり解釈したりする必要はありません.
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.
MathML数式処理プログラムのコンテントマークアップに基づいた入出力部分は, 全てのプレゼンテーションマークアップを無視することを選ぶかもしれません. その入出力部分が, プレゼンテーションマークアップで構成された式も含め, 全ての有効なMathMLの式を受け入れるならば, そのソフトウェアをMathML入力適合として特徴付けることは技術的に正しいでしょう.
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.
数式編集ツールは, 他の形式ではなく, MathMLとして式を出力することを容易にする内部のデータ表現を持っているかもしれません. 編集ツールが有効なMathMLとして単純な式を出力し, 他の形式への変換が失敗したというエラーメッセージを単に表示するならば, その編集ツールはそれでもMathML出力適合です.
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.
前の例で示したように, 利用しやすいよう, MathML適合の概念は, 言語の部分部分が意味の通るように実装されているかの判断を頻繁に含みます. 単に, 部分部分が適合の定義を尊重する技術的に正しい方法で処理されるということではありません. この概念は, MathMLの部分部分が与えられたソフトウェアによって有意義に定義されるよう, 定量的な説明を示す仕組みを必要としています. この目的に向かって, W3C数学作業部会はテストツールを提供しています.
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.
テストツールは, マークアップの種類によって特徴付けられた, たくさんの数のMathMLの式や, 検証された主要なMathML要素から成り立っています. テストツールの存在は, 例えば定量的に仮の数式処理システムの入出力部分を特徴付けることができます. その入出力部分は, テストツールのコンテント―マークアップの部分にある全ての式を含めて, 有意義にMathMLコンテントマークアップを実装したMathML入力適合プログラムであると上で述べたものです.
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.
意義のある理由でMathML仕様書の一部を実装しないことを選んだ開発者は, テストツールの特定の種類の部分を示すことで, 省略した部分を提示することが促されています.
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.
MathML出力適合処理プログラムに対し, MathMLを検証する現在利用可能なソフトウェアの情報は, W3C MathML検証サービスで管理されています. MathML出力適合プログラムの開発者は, 検証サービスを利用してプログラムの出力を確認するよう促されます.
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.
MathMLソフトウェアの顧客は, MathML仕様書の部分部分がソフトウェアによって実装されているという主張を確認したいと願う場合, その確認の流れの中でテストツールを利用することが促されています.
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は, 現在は非推奨となっている以前のMathMLの機能を含んでいます. 次に示す点で, 非推奨となることが機能として何を意味しているのかを定義し, 非推奨となった機能とMathML適合との間の関係を明らかにします.
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.
MathML出力適合であるために, MathMLを書き出すソフトウェアは, 非推奨の機能を含むMathMLマークアップを生成しない方が良いでしょう.
In order to be MathML-output-conformant, authoring tools may not generate MathML markup containing deprecated features.
MathML入力適合であるために, 描画ソフトウェアや音声読み上げソフトウェアは, ソフトウェアがMathML 1.xまたはMathML 2.xに適合するならば, 非推奨の機能に対応しなければなりません. それらのソフトウェアは, MathML 3.0に適合すると考えられているのなら, 非推奨の機能に対応しなくても良いです. しかしながら, 全てのソフトウェアは可能な限り古い形式に対応するよう促されています.
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.
MathML入出力適合であるために, 処理プログラムは, 非推奨の機能を何も含まない式においてMathML等価性を維持することだけが必要です.
In order to be MathML-round-trip-conformant, a processor need only preserve MathML equivalence on expressions containing no deprecated features.
MathML 3.0は3つの基本的な拡張の仕組みを定義しています. まず, mglyph要素は, ユニコード文字でない文字の字形や存在しているユニコード文字の異体字を表示する方法を提供します. また, maction要素は, 実装で指定された変数を利用するのに他の名前空間の属性を利用します. 最後に, コンテントマークアップは, definitionURL属性およびコンテント辞書やcd属性を, 数学の意味の外部定義を指し示すために利用します.
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.
これらの拡張の仕組みは重要です. なぜなら, これらの仕組みが, 現在明確に指定されたMathML 3.0の範囲を超え, まだ標準化されていない新しい考えを試しに利用するためにMathMLに認められた, 概念をコード化する手法を提供するからです. しかしながら, 新しい考えが定着するにつれ, その考えは将来の標準の一部となるかもしれません. 例えば, 現在mglyph要素で表現されなければならないと判明している文字が, 将来ユニコードのコードポイントを割当てられるかもしれません. そのときは, 直接ユニコードのコードポイントを用いて文字を表す方が好ましいでしょう. 既にユニコードに移行した文字として, 数学で利用される数百の文字があります.
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.
将来廃れる可能性が, 新しい考えを促進するための, 拡張の仕組みの利用には本質的に伴います. そのため, MathMLは, 代わりの標準的なマークアップが利用可能になったとしても, 拡張の仕組みの利用に影響する適合の必要条件が何も無いように考慮しています. 例えば, mglyph要素を'x'を表現するために利用することは認められています. 同様に, MathML 3.0の拡張の仕組みを利用している文書の管理者は, 関連する標準化の活動(例えば, ユニコード, OpenMath等)を把握し, より標準的なマークアップが利用可能になったときに文書を更新するよう促されています.
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.
MathML入力適合ソフトウェアが, 不当な数や種類の, 属性や子要素を持つ1つ以上の要素を含む入力を受け取ったとしても, ソフトウェアは全ての入力を分かりやすい方法で描画しようと試みるべきです. すなわち, 入力のうちの有効な部分は通常どおり描画し, 無効な式の場所に(あたかもmerror要素で囲まれたかのように描画された)エラーメッセージを表示するべきです.
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出力適合ソフトウェアは, 入力の中の単独のエラーに対しmerrorの式を出力することを選ぶかもしれません. この方法は有効であり, おそらく正しくないMathMLを出力するより普通好まれます.
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.
MathML仕様書で述べられているMathML属性は, 良い表現と内容のマークアップをできるようにするためのものです. しかしながら, 全ての利用者が必要としていることをマークアップで対応することは不可能です. 理想を言えば, 利用者が特定の描画ソフトウェアのための特定の属性を加えられるように, MathML属性は制限無しの一覧であるべきです. しかしながら, このことは, 単独のXML DTDや構文では限界があり, 実現できません. このことは標準のDTDの拡張を利用すれば実現できるかもしれませんが, 著者の中には, 標準DTDに厳密な適合を残す限り, 描画ソフトウェア特有の能力の有利な点を持つ, 標準でない属性を利用したいと願う人がいることを言っておきます.
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.
このことを認めるために, MathML 1.0仕様書[MathML1]は, 描画ソフトウェアに特有の情報を渡すためのフック(訳注:処理を割り込ませる仕組み)として利用するための属性otherを全ての要素の中で認めていました. 特に, その属性は, 聴覚表現ソフトウェア, 数式処理システム, 将来のマクロや拡張の仕組みとなる原型の部分に, 情報を渡すフックと考えられていました. この手法への意欲が問題へと向かったのは, 例えば, その言語の一部ではない情報を渡すのに, コメントを広く利用していたポストスクリプトを見てみると, 歴史上の事実です.
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.
MathMLの発展の次の期間の間に, 一般的なXML名前空間の仕組みの開発は, other属性の利用を時代遅れのものにしました. MathML 2.0において, MathMLでない属性を特定するのに名前空間の接頭辞の利用が望ましいことから, other属性は非推奨となっています. other属性はMathML 3.0でも非推奨として残っています.
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.
例えば, MathML 1.0において, 描画ソフトウェア特有の実装としての追加の情報は, maction要素(第3.7.1節 式の一部に動作を結び付ける <maction>)で利用することが推奨されていました. それらの情報はother属性を利用して渡すべきでした.
For example, in MathML 1.0, it was recommended that if additional information
was used in a renderer-specific implementation for the maction element
(Section 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>
MathML 2.0 以降は, 他の名前空間のcolor属性を利用すべきでしょう.
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>
標準でない属性を認めている意図は, ソフトウェア開発者にMathMLの中心となる慣習の裏をかく抜け道として, その属性の利用を進めている訳ではないことに注意して下さい. 著者やソフトウェアは, 標準でない属性を賢明に使用すべきです.
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.