DTDパーサー

  以下のように考えて、パーサを作って、MathML の DTDを表示してみました。
  Silverlightアプリケーションで、図をクリックすると実行します。

  IE9もデフォルトではMathMLを表示しないようです。
  SVGは表示できます。
  そこで数式や図をSVGでHTMLにインラインすることにして見ようと考えました。MathMLをSVGに変換することを考えます。
  MathMLの入力は、ワードや数式入力パネルなどからクリップボード経由でコピーします。

  わたしは、MathMLもSVGも知らないので、DTD記述から、それぞれの構文を知ろうと思います。

1. DTDもXMLとしてパースできると思ったのですが、少なくともSilverlightのXmlReaderでは読むことができませんでした。
   「DTDの効果」
2. DTD記述自体の定義は、「Extensible Markup Language (XML) 1.0 (Fifth Edition)」に、BNFで記述されているもののようです。

  XmlReaderはDTDを正しく扱いますが、DTD自体をドキュメントとして扱うことはできないようです。
  DTDをパースするプログラムがあるはずですが、分からないので簡単なパーサーを作って調べます。
  このパーサはXMLを読むのにも使います。「DTDの効果」で調べたことからすると、XmlReaderは、参照をすべて展開します。展開していない状態を取得したいと思います。
  目的がMathMLの構文の理解なので、参照用に振られたシンボルには意味があります。

文字セット

  パーサーを作る上で文字の表現方法が気になります。入力となるバイト列は、さまざまなコード系の可能性があります。

1. XMLドキュメントには XMLDecl が記されている。
2. MathMLのDTDには、XMLDeclがない。
3. プログラミング上ではUTF16エンコードのUnicodeを扱う。

  MathMLのDTDは、ASCIIコードだけで記述され、どのエンコードと見ても、解釈が変わらないものだと思います。
  また、DTD が Unicode なら、名前に、どの文字を使っても問題が起きません。解析に使われる '<' などのマークとは絶対に一致しないからです。
  文字コードの問題は、いろいろなことが考えられますが、Unicodeだけを対象にしようと思います。

Unicodeについて

  Unicodeだけを対象にしようと思いますが、すこし補足します。

SJISとUnicodeファイル

  字形ごとに一意な数値を割り当てたものが文字コードですが、127以下の部分については、どのコード系でも、原則、同じ対応になっています。
  Unicodeには、BOM(Byte Order Mark)が定められていますが、これがない場合は、127以下の文字だけからなるファイルは、SJISのファイルもUnicodeのファイルも同一内容だと言うことです。
  テキストエディタで半角英数だけを書いて、SJISと、BOMなしのUnicodeで保存すると全く同じファイルになります。
  0 から 127 の部分は、「Basic Latin」、「Ascii」などと呼ばれます。ISO646、JIS X 0201の1面、Latin1、ISO8859の前半と言うこともできます。
  この範囲のコードだけが使われている MathML の DTDファイルの扱いには問題が起きないと言うことです。

ファイル上の表現とプログラムでの扱い

  MathMLのDTDファイルは、Basic Latin の文字のみから成るので問題がありませんが、それ以外の文字が、プログラムでどのようになるのか見ておきます。
  テキストエディタで、"あ" 1文字だけを入力し、

1. SJIS
2. UTF-8 BOMなし
3. UTF-8 BOM付き
4. UTF-16BE BOMなし
5. UTF-16BE BOM付き

  の形式で、5つのファイルを作って読み込んでみます。
  読み込む方法は、

1. Stream.ReadByte()
2. TextReader.ReadToEnd()
3. StreamReader.ReadToEnd()

結果は以下のようです。

1. "あ" の Unicode は 0x3042 です。プログラムで扱うのは常にこのコードです。
   プログラムで扱うUnicodeは、特にバイト数に決まりはなく、値と考えます。
   Unicodeの値の最大は、0x10ffff。
2. Unicodeをメモリやファイルに格納する場合は、バイト単位に分割することになるので、文字の区切りが分かるようにする必要があります。
   このためのエンコードが、UTF-8やUTF-16です。これらは1文字のバイト数は可変です。UnicodeをUTF-8にエンコードすると1文字は最大6バイトになります。UTF-16の場合は、2バイトか4バイトになります。
3. デフォルトはUTF-8で、BOMの有無にかかわらず読み込めます。
4. UnicodeならBOM(Byte Order Mark)があれば、エンコーディングに係らず読み込めます。
5. UTF-16BE BOMなしの場合、UTF-8と見なすので、0x30、0x42は半角2文字（'0'、'B'）として読み込まれました。
6. SJISの"あ" 0x82a0は、0xfffd として読み取られました。Unicodeの0xfffdは、REPLACEMENT CHARACTERと名前が付いています。
   0x82が、字形を持つUTF-8の1文字目としては未使用なためだと思います。

BMP外のUnicode

  TextReaderを使って読み出せば、Unicodeのデコードの問題はないと考えたのですが間違いでした。
  「文字（char、int、string、BMP外のUnicode）」に記したように、プログラム上はUTF-16エンコードのUnicodeの処理が必要でした。
  char型が16ビットです。TextReader.Read()の返す値は32ビットのint型です。
  しかし、いずれも同じ値を返し、16ビット以上のUnicodeを表現できません。
  string自体は、UTF-16エンコードで正しくUnicodeの処理を行います。
  具体的には、読み出した16ビットの値が、サロゲートペアの先頭かどうかを見ることが必要で、サロゲートペアの場合、続く16ビットと合わせて、2つのchar型の値から1つのUnicodeにデコードすることになります。
  あるいは、一括してUTF-32にエンコードすることも考えられます。

DTDのパッケージ

  W3のページからMathMLのDTDをダウンロードすると、ZIPファイルで複数のファイルから成り立っています。
  単に複数ファイルをまとめたものなのか、パッケージングのルールがあるのかはわかりませんが、ZIPファイルをフォルダとして扱うことになります。

パーサーの目的

  Visual Studio のエディタでXMLファイルを編集する場合、DTD定義はリアルタイムに反映されます。DTDにしたがって、構文チェックが行われエラー箇所がマーキングされます。また、文脈依存で入力補完も機能します。また、参照の未定義も検出されます。「DTDの効果」
  この場合、DTDは以下の機能を実現しています。

1. 構文チェック
2. 入力補助
3. 文字の実体参照宣言

  この場合、パーサーは、規格に忠実な解析が必要で、エラーが見つかっても解析を続けることになります。
  ブラウザのように、表示が目的なら、規格に忠実でなくてもそれなりに表示される方が適切です。

  今回は、MathMLからSVGへの変換に必要な構文情報をC#のコードの形で取り出すことが目的です。
  基本的に入力にはエラーがないものとして、エラーがあればそこで打切るように作ります。

気になる点

  作成する前に気になることを調べておきます。「文字（char、int、string、BMP外のUnicode）」

1. 文字

   1. Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] 
   2.        | [#xE000-#xFFFD] | [#x10000-#x10FFFF]

   C#で文字として入力した場合、UTF-16エンコードのUnicodeとして扱うことになる。
   C#のchar型は16ビットで、0xD800 - 0xDFFF の区間（Surrogate Area）はサロゲートペアに使われ、2つ char から、0x10000 - 0x10ffff の1つのUnicode 文字に変換される必要がある。
   このことは、ファイルサイズやcharの数と、文字数が一致しないことを示し、読み込んで、サロゲートぺアを処理するまで文字数が分からないことを示す。
   ファイルの先頭の0xfffe、oxfeff は、BOMに使われるので入力結果には反映されないものと考える。
   SJISをUTF-8として読み込んだ場合は、前述の例のように 0xfffd などの、Charに含まれるUnicodeとして読み取られる。
2. Nameのハイフンとアンダースコア
   XAMLでは、Nameは、アンダースコアが有効で、ハイフンが使えない。
   XMLでは、先頭以外にハイフンが有効。アンダースコアは、先頭にだけ許される。
3. NameはAscii文字に限らない
   

   1. NameStartChar::= ":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6]
   2.                | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D]
   3.                | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] 
   4.                | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] 
   5.                | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF]
   6. NameChar ::= NameStartChar | "-" | "." | [0-9] | #xB7 
   7.            | [#x0300-#x036F] | [#x203F-#x2040]
   8. Name ::= NameStartChar (NameChar)*
4. リテラル（文字列）
   single-quotation と double-quotation は、それぞれペアで使い、等価。
   single-quotationのペアは、double-quotation を普通の文字として含むことができる。
   double-quotationのペアは、single-quotation を普通の文字として含むことができる。
5. リテラルの記述箇所による差異
   ・SystemLiteral
   外部参照のDTDファイルを指す文字列は、前述のルールに従う。
   ・AttValue
   属性値として記述される場合は、'&'、'<' を、普通の文字として含むことができない。
   '&' は、 &name; のような参照と解釈される。
   ・EntityValue
   Entityの定義のSYSTEM の値として記述される場合は、'&'、'%' を、普通の文字として含むことができない。
   &name; や %name; のような参照と解釈される。
   ・PubidLiteral
   Entityの定義のPUBLIC の値として記述される場合は、字類に制約がある。
   

   1. PubidLiteral ::= '"' PubidChar* '"' 
   2.                | "'" (PubidChar - "'")* "'"
   3. PubidChar ::= #x20 | #xD | #xA | [a-zA-Z0-9]
   4.             | [-'()+,./:=?;!*#@$_%]
6. リテラルは、記述箇所が決められているので、その他では、
   single-quotation 、double-quotation は、普通の文字として扱われペアとして扱われない。
7. MathMLのDTDは、「document」の構造になっていない。
   これについて明確な記述はわからないが、extSubset が該当し、機能的には intSubset に準じると解釈して置く。
8. マークアップであるので、マークアップ記述と、マークアップされる対象がある。
   マークアップされる対象は、CharData で、XMLの文字セットから、'<'、'&' を除外した文字列となる。さらに、"]]>" と言う文字列も除外される。
   '<' は、マークアップ記述中に含まれるので、先頭から見ていく必要がある。
   Comment、PI、CData、SystemLiteralに、入れ子はない。
9. '<' は、マークアップ記述の開始を示すことになるが、これに要素名が続くケースは、EmptyTag と、STag となる。
   '/' が続く場合は、ETag となる。
   '?' が続くのは、PI(Processing Instructions) となっている。"<?xml " も定義されていて、TextDecl、XMLDecl と名前が与えられている。
   '!' が続く場合は、"<!" としては定義されていない。
10. "<![" で始まるもの
    ・任意個の空白文字の後に、INCLUDE、IGNORE
    ・"CDATA["
    ・%で始まるPEReferenceと'['   （PEReferenceは、INCLUDEかIGNOREを宣言している）
11. "<!" で始まるもの
    DOCTYPE
    ELEMENT
    ATTLIST
    ENTITY
    NOTATION

最初のパース

  BNFに従って見ていくと AttDef で行き詰まりました。
  そこで、少し離れて、左図のようなステートに分けて考えることにします。
  最初のパースでは、出現順に、マークアップされる対象(Text)と、マークアップ記述を列挙することにします。階層はなく、マークアップ間の整合性も調べません。

  このパーサーはXMLにも使いたいと考えています。両方を可にすると、バリデーションできないことになりますが、標準的な（エラーのない）ソースの内容把握が目的なので良しとします。
 また、0x01 などは、XMLの対象外の文字ですが、除外文字はチェックしないことにします。

  ステートへの遷移条件は、比較的明瞭ですが、ステートの終了条件は明瞭ではありません。

  初期状態は、Text ステートとします。
  マークアップされる対象の Text は、DTDの宣言では、インクルードしたファイルに書かれた定義を展開する目的で、参照を記述するのに使用されています。
  これは、Text に %xxx; の参照（PEReference : Parameter-entity references）記述が有効だと言うことです。
  Text部分は、CharData の繰り返しなので、& と < は除外されていますが、%は含まれます。
  ただし、ここでは、この参照を展開しません。後の処理にゆだねることにして、ここでは他の文字と同様そのままTextに含めます。これは、参照名には意味があると考えるからです。記述した人は何かの基準で名前を付けて分類をしています。
  ここでは、&で始まる参照（CharRef と EntityRef）だけを展開します。
  展開前の状態で、< が出現すると Textステートを終わります。

  < に続いて、タグ名が続くケースには、STag と EmptyElemTag があります。
  終端が、/> の場合を EmptyElemTag とします。
  </ に続いて、タグ名が続くケースはETagとして記録します。
  ここでは、&で始まる参照（CharRef と EntityRef）を展開します。
  引用符の認識を行います。引用符内の > は、終端と見なしません。
  STag、EmptyElemTag、ETag は、DTDの記述には出てこないようです。

PI（Processing instructions）

  実際に見かけたのは、<?xml と <?IS10744 です。
  これは、?> までを無条件に切り出して記録します。
  何の処理もしません。
  ここには、エンコーディングが記されますが無視します。
  UTF-8以外のエンコードが必要な場合は、その都度ユーザーがエンコードを選択するものとし、パーサーのオプションで指定することにします。
  また、<?xml は、空白を伴って定義されていますが、空白文字なら可とします。

Comment

  --> が出現するまでのすべての文字をコメントとして記録します。
  DOCTYPE中に記述されることがあり、その場合はDOCTYPEの情報として記録します。

CDATA

  ]]> が出現するまでのすべての文字をCDATAとして記録します。
  他のマークアップ記述中にも記述できます。
  この場合は、単にCDATAの囲みが除去されるだけで、CDATAを独立に記録しません。

宣言

  <! に続いて、宣言を記述するケースには、大別して DOCTYPEと、その他（DTDの記述に使われるELEMENT、ATTLIST、ENTITY、NOTATION）に分けられます。

DOCTYPE

  DOCTYPEは、documentに関する記述で、DTDにはないようです。
  DOCTYPEは、DTDを含むことができます。
  ここでは、DOCTYPEはそのまま記録します。
  ここでは、&で始まる参照（CharRef と EntityRef）を展開します。
  引用符の認識を行います。引用符内の > は、終端と見なしません。
  引用符外のブラケット（ [ と ] ）を認識します。
  この中には、DTDの記述が可能で、PI、コメントも含まれます。
  ここでは、%で始まる参照(PEReference)を展開します。

ENTITY

  GEDecl と PEDecl があります。
  対応する宣言は、それぞれ ENTITY名と、% ENTITY名です。
  参照は、&ENTITY名; と、%ENTITY名; です。
  PEDeclは、XMLファイルに読み込まれる、独立したDTDファイル内でのみ有効です。XMLファイルのDOCTYPE中以外に記述することはできません。
  したがって、PEDecl定義は、最終的にはGEDeclで参照され、そのENTITY名で、&ENTITY名; のようにXMLで使われることになります。

ELEMENT

  XMLの普通の要素名（タグ名）と、その形式を宣言します。コンテンツの有無と、入れ子になる要素を宣言します。

ATTLIST