6 ホスト環境との相互作用
Interactions with the Host Environment

6.2.1 XMLの中のMathMLの認知
Recognizing MathML in XML

名前空間[XML], [名前空間]に対応しているXML文書の中で, MathMLマークアップを認知する好ましい方法は, MathML名前空間URI http://www.w3.org/1998/Math/MathMLの使用によって, MathML名前空間中のmath要素を認知するということです.

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

MathML名前空間URIは, [XHTML]文書の中に埋め込まれたMathMLに対して推奨される方法です. ただし, 利用者のソフトウェアの中には, MathMLマークアップを処理する特定の拡張機能を呼び出すことができるように, 補足の情報を必要とするものがあるかもしれません.

The MathML namespace URI is the recommended method to embed MathML within [XHTML] documents. However, some user-agents may require supplementary information to be available to allow them to invoke specific extensions to process the MathML markup.

MathMLを埋め込もうとしているマークアップ言語の仕様書は, この勧告文書とは独立したMathMLを認知する特別な条件を必要とするかもしれません. その条件は, この勧告文書で説明されているものと類似したものであるべきです. また, MathML要素のその環境での名前は, この勧告文書で定義されたものと同じであるべきです.

Markup-language specifications that wish to embed MathML may require special conditions to recognize MathML markup that are independent of this recommendation. The conditions should be similar to those expressed in this recommendation, and the local names of the MathML elements should remain the same as those defined in this recommendation.

6.2.2 HTMLの中のMathMLの認知
Recognizing MathML in HTML

HTMLは何ら名前空間を認めていませんが, MathML名前空間を認識するものをして組み込んでいます. math要素やその子孫要素は, HTML処理プログラムによってhttp://www.w3.org/1998/Math/MathML名前空間に置かれ, 入力が前の節で宣言した名前空間を伴うXHTMLであるかのように処理されるでしょう. HTML処理プログラムがMathMLを制御する詳細な決まりについては, 第6.4.3節 MathMLとHTMLの混在を参照して下さい.

HTML does not allow arbitrary namespaces, but has built in knowledge of the MathML namespace. The math element and its descendants will be placed in the http://www.w3.org/1998/Math/MathML namespace by the HTML parser, and will appear to applications as if the input had been XHTML with the namespace declared as in the previous section. See Section 6.4.3 Mixing MathML and HTML for detailed rules of the HTML parser's handling of MathML.

6.2.3 MathML文書の内容の形式
Resource Types for MathML Documents

MathMLの式を描画することは, ウェブブラウザの中でしばしば行われますが, 描画以外のMathMLを処理する機能は, 他のソフトウェアで行われるのが, より自然です. 特に, 一般的な機能は, 数式編集ツールや数式処理システムでMathMLの式を開くことを含んでいます. よって, MathMLマークアップの形式を特定する, コード化された名前を指定することは重要です.

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

XML名前空間を認知した環境以外では, MathML処理プログラムを呼び出すことを確実にすることができるように, メディアタイプ[RFC2045], [RFC2046]が利用されるべきです. メディアタイプが適切でない環境では, ある特定の動作環境におけるクリップボードの形式といった, 次の節で述べるコード化された名前が使用されるべきです.

Outside of those environments where XML namespaces are recognized, media types [RFC2045], [RFC2046] should be used if possible to ensure the invocation of a MathML processor. For those environments where media types are not appropriate, such as clipboard formats on some platforms, the encoding names described in the next section should be used.

6.2.4 MathMLのコード化された名前
Names of MathML Encodings

MathMLは2つの別個の種類があります. 1つは視覚的表現をコード化したもので, 第3章 プレゼンテーションマークアップで定義しています. もう1つはコンピュータでの構造をコード化したもので, 第4章 コンテントマークアップで定義しています. MathMLソフトウェアの中には, 2つの種類のうち1つしか入出力しないものもあるかもしれません. それぞれ別々の方法を提供したり使用したりし, まだそれぞれが2つの違いを除いてしたか処理できないためです. 次に示すコード化された名前は, コンテントMathMLやプレゼンテーションMathMLのマークアップを必要に応じて確立するために利用されるでしょう.

MathML contains two distinct vocabularies: one for encoding visual presentation, defined in Chapter 3 Presentation Markup, and one for encoding computational structure, defined in Chapter 4 Content Markup. Some MathML applications may import and export only one of these two vocabularies, while others may produce and consume each in a different way, and still others may process both without any distinction between the two. The following encoding names may be used to distinguish between content and presentation MathML markup when needed.

• MathML-プレゼンテーション: プレゼンテーションMathMLのマークアップを含む実例

  MathML-Presentation: The instance contains presentation MathML markup only.

  • メディアタイプ: application/mathml-presentation+xml

    Media Type: application/mathml-presentation+xml

  • ウィンドウズクリップボードフレーバー: MathML Presentation
    (訳注:ウィンドウズのクリップボードのデータ形式を決める値)

    Windows Clipboard Flavor: MathML Presentation

  • ユニバーサルタイプ識別子: public.mathml.presentation

    Universal Type Identifier: public.mathml.presentation

• MathML-コンテント:コンテントMathMLマークアップを含む実例

  MathML-Content: The instance contains content MathML markup only.

  • メディアタイプ: application/mathml-content+xml

    Media Type: application/mathml-content+xml

  • ウィンドウズクリップボードフレーバー: MathML Content

    Windows Clipboard Flavor: MathML Content

  • ユニバーサルタイプ識別子: public.mathml.content

    Universal Type Identifier: public.mathml.content

• MathML (一般): プレゼンテーションMathMLマークアップ, コンテントMathMLマークアップ, その2つを混合したもののどれかを含むであろう実例

  MathML (generic): The instance may contain presentation MathML markup, content MathML markup, or a mixture of the two.

  • 拡張子: .mml

    File name extension: .mml

  • メディアタイプ: application/mathml+xml

    Media Type: application/mathml+xml

  • ウィンドウズクリップボードフレーバー: MathML

    Windows Clipboard Flavor: MathML

  • ユニバーサルタイプ識別子: public.mathml

    Universal Type Identifier: public.mathml

これらのコード化された名前それぞれに対する詳細については, 付録B メディアタイプの登録を参照して下さい.

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

MathML2は, annotation-xml要素のencoding属性に, 定義済みの値MathML, MathML-Content, MathML-Presentationを指定していました. これらの値は, 以前との互換性のためにメディアタイプの代わりに用いられるでしょう. 詳細については, 第5.1.3節 代替表現や第5.1.4節 同一内容を参照して下さい. MathML1.0は, [RFC3023]で廃止されたメディアタイプtext/mathmlを提案していました.

MathML 2 specified the predefined encoding values MathML, MathML-Content, and MathML-Presentation for the encoding attribute on the annotation-xml element. These values may be used as an alternative to the media type for backward compatibility. See Section 5.1.3 Alternate representations and Section 5.1.4 Content equivalents for details. Moreover, MathML 1.0 suggested the media-type text/mathml, which has been superseded by [RFC3023].

6.3.1 基となる転送フレーバーの名前と内容
Basic Transfer Flavor Names and Contents

第6.2.4節 MathMLのコード化された名前で一覧にした名前は, MathMLのコード化に対応する転送フレーバーを特定するのに使われる正確な文字列です. そのようなものを認めたオペレーティングシステムにおいて, ソフトウェアは, それらのフレーバーに対するそのソフトウェアの対応状況を登録すべきです(例えば, Windowsにおけるレジスタークリップボードフォーマット, マッキントッシュ環境におけるソフトウェア記述子の中のユニバーサルタイプ識別子への対応の宣言).

The names listed in Section 6.2.4 Names of MathML Encodings are the exact strings that should be used to identify the transfer flavors that correspond to the MathML encodings. On operating systems that allow such, an application should register their support for these flavor names (e.g. on Windows, a call to RegisterClipboardFormat, or, on the Macintosh platform, declaration of support for the universal type identifier in the application descriptor).

MathMLを受け渡すとき, ソフトウェアは, 受け渡されるデータの中身がMathML文書型の整形式のXMLの実例であることを確実にしなければなりません. とりわけ次のようにです.

When transferring MathML, an application MUST ensure the content of the data transfer is a well-formed XML instance of a MathML document type. Specifically:

1. その例は, 例えば<?xml version="1.0">のようなXML宣言で始まるでしょう.

   The instance MAY begin with an XML declaration, e.g. <?xml version="1.0">

2. その例は, きっちり1つのルート要素であるmath要素を含まなければなりません.

   The instance MUST contain exactly one root math element.

3. その例は, ルート要素であるmath要素の中でMathML名前空間を宣言しなければなりません.

   The instance MUST declare the MathML namespace on the root math element.

4. その例は, math要素のschemaLocation属性を, その例が適合しているMathML文書型を述べているMathML構文の場所を示すのに利用するかもしれません. schemaLocation属性の存在は, MathMLの利用者が参照している構文を取得したり利用したりするのに必須ではありません.

   The instance MAY use a schemaLocation attribute on the math element to indicate the location of the MathML schema that describes the MathML document type to which the instance conforms. The presence of the schemaLocation attribute does not require a consumer of the MathML instance to obtain or use the referenced schema.

5. その例は, より高い相互運用性のために, 文字実体参照名(例えば&alpha;)よりも, 数値文字参照(例えば&#x03b1;)を利用すべきです.

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

6. UTF-8以外の文字コードが使われている場合, XML宣言か, UTF-16でコード化されたデータに対するバイト順マーク(BOM)の利用かによって, その例は文字コードを指定しなければなりません.

   The instance MUST specify the character encoding, if it uses an encoding other than UTF-8, either in the XML declaration, or by the use of a byte-order mark (BOM) for UTF-16-encoded data.

6.3.2 受け渡す際の推奨されるふるまい
Recommended Behaviors when Transferring

MathMLマークアップを受け渡すソフトウェアは, 次の慣習を守るべきです.

An application that transfers MathML markup SHOULD adhere to the following conventions:

1. 純粋なプレゼンテーションマークアップや純粋なコンテントマークアップに対応したソフトウェアは, 利用可能な限りたくさんのフレーバーに対応すべきです.

   An application that supports pure presentation markup and/or pure content markup SHOULD offer as many of these flavors as it has available.

2. 1つのMathMLフレーバーを出力するソフトウェアは, より特定のフレーバーを決められないことから, その名前をMathMLのみとすべきです.

   An application that only exports one MathML flavor SHOULD name it MathML if it is unable to determine a more specific flavor.

3. ソフトウェアがより特定のフレーバーを決めることができるならば, そのソフトウェアは一般的なものと特定のもの両方のフレーバーを提供すべきです. ただし, 受け取り側が特定のフレーバーに対応していると知られている場合は, そのフレーバーのみを受け渡すべきです. HTTP GET通信では, 例えば, コンテントマークアップとプレゼンテーションマークアップに対して, 特定の転送形式がクライアントが送ったHTTP Acceptヘッダーに含まれているならば, その転送形式のみを返すべきです.

   If an application is able to determine a more specific flavor, it SHOULD offer both the generic and specific transfer flavors, but it SHOULD only deliver the specific flavor if it knows that the recipient supports it. For an HTTP GET transfer, for example, the specific transfer types for content and presentation markup should only be returned if they are included in the the HTTP Accept header sent by the client.

4. 2つの特定の転送フレーバーを出力するソフトウェアは, コンテントマークアップとプレゼンテーションマークアップ両方のフレーバーと同じように, 一番上のMathML semantics要素(第5.4.1節 並列のマークアップの一番上の要素参照)を使った他の2つを複合する一般的なフレーバーを出力すべきです.

   An application that exports the two specific transfer flavors SHOULD export both the content and presentation transfer flavors, as well as the generic flavor, which SHOULD combine the other two flavors using a top-level MathML semantics element (see Section 5.4.1 Top-level Parallel Markup).

5. ルート要素の子要素がsemantics要素のみのMathMLデータをソフトウェアが出力するとき, 転送フレーバーが認知され, encoding属性に基づいて名付けられ付加情報の鍵が(既定値の)alternate-representationならば, そのソフトウェアは上で示したフレーバーの後に, それぞれannotationまたはannotation-xml要素に対応する転送フレーバーを提供すべきです. それぞれの付加情報で受け渡される内容は, (annotation要素に対して)特定の文字コードの文字データ, または(annotation-xmlに対して)整形式のXMLデータ, または(付加情報の参照に対して)src属性で与えられるURLを参照した結果のデータを含みます.

   When an application exports a MathML fragment whose only child of the root element is a semantics element, it SHOULD offer, after the above flavors, a transfer flavor for each annotation or annotation-xml element, provided the transfer flavor can be recognized and named based on the encoding attribute value, and provided the annotation key is (the default) alternate-representation. The transfer content for each annotation should contain the character data in the specified encoding (for an annotation element), or a well-formed XML fragment (for an annotation-xml element), or the data that results by requesting the URL given by the src attribute (for an annotation reference).

6. 最後の頼みの綱として, ソフトウェアは, (text/plain, CF_UNICODETEXT, UnicodeText, NSStringPboardTypeといった)書式無しの文字列フレーバー形式のデータを出力するかもしれません. ソフトウェアが利用可能な表現の複数の形式を持っているとき, そのソフトウェアは, そのソフトウェアの考え方次第で文字列として出力する形式を選ぶかもしてません. 古いMathML処理プログラムは, math要素で始まる書式無しの文字列として受け渡される, math要素の前に現れるであろうXML宣言, DOCTYPE宣言, 他のXMLの前処理の部分を一般に省略した, MathMLデータを期待しているかもしれません. 出力されるフレーバーは最も特定のフレーバーが最初で, 最も一般的なフレーバーが最後になる順番で並ぶべきであるという原則に従って, ユニコードの文字列形式のデータは, いつも最後に出力されるフレーバーであるべきです.

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

6.3.3 議論
Discussion

MathMLの実例が純粋なコンテントマークアップか純粋なプレゼンテーションマークアップのどちらか決めるのに, math, semantics, annotation, annotation-xml要素は, プレゼンテーションマークアップとコンテントマークアップの両方の種類に属することができると見なされるべきです. math要素は, 全てのMathMLの受け渡しでルート要素として必要とされることから, この方法で取り扱われます. semantics要素とその子要素の付加情報要素は, MathMLの中で代わりの付加情報の仕組みを構成しており, また, プレゼンテーションマークアップかコンテントマークアップかのどちらかと結び付けられるわけではありません. 結果として, MathMLを利用するソフトウェアは, 2つの種類のうち1つしか実装していないとしても, いつもこれらの4つの要素を処理する必要があります.

To determine whether a MathML instance is pure content markup or pure presentation markup, the math, semantics, annotation and annotation-xml elements should be regarded as belonging to both the presentation and content markup vocabularies. The math element is treated in this way because it is required as the root element in any MathML transfer. The semantics element and its child annotation elements comprise an arbitrary annotation mechanism within MathML, and are not tied to either presentation or content markup. Consequently, an application that consumes MathML should always process these four elements, even if it only implements one of the two vocabularies.

MathMLを提供するプログラムが, 例えば画像や他のソフトウェア特有の形式であるバイナリデータをクリップボードに提供することを, 前で述べた推奨されるふるまいが認めることは価値を持ちません. XML文字データは何らかのバイトの流れのデータを受け渡すことができないことから, バイナリデータを受け渡す唯一の方法は, 付加情報のsrc属性を利用してバイナリーデータを参照することです.

It is worth noting that the above recommendations allow agents that produce MathML to provide binary data for the clipboard, for example in an image or other application-specific format. The sole method to do so is to reference the binary data using the src attribute of an annotation, since XML character data does not allow for the transfer of arbitrary byte-stream data.

前で述べた推奨されるふるまいは, MathMLを受け渡す枠組を利用する, MathMLに関係したソフトウェア間の相互運用性を改良することを意図されていますが, それらの推奨されるふるまいは相互運用性を保証していないことに注意すべきです. 例えば, MathMLデータの中の(例えば, スタイルシート等の)外部のデータへの参照は, データの利用者がそれらが置かれた場所を利用できない場合に, HTMLや他のデータ形式を切り取り貼り付けしたときに起こるであろう相互運用性の問題を引き起こすでしょう. 外部データへの参照を利用するソフトウェアは, 潜在的な問題を利用者に意識させ, 参照しているデータを得る代わりの方法を提供するように促されています. 一般に, 解決したり理解できない参照を含むMathMLデータの利用者は, 外部の参照を無視すべきです.

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

6.3.4 例
Examples

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

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

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

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

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

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

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

{x \over x-1}

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

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

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

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

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

{x \over x-1}

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

6.4.1 MathMLとXHTMLの混在
Mixing MathML and XHTML

XHTMLにMathMLを統合するには, XHTMLにMathMLを埋め込むだけでなく, MathMLにXHTMLを埋め込むことも可能とすべきです. W3C HTML5検証ツールで使用される構文は, (svgを含む)全ての行の中のHTML(を表す)要素を, mtextの内容に利用できるように, mtextを拡張しています. 第3.2.2.2節 MathMLの中にHTMLを埋め込むの例を参照して下さい. 前に注意したように, mtextの中のXHTML要素を使用するMathMLデータは, 文書から抜き出されたり, 分離して利用されたりした場合, 有効なMathMLデータではないでしょう. 編集ツールは, mtextの中から全てのHTMLのマークアップを取り除くか, 代わりの文字列で置き換えるかする対応を提案するかもしれません.

To fully integrate MathML into XHTML, it should be possible not only to embed MathML in XHTML, but also to embed XHTML in MathML. The schema used for the W3C HTML5 validator extends mtext to allow all inline (phrasing) HTML elements (including svg) to be used within the content of mtext. See the example in Section 3.2.2.2 Embedding HTML in MathML. As noted above, MathML fragments using XHTML elements within mtext will not be valid MathML if extracted from the document and used in isolation. Editing tools may offer support for removing any HTML markup from within mtext and replacing it by a text alternative.

ほとんどの場合に, XHTML要素(ヘッダー, 段落, 一覧等)が数学の文脈の中に適用されないか, MathMLがあらかじめ数学の内容(表, 数学の書式の変更等)に特別に合わせられた同様のまたは改良された機能を提供するかします.

In most cases, XHTML elements (headings, paragraphs, lists, etc.) either do not apply in mathematical contexts, or MathML already provides equivalent or improved functionality specifically tailored to mathematical content (tables, mathematics style changes, etc.).

最新のブラウザや他のMathML関連ソフトウェアに対する互換性や実装の提案は, W3C数学作業部会のホームページに相談して下さい.

Consult the W3C Math Working Group home page for compatibility and implementation suggestions for current browsers and other MathML-aware tools.

6.4.2 MathMLとXMLでない言語の混在
Mixing MathML and non-XML contexts

数式の記述を必要としているXMLでない種類の言語があり, この仕様書を参照することが有意義な場合があるかもしれません. HTMLは次の節で論じている重要な例ですが, 他の例が存在します. \frac{a}{b}といったTeXのような構文を, 明確に<mfrac>や<mi">を利用する代わりに利用できます. プログラムが特定の構文を処理し, MathML構文に適合しているであろうツリー構造を提供するならば, その構文はMathMLの応用と見られるでしょう. それでもその体系を利用した文書は, MathMLに適合していないことに注意して下さい. そのような構文の実装は, ここで定義されているXML構文でのMathMLとして, 可能な限り何らかの数式を出力する機能を提供すべきです. そのようなプログラムは, 第2.3.1節 MathML適合で述べたMathML出力適合です.

There may be non-XML vocabularies which require markup for mathematical expressions, where it makes sense to reference this specification. HTML is an important example discussed in the next section, however other examples exist. It is possible to use a TeX-like syntax such as \frac{a}{b} rather than explicitly using <mfrac> and <mi">. If a system parses a specified syntax and produces a tree that may be validated against the MathML schema then it may be viewed as as a MathML application. Note however that documents using such a system are not valid MathML. Implementations of such a syntax should, if possible, offer a facility to output any mathematical expressions as MathML in the XML syntax defined here. Such an application would then be a MathML-output-conformant processor as described in Section 2.3.1 MathML Conformance.

6.4.3 MathMLとHTMLの混在
Mixing MathML and HTML

XMLに基づかない体系の重要な例が[HTML5]で定義されています. HTMLの中のMathMLについて考えると, 2つに分けられる考え得る課題があります. 1つ目は, XHTMLの内容について前に述べたように, 構文がmtextの中のHTMLを認めるよう拡張されることです. 2つ目は, XML処理プログラムではなくHTML処理プログラムが利用されることです. HTML処理プログラムによってMathMLを処理することは, [HTML5]で規範的に定義しています. ここでの議論は, 処理プログラムの実装者に向けられており, 処理プログラムが入力それぞれの文字を処理する際の, 状態の移り変わりの観点から書かれています. 後の規範的でない説明は, 高い水準の説明や例を与えようとしています.

An important example of a non-XML based system is defined in [HTML5]. When considering MathML in HTML there are two separate issues to consider. Firstly the schema is extended to allow HTML in mtext as described above in the context of XHTML. Secondly an HTML parser is used rather than an XML parser. The parsing of MathML by an HTML parser is normatively defined in [HTML5]. The description there is aimed at parser implementers and written in terms of the state transitions of the parser as it parses each character of the input. The non-normative description below aims to give a higher level description and examples.

XMLの処理は完全に一般的なもので, 何らかのXML文書は, 利用されている特定の種類の言語への参照無しに処理されるかもしれません. HTMLの処理は, それぞれの要素に特定の決まりと一緒にHTML言語に特化した処理プログラムという点で異なっています. XMLでの場合と同様に, HTML処理プログラムは, 検証からの処理を確立します. 入力の中には, 正確に描画されたとしても, 検証プログラムによって報告されるであろう(ただし, 通常は描画システムからは報告されない)処理エラーに分類されるものもあります.

XML parsing is completely regular, any XML document may be parsed without reference to the particular vocabulary being used. HTML parsing differs in that it is a custom parser for the HTML vocabulary with specific rules for each element. Similarly to XML though, the HTML parser distinguishes parsing from validation; some input, even if it renders correctly, is classed as a parse error which may be reported by validators (but typically is not reported by rendering systems).

MathMLの利用に影響する主な違いは, 次のように要約されます.

The main differences that affect MathML usage may be summarized as:

• ほとんどの場合, 属性値は引用符で囲う必要がありません. <mfenced open=( close=)>は正しく処理されます.

  Attribute values in most cases do not need to be quoted: <mfenced open=( close=)> would parse correctly.

• 終了タグは, 多くの状況で省略されるかもしれません.

  End tags may in many cases be omitted.

• HTMLは, HTML, MathML,SVGの3つのいずれかからなる名前空間以外に対応しておらず, また, 名前空間の接頭辞にも対応していません. よって, <mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML">のような接頭辞の付いた形は利用できず, <math xmlns="http://www.w3.org/1998/Math/MathML">は利用できるかもしれませんが, 名前空間の宣言は本質的に無視され, その入力は<math>として扱われます. どちらの場合でも, math要素とその子孫要素はMathML名前空間に置かれます. 第5章 数式に対するマークアップ言語の混在で注意したように, 名前空間への対応の欠乏は, HTMLの中で利用する場合に, MathMLに他の言語のマークアップで付加情報を付ける何らかの可能性を制限します.

  HTML does not support namespaces other than the three built in ones for HTML, MathML and SVG, and does not support namespace prefixes. Thus you can not use a prefix form like <mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML"> and while you may use <math xmlns="http://www.w3.org/1998/Math/MathML">, the namespace declaration is essentially ignored and the input is treated as <math>. In either case the math element and its descendants are placed in the MathML namespace. As noted in Chapter 5 Mixing Markup Languages for Mathematical Expressions the lack of namespace support limits some of the possibilities for annotating MathML with markup from other vocabularies when used in HTML.

• XML処理プログラムとは異なり, HTML処理プログラムは, どんな入力文字列も受入れ, 定義された結果を提供するよう定義されています. この結果は, 不適合に分類されるかもしれません. 例として, 極端な例である<math></<><z =5>は, 検証ツールによりエラーと処理されるでしょうが, コメント<とXMLでは表現できない名前が=5で値が""の属性をもつ要素zを含んでいるmath要素に対応するツリー構造を返すでしょう.

  Unlike the XML parser, the HTML parser is defined to accept any input string and produce a defined result (which may be classified as non-conforming. The extreme example <math></<><z =5> for example would be flagged as a parse error by validators but would return a tree corresponding to a math element containing a comment < and an element z with an attribute that could not be expressed in XML with name =5 and value "".

• 素子要素<mtext>, <mo>, <mn>, <mi>, <ms>の中, またはencoding属性が"text/html"または"annotation/xhtml+xml"である<annotation-xml>の中を除いて, HTML要素の存在は, 全ての開いたMathML要素を閉じることで数式を終わらせるでしょう. そのため, そのHTML要素は, 外側のHTMLの文脈にあると解釈されます. 何らかのそれに続くMathML要素は<math>に含まれておらず, そのため無効なHTML要素として処理され, MathMLとして描画されないでしょう. 例については, 第5.2.3.3節 HTML文書でannotation-xmlを利用するで与えられた例を参照して下さい.

  Unless inside the token elements <mtext>, <mo>, <mn>, <mi>, <ms>, or inside an <annotation-xml> with encoding attribute "text/html" or "annotation/xhtml+xml", the presence of an HTML element will terminate the math expression by closing all open MathML elements, so that the HTML element is interpreted as being in the outer HTML context. Any following MathML elements are then not contained in <math> so will be parsed as invalid HTML elements and not rendered as MathML. See for example the example given in Section 5.2.3.3 Using annotation-xml in HTML documents.

既存のMathMLソフトウェアとの互換性の観点から, 著者や編集ツールは, HTML文書の中でさえ, 整形式のXMLであるMathMLの断片を利用すべきです. 前に注意したように, HTML文書の中にMathMLを受け入れるソフトウェアが, それらのHTML処理プログラムの機能をMathMLが利用することを受け入れなければならないとしても, それらのソフトウェアは, 軽量なXML構文の中にMathMLを出力する方法を提供すべきです.

In the interests of compatibility with existing MathML applications authors and editing systems should use MathML fragments that are well formed XML, even when embedded in an HTML document. Also as noted above, although applications accepting MathML in HTML documents must accept MathML making use of these HTML parser features, they should offer a way to export MathML in a portable XML syntax.

6.4.4 リンク
Linking

MathML3において, href属性の存在によって, 要素はリンクとして指定されます. MathMLは, HTML/XHTMLのアンカー要素aに対応する要素を何ら持ちません.

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

MathMLは全ての要素にhrefを認めています. しかしながら, ほとんどのソフトウェアは, 入れ子になったリンクまたは視覚的に描画されない要素でのリンクを実装する方法を持ちません. そのようなリンクは何ら効果がありません.

MathML allows the href attribute on all elements. However, most user agents have no way to implement nested links or links on elements with no visible rendering; such links may have no effect.

通常視覚的に描画されず, そのためリンク要素として利用すべきでないプレゼンテーションマークアップ要素の一覧は, 下の表に示すとおりです.

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

リンクの仕組みに対応した複合文書書式において, id属性は, MathMLの式へのリンクの場所を特定するために使用すべきです. id属性は全てのMathML要素で認められており, その値は文書の中で唯一のものでなければなりません.

For compound document formats that support linking mechanisms, the id attribute should be used to specify the location for a link into a MathML expression. The id attribute is allowed on all MathML elements, and its value must be unique within a document, making it ideal for this purpose.

MathML2は, リンクに直接対応していないことに注意して下さい. MathML2は, W3C勧告"XMLリンク言語" [XLink]を参照しており, xlink:href属性を利用して複合文書の中のリンクを定義していました. 上で話したように, MathML3はリンクのためのhref属性を加えたことから, xlink:hrefはもはや必要ありません. しかしながら, MathMLがMathMLでない名前空間の属性の利用を認めていることから, xlink:hrefは今でも利用可能です. 新しい複合文書書式は, リンクにMathML3href属性を使用することが推奨されています. ソフトウェアが, hrefとxlink:href属性の両方を持つMathML要素に出くわしたとき, href属性が優先されるべきです. 以前との互換性に対応するため, MathML2を含む複合文書でXMLリンクを実装したソフトウェアは, href属性への対応に加えて, xlink:href属性の利用への対応も継続すべきです.

Note that MathML 2 has no direct support for linking; it refers to the W3C Recommendation "XML Linking Language" [XLink] in defining links in compound document contexts by using an xlink:href attribute. As mentioned above, MathML 3 adds an href attribute for linking so that xlink:href is no longer needed. However, xlink:href is still allowed because MathML permits the use of attributes from non-MathML namespaces. It is recommended that new compound document formats use the MathML 3 href attribute for linking. When user agents encounter MathML elements with both href and xlink:href attributes, the href attribute should take precedence. To support backward compatibility, user agents that implement XML Linking in compound documents containing MathML 2 should continue to support the use of the xlink:href attribute in addition to supporting the href attribute.

6.4.5 MathMLと画像のマークアップ
MathML and Graphical Markup

新しい字形の導入を別にすれば, 画像を利用したいと思う状況の多くは, 文字付きの図式を表示する場合です. 例えば, 結び目図式, ベン図, ディンキン図形, ファイマンダイアグラム, 可換図式は全てこの状況に分類されます. そのような, それらの中身は, 構造化された画像とMathMLマークアップを組合せることを通じて, より良くコード化できるでしょう. しかしながら, このことについて書く場合に, "文字付きの図式"としてそのような概念をコード化することは, W3C数学事業の範囲の及ばないところです. (最新の数学におけるW3Cの事業についてはhttp://www.w3.org/Mathを, W3Cの画像事業についてはhttp://www.w3.org/Graphicsを参照して下さい.)

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

semantics要素を利用して, 追加の画像の内容を埋め込む仕組みの1つは, 次の例のとおりです.

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

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

ここで, annotation-xml要素は, 2つの集合の集合積をMathMLコンテントで描画する代わりの表現を示すのに使用しています. 1つ目のものは, "Scalable Vector Graphics"書式[SVG1.1](MathMLとSVGを統合したXHTMLの概要の定義は[XHTML-MathML-SVG]参照)で, 2つ目のものは, XHTMLの断片として埋め込まれるXHTMLimg要素を利用しています. この状況では, MathML処理プログラムはこれらの表現のどれでも表示に利用することができ, ひょっとしたら下記の画像のような画像書式を提供するかもしれません.

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

この例の意味の表現は, MathMLコンテントマークアップで, semantics要素の最初の子要素として与えられていることに注意して下さい. この点に関して, XHTMLのimg要素のalt属性とほとんど同じ表現で, 視覚的でない表現では最も適切な選択になるでしょう.

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

6.5.1 属性とスタイルシートを処理する順番
Order of processing attributes versus style sheets

CSSまたは類似したスタイルシートは, 選択したMathML要素の描画特性の変更を指定することができます. 描画特性は, 要素の属性からも変更することができたり, 描画ソフトウェアによって自動で変更されたりすることから, 様々なデータから要請された変更が適用されるべき順番を指定する必要があります. 順番は, CSSでない表現の助言の優先度を考慮した順番を幾層にも重ねることで[CSS21]で定義しています.

CSS or analogous style sheets can specify changes to rendering properties of selected MathML elements. Since rendering properties can also be changed by attributes on an element, or be changed automatically by the renderer, it is necessary to specify the order in which changes requested by various sources should occur. The order is defined by [CSS21] cascading order taking into account precedence of non-CSS presentational hints.