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

概要: 数学用マークアップ言語 (MathML) ヴァージョン 3.0 第2版
Overview: Mathematical Markup Language (MathML) Version 3.0 2nd Edition
前へ: 5 数式に対するマークアップ言語の混在
Previous: 5 Mixing Markup Languages for Mathematical Expressions
次へ: 7 文字, 実体, 書式
Next: 7 Characters, Entities and Fonts

6 ホスト環境との相互作用
Interactions with the Host Environment
    6.1 導入
    Introduction
    6.2 MathML処理プログラムを呼び出す
    Invoking MathML Processors
        6.2.1 XMLの中のMathMLの認知
        Recognizing MathML in XML
        6.2.2 HTMLの中のMathMLの認知
        Recognizing MathML in HTML
        6.2.3 MathML文書の内容の形式
        Resource Types for MathML Documents
        6.2.4 MathMLのコード化された名前
        Names of MathML Encodings
    6.3 MathMLを受け渡す
    Transferring MathML
        6.3.1 基となる通信フレーバーの名前と内容
        Basic Transfer Flavor Names and Contents
        6.3.2 受け渡す際の推奨されるふるまい
        Recommended Behaviors when Transferring
        6.3.3 議論
        Discussion
        6.3.4
        Examples
            6.3.4.1 例1
            Example 1
            6.3.4.2 例2
            Example 2
            6.3.4.3 例3
            Example 3
            6.3.4.4 例4
            Example 4
    6.4 MathMLと他の言語を組合せる
    Combining MathML and Other Formats
        6.4.1 MathMLとXHTMLの混在
        Mixing MathML and XHTML
        6.4.2 MathMLとXMLでない言語の混在
        Mixing MathML and non-XML contexts
        6.4.3 MathMLとHTMLの混在
        Mixing MathML and HTML
        6.4.4 リンク
        Linking
        6.4.5 MathMLと画像のマークアップ
        MathML and Graphical Markup
    6.5 MathMLと一緒にCSSを利用する
    Using CSS with MathML
        6.5.1 属性とスタイルシートを処理する順番
        Order of processing attributes versus style sheets

6.1 導入
Introduction

効果的であるように, MathMLは, 幅広い種類の描画ソフトウェア, 処理プログラム, 変換ソフトウェア, 編集ツールとうまく機能しなければなりません. この章は, MathMLを生成したり描画したりすることに関する連携部分での問題点について, いくつか挙げます. MathMLは第一にインターネットの文書をコード化するために存在していることから, ひょっとしたら最も重要な連携部分の問題点は, MathMLを[HTML5][XHTML], もしくは新しく現れる何らかのHTMLに埋め込むことに関係するかもしれません.

To be effective, MathML must work well with a wide variety of renderers, processors, translators and editors. This chapter raises some of the interface issues involved in generating and rendering MathML. Since MathML exists primarily to encode mathematics in Web documents, perhaps the most important interface issues relate to embedding MathML in [HTML5], and [XHTML], and in any newer HTML when it appears.

MathMLを他のXML文書に埋め込む際に起こる3種類の連携部分の課題があります. 1つ目の課題として, MathMLのマークアップは, 有効な埋め込まれたXMLと認知され, エラーが無いものでなければなりません. この課題は, XMLの名前空間[名前空間]を管理する第一の課題として見なされるかもしれません.

There are three kinds of interface issues that arise in embedding MathML in other XML documents. First, MathML markup must be recognized as valid embedded XML content, and not as an error. This issue could be seen primarily as a question of managing namespaces in XML [Namespaces].

2つ目の課題として, HTML/XHTMLにおいて, MathMLの描画はブラウザと統合されていなければなりません. ブラウザの中には, 既に元々の機能としてMathMLの描画を実装しているものもあり, よりたくさんのブラウザがその機能を実装することが期待されています. 同時に, 他のブラウザは, 別のソフトウェアメーカーや他の備え付けの技術によって, MathMLや他の埋め込まれたXMLの内容を描画することを促す基盤を開発してきました. この備え付けの技術の例としては, 現在利用可能な洗練されたCSS描画エンジンや一般的となったJavaScript/ECMAScriptの強力な実装があります. これらのブラウザ特有の仕組みの利用は, 一般にこれらを活性化する種類の追加の連携部分のマークアップを必要とします. CSSの場合は, CSS 2.1 [CSS21]に対応したCSS描画エンジンに合わせたMathMLの特別な制限された形式[MathMLforCSS]があります. このMathML3の制限された概要は, MathML3の完全な表記の豊かさは提供できませんが, 現在のCSSエンジンによって外面上で許容できる内容で描画できる, どこでも利用できる単純な形式を提供しています.

Second, in the case of HTML/XHTML, MathML rendering must be integrated with browser software. Some browsers already implement MathML rendering natively, and one can expect more browsers will do so in the future. At the same time, other browsers have developed infrastructure to facilitate the rendering of MathML and other embedded XML content by third-party software or other built-in technology. Examples of this built-in technology are the sophisticated CSS rendering engines now available, and the powerful implementations of JavaScript/ECMAScript that are becoming common. Using these browser-specific mechanisms generally requires additional interface markup of some sort to activate them. In the case of CSS, there is a special restricted form of MathML3 [MathMLforCSS] that is tailored for use with CSS rendering engines that support CSS 2.1 [CSS21]. This restricted profile of MathML3 does not offer the full expressiveness of MathML3, but it provides a portable simpler form that can be rendered acceptably on the screen by modern CSS engines.

3つ目の課題として, MathMLを生成したり処理したりする他のプログラムは, 利用者と意思疎通ができなければなりません. 数々のMathMLソフトウェアが, 編集ツール, 変換ソフトウェア, 数式処理システム, 他の科学的なソフトウェアを含めて, 開発されてきたか開発されています. しかしながら, MathMLの式は長くなる傾向があり, 手入力すると間違いがちです. そのため, 特別な強調する機能が, 使い勝手の良い変換ソフトウェアや編集ツールによって, MathMLの生成を容易にすることを確実にしなければなりません. それらのソフトウェアは, 信頼できる, 環境に依存せず, 製造元に依存しない方法で協調して動作すべきです.

Third, other tools for generating and processing MathML must be able to communicate. A number of MathML tools have been or are being developed, including editors, translators, computer algebra systems, and other scientific software. However, since MathML expressions tend to be lengthy, and prone to error when entered by hand, special emphasis must be made to ensure that MathML can easily be generated by user-friendly conversion and authoring tools, and that these tools work together in a dependable, platform-independent, and vendor-independent way.

この章は, コンテントマークアップとプレゼンテーションマークアップの両方に適用され, 第5.1節 付加情報の枠組みで述べたsemantics, annotation, annotation-xml要素に対する特別な処理モデルについて説明します.

This chapter applies to both content and presentation markup, and describes a particular processing model for the semantics, annotation and annotation-xml elements described in Section 5.1 Annotation Framework.

6.2 MathML処理プログラムを呼び出す
Invoking MathML Processors

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 MathMLを受け渡す
Transferring MathML

MathMLの式はしばしば, コピー貼り付けまたはドラッグアンドドロップといった, よく知られた枠組みを利用するソフトウェア間で交換され, ファイルに保存されたり, HTTPプロトコルを通じて交換されたりします. この節は, そういった受け渡しの際にMathMLを処理するのに推奨される方法を提供します.

MathML expressions are often exchanged between applications using the familiar copy-and-paste or drag-and-drop paradigms and are often stored in files or exchanged over the HTTP protocol. This section provides recommended ways to process MathML during these transfers.

この節で述べているMathMLデータの受け渡しは, しばしばメディアタイプ, クリップボードフォーマット, データフレーバーと呼ばれる, いくつかのフレーバーを利用可能なMathMLデータを作る, 2つのソフトウェアのデータの間で起こります. これらのフレーバーは, 通常は提供するソフトウェアの優先度の順に並べられ, 通常は利用するソフトウェアの望ましい順で探索されます. コピー貼り付けの枠組みは, 中央のクリップボードに, クリップボードフォーマットごとに1つのデータの流れとして, ソフトウェアにそれ自身のデータを置くことを認めています. 利用するソフトウェアは, それ自身が望む形式のデータを選んで読み込むことで折衝します. ドラッグアンドドロップの枠組みは, 利用可能な形式を宣言することで, その形式のデータを提供することを, ソフトウェアに認めています. データを受け入れることになるソフトウェアは, 利用可能な形式の一覧に基づき, ドロップを受け入れるか拒否するか決めます. また, ドロップ動作は, 示されている形式の中から1つのデータを引き渡すよう, 受け入れるソフトウェアが求めることを認めています. [HTTP11]におけるHTTP GET通信は, 利用可能なメディアタイプの一覧の送信を, クライアントに認めています. そして, サーバーは, 示されたメディアタイプの中から1つのデータを引き渡します. [HTTP11]におけるHTTP POST通信は, サーバーのソフトウェアが利用可能なメディアタイプと関連付けられたデータの送信を, クライアントに認めています.

The transfers of MathML fragments described in this section occur between the contexts of two applications by making the MathML data available in several flavors, often called media types, clipboard formats, or data flavors. These flavors are typically ordered by preference by the producing application, and are typically examined in preference order by the consuming application. The copy-and-paste paradigm allows an application to place content in a central clipboard, with one data stream per clipboard format; a consuming application negotiates by choosing to read the data of the format it prefers. The drag-and-drop paradigm allows an application to offer content by declaring the available formats; a potential recipient accepts or rejects a drop based on the list of available formats, and the drop action allows the receiving application to request the delivery of the data in one of the indicated formats. An HTTP GET transfer, as in [HTTP11], allows a client to submit a list of acceptable media types; the server then delivers the data using the one of the indicated media types. An HTTP POST transfer, as in [HTTP11], allows a client to submit data labelled with a media type that is acceptable to the server application.

現在の端末環境は, 同じような構造を利用するコピー貼り付けとドラッグアンドドロップによる受け渡しを提供します. ただし, 環境に依存する名前付けの構文を検証しながらです. HTTP通信は全てメディアタイプに基づきます. この節は, ソフトウェアが提供すべき通信の形式は何か, どのようにそれらの形式を名付けるべきか, どのようにそれらの形式がsemantics, annotation, annotation-xml要素を扱うべきか指定します.

Current desktop platforms offer copy-and-paste and drag-and-drop transfers using similar architectures, but with varying naming schemes depending on the platform. HTTP transfers are all based on media types. This section specifies what transfer types applications should provide, how they should be named, and how they should handle the special semantics, annotation, and annotation-xml elements.

3つの折衝の仕組みを要約するために, 次の段落は, 提供され, 受け入れられ, 出力されるフレーバー, それぞれの名前(文字列)と中のデータ(バイナリデータの流れ)について説明します.

To summarize the three negotiation mechanisms, the following paragraphs will describe transfer flavors, each with a name (a character string) and content (a stream of binary data), which are offered, accepted, and/or exported.

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

6.3.4.1 例1
Example 1

あるeラーニングソフトウェアが, MathMLを含んでいるものもあるクイズの問題のデータベースを持っています. MathMLは複数のデータから成り立っており, eラーニングソフトウェアは単にデータを表示部分に渡していますが, 洗練されたMathML解析の能力は持っていません. 結果として, ソフトウェアは与えられたMathMLの実例が純粋なプレゼンテーションマークアップか純粋なコンテントマークアップかのどちらか知らず, 実例が特定のヴァージョンのMathML構文に関して有効か分かりません. したがって, このソフトウェアは, クリップボードに次の形式のデータを置きます.

An e-Learning application has a database of quiz questions, some of which contain MathML. The MathML comes from multiple sources, and the e-Learning application merely passes the data on for display, but does not have sophisticated MathML analysis capabilities. Consequently, the application is not aware whether a given MathML instance is pure presentation or pure content markup, nor does it know whether the instance is valid with respect to a particular version of the MathML schema. It therefore places the following data formats on the clipboard:

フレーバーの名前
Flavor Name
フレーバーの内容
Flavor Content
MathML
<math xmlns="http://www.w3.org/1998/Math/MathML">...</math>
Unicode Text
<math xmlns="http://www.w3.org/1998/Math/MathML">...</math>

6.3.4.2 例2
Example 2

あるWindows環境の数式編集ツールは, MathML3に関して有効な純粋なプレゼンテーションマークアップを生成することができます. 結果として, このソフトウェアは次のフレーバーを出力します.

An equation editor on the Windows platform is able to generate pure presentation markup, valid with respect to MathML 3. Consequently, it exports the following flavors:

フレーバーの名前
Flavor Name
フレーバーの内容
Flavor Content
MathML Presentation
<math xmlns="http://www.w3.org/1998/Math/MathML">...</math>
Tiff (描画された例)
(a rendering sample)
Unicode Text
<math xmlns="http://www.w3.org/1998/Math/MathML">...</math>

6.3.4.3 例3
Example 3

あるXMLスキーマを基にしたMac OS X環境のコンテンツマネジメントシステムは, 数式の集合の複数のMathML表現を含んでいます. その表現は, 著者による混合されたマークアップ, 記号計算プログラムの芯となる純粋なコンテントマークアップ, 印刷出版のための純粋なプレゼンテーションマークアップを含みます. XMLスキーマのシステムによる利用のために, マークアップは名前空間の接頭辞と一緒に保存されます. よって, そのシステムは次のデータを受け渡します.

A schema-based content management system on the Mac OS X platform contains multiple MathML representations of a collection of mathematical expressions, including mixed markup from authors, pure content markup for interfacing to symbolic computation engines, and pure presentation markup for print publication. Due to the system's use of schemata, markup is stored with a namespace prefix. The system therefore can transfer the following data:

フレーバーの名前
Flavor Name
フレーバーの内容
Flavor Content
public.mathml.presentation
<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>
public.mathml.content
<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>
public.mathml
<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> 
public.plain-text.tex
{x \over x-1}
public.plain-text
<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.3.4.4 例4
Example 4

ある同じようなコンテンツマネジメントシステムがインターネットを基にしており, 数式のMathML表現を受け渡します. そのシステムはMathML-プレゼンテーション, MathML-コンテント, Tex, TIFF形式の画像を提供できます. ホームページが見られているとき, そのシステムは次のようなMathMLデータを提供するでしょう.

A similar content management system is web-based and delivers MathML representations of mathematical expressions. The system is able to produce MathML-Presentation, MathML-Content, TeX and pictures in TIFF format. In web-pages being browsed, it could produce a MathML fragment such as the following:

<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>

そのようなデータを受け取りドラッグアンドドロップ動作の一部として出力しようとするWindowsブラウザは, 次のフレーバーを提供できるでしょう.

A web-browser on the Windows platform that receives such a fragment and tries to export it as part of a drag-and-drop action, can offer the following flavors:

フレーバーの名前
Flavor Name
フレーバーの内容
Flavor Content
MathML Presentation
<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>
MathML Content
<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>
MathML
<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> 
TeX
{x \over x-1}
CF_TIFF (formula3848.tiffから要求された画像ファイルの内容)
(the content of the picture file, requested from formula3848.tiff)
CF_UNICODETEXT
<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 MathMLと他の言語を組合せる
Combining MathML and Other Formats

MathMLは普通, 他のマークアップ言語と組合せられて利用されます. 最も典型的な事例は, ひょっとしたらHTMLまたはDocBookといった文書に基づいたマークアップ言語の中でのMathMLの利用かもしれません. 他の文書の要素に基づいたマークアップ言語が, HTML5の中のMathMLやSVGといったように複合文書書式の中に含まれることも一般的です. 他の一般的な利用状況としては, 他のマークアップをMathMLの中に混在させる場合があります. 例えば, 編集ツールは, カーソルの場所を表す要素, または他の状況の情報を, MathMLマークアップの中におそらく挿入するので, 著者は編集を中断した場所を見つけ出すことができます.

MathML is usually used in combination with other markup languages. The most typical case is perhaps the use of MathML within a document-level markup language, such as HTML or DocBook. It is also common that other object-level markup languages are also included in a compound document format, such as MathML and SVG in HTML5. Other common use cases include mixing other markup within MathML. For example, an authoring tool might insert an element representing a cursor position or other state information within MathML markup, so that an author can pick up editing where it was broken off.

ほとんどの文書マークアップ言語は, 行の中の式(または, 画像, 文書の要素等)の概念を持っており, 典型的にMathMLの実例を内容モデルに統合させる自然な文法があります. しかしながら, 他の面で, MathMLの中にマークアップを埋め込むことは, そのように明確に処理することはできません. なぜなら, たくさんのMathML要素で子要素の役割は場所によって定義されるからです. 例えば, applyの最初の子要素は演算子でなければならず, mfracの2番目の子要素は分母です. それらの文脈に他のマークアップが現れた場合の適切なふるまいは未解決のままです. そのようなふるまいが特定の文脈で定義できる場合でさえ, 一般的なMathML処理プログラムに対して, 実装の課題が示されています.

Most document markup languages have some concept of an inline equation, (or graphic, object, etc.) so there is a typically a natural way to incorporate MathML instances into the content model. However, in the other direction, embedding of markup within MathML is not so clear cut, since in many MathML elements, the role of child elements is defined by position. For example, the first child of an apply must be an operator, and the second child of an mfrac is the denominator. The proper behavior when foreign markup appears in such contexts is problematic. Even when such behavior can be defined in a particular context, it presents an implementation challenge for generic MathML processors.

この理由から, 通常MathMLスキーマは, 外部のマークアップ要素をMathMLの実例の中に含めることを認めていません.

For this reason, the default MathML schema does not allow foreign markup elements to be included within MathML instances.

標準的な構文において, 他の名前空間の要素は認められませんが, 他の名前空間の属性は認められています. 知らないXMLマークアップに出くわしたMathML処理プログラムは, 次のようにふるまうべきです.

In the standard schema, elements from other namespaces are not allowed, but attributes from other namespaces are permitted. MathML processors that encounter unknown XML markup should behave as follows:

  1. MathMLでない名前空間の属性は, 静かに無視されるべきです.

    An attribute from a non-MathML namespace should be silently ignored.

  2. MathMLでない名前空間の要素は, annotation-xml要素の中の場合を除いて, エラーとして扱われるべきです. その要素がプレゼンテーション要素の子要素ならば, 第3.3.5節 エラーメッセージ <merror>で述べたように扱われるべきです. その要素がコンテント要素の子要素ならば, 第4.2.9節 エラーマークアップ <cerror>で述べたように扱われるべきです.

    An element from a non-MathML namespace should be treated as an error, except in an annotation-xml element. If the element is a child of a presentation element, it should be handled as described in Section 3.3.5 Error Message <merror>. If the element is a child of a content element, it should be handled as described in Section 4.2.9 Error Markup <cerror>.

例えば, mfrac要素の2番目の子要素が知らない要素だった場合, その分数は, エラーを意図する分母とともに描かれるべきです.

For example, if the second child of an mfrac element is an unknown element, the fraction should be rendered with a denominator that indicates the error.

MathMLが大きな文書型に含まれているように複合文書書式を記述する場合, 設計者はMathMLの内容モデルを, 追加の要素を認めるように拡張するかもしれません. 例えば, 一般的な拡張方法は, MathMLでない名前空間の要素を素子要素の中で認められるように, ただし他の要素の中では認められないように, MathML構文を拡張することです. 知らないマークアップに出くわしたMathML処理プログラムは, 次のようにふるまうべきです.

When designing a compound document format in which MathML is included in a larger document type, the designer may extend the content model of MathML to allow additional elements. For example, a common extension is to extend the MathML schema such that elements from non-MathML namespaces are allowed in token elements, but not in other elements. MathML processors that encounter unknown markup should behave as follows:

  1. 認知されていないXML属性は, 静かに無視されるべきです.

    An unrecognized XML attribute should be silently ignored.

  2. MathML素子要素の中の認知されていない要素は, 静かに無視されるべきです.

    An unrecognized element in a MathML token element should be silently ignored.

  3. MathMLでない名前空間の要素は, annotation-xml要素の中の場合を除いて, エラーとして扱われるべきです. その要素がプレゼンテーション要素の子要素ならば, 第3.3.5節 エラーメッセージ <merror>で述べたように扱われるべきです. その要素がコンテント要素の子要素ならば, 第4.2.9節 エラーマークアップ <cerror>で述べたように扱われるべきです.

    An element from a non-MathML namespace should be treated as an error, except in an annotation-xml element. If the element is a child of a presentation element, it should be handled as described in Section 3.3.5 Error Message <merror>. If the element is a child of a content element, it should be handled as described in Section 4.2.9 Error Markup <cerror>.

この方法で構文を拡張することは, 付録A MathMLを処理するで述べるRelax NGを用いて簡単に行えます. この拡張は, mtextの内容モデルを上書きすることで, 単純にMathML構文に組み込めるでしょう.

Extending the schema in this way is easily achieved using the Relax NG schema described in Appendix A Parsing MathML, it may be as simple as including the MathML schema whilst overriding the content model of mtext:


default namespace m = "http://www.w3.org/1998/Math/MathML"

include "mathml3.rnc" {
mtext = element mtext {mtext.attributes, (token.content|anyElement)*}
}

ここで与えられた定義は, MathML名前空間でない何らかの整形式のXMLを, mtextの子要素として認めようとするものです. 実際はこの定義はとてもあいまいです. 例えば, XHTML+MathML構文は, 単に行の中のXHTML要素をmtextの追加の子要素として認めたがるでしょう. このことは, anyElementをホストの文書型の構文の適切な成果で置き換えることで実現できるでしょう. 第6.4.1節 MathMLとXHTMLの混在を参照して下さい.

The definition given here would allow any well formed XML that is not in the MathML namespace as a child of mtext. In practice this may be too lax. For example, an XHTML+MathML Schema may just want to allow inline XHTML elements as additional children of mtext. This may be achieved by replacing anyElement by a suitable production from the schema for the host document type, see Section 6.4.1 Mixing MathML and XHTML.

複合文書の中でマークアップの種類を混在させる場合に考慮すべき状況としては, 複合文書の型を最初に設計するときが挙げられます. ただし, 文書型が1度固まったら, 特定のソフトウェアの必要性に合わせて内容モデルをさらに修正することは一般に現実的ではないです. しかしながら, そのようなソフトウェアがMathMLの実例の中に追加の情報を保存する必要があるだろう状況がまだ頻繁に起こります. MathMLはしばしば編集ツールによって生成されます. そのため, 特に一般的で重要な状況としては, 編集ツールがMathMLの式と一緒にツール内部の状態についての情報を保存する必要がある状況があります. そのため, 著者は以前の状態から編集を再開できるでしょう. 例えば, 式の不完全な部分を示すために仮のものが利用されるかもしれませんし, また, 式の中の挿入の場所が保存される必要があるかもしれません.

Considerations about mixing markup vocabularies in compound documents arise when a compound document type is first designed. But once the document type is fixed, it is not generally practical for specific software tools to further modify the content model to suit their needs. However, it is still frequently the case that such tools may need to store additional information within a MathML instance. Since MathML is most often generated by authoring tools, a particularly common and important case is where an authoring tool needs to store information about its internal state along with a MathML expression, so an author can resume editing from a previous state. For example, placeholders may be used to indicate incomplete parts of an expression, or a insertion point within an expression may need to be stored.

MathMLの式の中に固有のデータを残す必要があるソフトウェアは, 残すことが可能な状況であっても, 一般に内容モデルを変更せずに残すことを試みるべきです. 2つの必要性に対応するため, 特定の複合文書書式の内容モデルによって認められているかどうかに関わらず, MathMLは, 次の方法によって固有のデータの保存を認めています.

An application that needs to persist private data within a MathML expression should generally attempt to do so without altering the underlying content model, even in situations where it is feasible to do so. To support this requirement, regardless of what may be allowed by the content model of a particular compound document format, MathML permits the storage of private data via the following strategies:

  1. XML名前空間の利用を認めている書式において, 小さいデータに対し, 他の名前空間の属性が, 全てのMathML要素において認められています.

    In a format that permits the use of XML Namespaces, for small amounts of data, attributes from other namespaces are allowed on all MathML elements.

  2. 大きいデータに対して, 第5.1節 付加情報の枠組みで説明しているよに, ソフトウェアは, semantics要素を使うでしょう.

    For larger amounts of data, applications may use the semantics element, as described in Section 5.1 Annotation Framework.

  3. 編集ツールや, 例えば, 著者によってあてはめられるべき完全ではない式に印を付けるといった特定の動作と, プレゼンテーションMathMLのツリー構造を結び付ける他のソフトウェアに対して, 第3.7.1節 式の一部に動作を結び付ける <maction>で説明したようにmaction要素が用いられるでしょう.

    For authoring tools and other applications that need to associate particular actions with presentation MathML subtrees, e.g. to mark an incomplete expression to be filled in by an author, the maction element may be used, as described in Section 3.7.1 Bind Action to Sub-Expression <maction>.

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属性を使用することが推奨されています. ソフトウェアが, hrefxlink: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.

\includegraphics{intersect}

この例の意味の表現は, 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 MathMLと一緒にCSSを利用する
Using CSS with MathML

CSS[CSS21]に対応した環境でMathMLが描画されるとき, CSSスタイルシートを利用して数学の書式の特性を制御することが望ましいです. ただし, MathML配置の構文の書式とCSSの視覚的書式のモデルは完全に異なり, 数学の配置に影響するたくさんの書式の変数は直接の類似した文字表現を持っていないことから, 一番最初に現れたであろう時のように単純ではありません. 類似の特性がある状況でさえ, それらの特性の実用的な値は一致しないかもしれません. この違いのために, MathMLに元から対応しているソフトウェアは, MathMLの配置の構文に適用できるCSSプロパティを, 配置に影響を与えないものに限定することを選ぶかもしれません.

When MathML is rendered in an environment that supports CSS [CSS21], controlling mathematics style properties with a CSS style sheet is desirable, but not as simple as it might first appear, because the formatting of MathML layout schemata is quite different from the CSS visual formatting model and many of the style parameters that affect mathematics layout have no direct textual analogs. Even in cases where there are analogous properties, the sensible values for these properties may not correspond. Because of this difference, applications that support MathML natively may choose to restrict the CSS properties applicable to MathML layout schemata to those properties that do not affect layout.

一般的に言って, 数学書式属性とCSSの相互作用に対応するモデルは, 次のように処理されます. CSSスタイルシートは次のように書式の決まりを提供しているとします.

Generally speaking, the model for CSS interaction with the math style attributes runs as follows. A CSS style sheet might provide a style rule such as:

math *.[mathsize="small"] {
  font-size: 80%
}

この決まりは, smallに設定されているmathsize属性を持つ, math要素の全ての子要素に対して, CSS font-sizeプロパティを設定します. MathML描画ソフトウェアは, CSS環境の書式エンジンに確認し, 返値ををソフトウェア自身の配置アルゴリズムの入力として利用します. MathMLは, 書式情報を描画環境から継承する仕組みを指定していません. しかしながら, 周囲の書式環境の特性とMathMLが指定した描画の決まりの間の相互作用に対し提案されている描画の決まりは, 第3.2.2節 素子要素に共通の数学書式属性で論じられており, より一般的に第3章 プレゼンテーションマークアップを通して論じられています.

This rule sets the CSS font-size property for all children of the math element that have the mathsize attribute set to small. A MathML renderer would then query the style engine for the CSS environment, and use the values returned as input to its own layout algorithms. MathML does not specify the mechanism by which style information is inherited from the environment. However, some suggested rendering rules for the interaction between properties of the ambient style environment and MathML-specific rendering rules are discussed in Section 3.2.2 Mathematics style attributes common to token elements, and more generally throughout Chapter 3 Presentation Markup.

しかしながら, MathMLに対するCSSスタイルシートを書く場合には, いくらかの慎重さが必要なことが強調されるべきです. 数学記号の植字の特性を変えることは, 数式の意味を変えられることから, 文書全体の植字の書式が, 埋め込まれたMatMLの式に影響を与えないような方法で, スタイルシートは書かれるべきです.

It should be stressed, however, that some caution is required in writing CSS stylesheets for MathML. Because changing typographic properties of mathematics symbols can change the meaning of an equation, stylesheets should be written in a way such that changes to document-wide typographic styles do not affect embedded MathML expressions.

避けるべき他の注意点は, 数式の適切な理解に必要な植字の書式情報を提供するためにCSSを使用することです. 意味の上でCSSに依存している式は, 数式処理システムといったCSSでない環境では利用できないでしょう. CSSの決まりの選択子として新しいMathML3.0数学書式属性の論理的な値を利用することで, 式の意味のために必要な書式情報をMathMLで直接コード化することを確実にできます.

Another pitfall to be avoided is using CSS to provide typographic style information necessary to the proper understanding of an expression. Expressions dependent on CSS for meaning will not be portable to non-CSS environments such as computer algebra systems. By using the logical values of the new MathML 3.0 mathematics style attributes as selectors for CSS rules, it can be assured that style information necessary to the sense of an expression is encoded directly in the MathML.

MathML3.0は, どのように利用者のソフトウェアが書式情報を処理すべきか指定してません. なぜなら, たくさんのCSSに対応していないMathML環境があり, いろいろな利用者のソフトウェアや描画ソフトウェアが, CSS情報を読み込む際の幅広く異なった度合いを持っているからです.

MathML 3.0 does not specify how a user agent should process style information, because there are many non-CSS MathML environments, and because different users agents and renderers have widely varying degrees of access to CSS information.

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.

概要: 数学用マークアップ言語 (MathML) ヴァージョン 3.0 第2版
Overview: Mathematical Markup Language (MathML) Version 3.0 2nd Edition
前へ: 5 数式に対するマークアップ言語の混在
Previous: 5 Mixing Markup Languages for Mathematical Expressions
次へ: 7 文字, 実体, 書式
Next: Characters, Entities and Fonts