動機

SAX の利用は "簡素(Simple)" か？

SAX の利用は簡素ではないですよね？ SAX の "簡素(simple)" 性は、 API 定義に関してだけのように見受けられます。

文脈管理

"XML 文書例" に示す XML 文書の解析を行う場合、 以下のような SAX イベントを受理します:

<idList>
  <id>12345</id>
  <id>23456</id>
</idList>

1. startElement("idList")
2. characters("\n ")
3. startElement("id")
4. characters("12345")
5. endElement("id")
6. characters("\n ")
7. startElement("id")
8. characters("23456")
9. endElement("id")
10. characters("\n")
11. endElement("idList")

この時、 "startElement" イベントに対しては以下の処理を：

• "ルート解析"（＝初期）状態で且つ "list" が開始された場合は、 "リスト解析" 状態に状態遷移する
• "リスト解析" 状態で "id" が開始された場合は、 "ID 解析" 状態に状態遷移する
• それ以外の場合はエラーを通知する

"characters" イベントに対しては以下の処理を：

• "ルート解析"、"リスト解析" ないし "ID 解析" 状態の場合は、 空白文字群を無視する
• "ID 解析" 状態の場合は非空白文字を格納する
• それ以外の場合はエラーを通知する

"endElement" イベントに対しては以下のような処理を行うことでしょう。

• "ID 解析" 状態の場合は ID を格納する
• それ以外の場合はエラーを通知する

このため、 (1) ３つの状態（"ルート解析"、"リスト解析" および "ID 解析"） 間での状態遷移と、 (2) ID の中間文字列の格納領域 （"id" 要素の内容が一括して通知される保証が無いため） の両方を管理する必要があります。

DTD や XML Schema 定義を利用する "検証機能付きパーサ" を利用するのであれば、 改行／空白文字による "characters" イベントの代わりに "ignorableWhitespace" を受け取るでしょうし （そしてそれらのイベントは無視出来ます）、 それによって "id" 要素の "startElement" および "endElement" イベントにのみ着目すれば良くなります。 しかし、それでもなお (2) 格納領域の管理が必要です。

また、 例えば異なる構造が交じり合っていたり入れ子になった構造といった、 より複雑な XML 文書の解析を行おうとするならば、 状態遷移の管理が必要であると気付くことでしょう。

"型無し"性

XML 文書においては全てが文字列として表現されるため、 文字列以外の他の型 （例： int、float、double など）の文字列表現形式に対して、 検証／デシリアライズを行う必要があります。

いくつかの型のデシリアライズは、 実行時例外（例：数値型における NumberFormatException）を浮揚したり、 複雑な手順（例：dateTime 型）が必要であったり、 他のユーティリティの機能 （例： hexBinary 型や base64Binary 型）を必要としたりします。

最も重要な事は、 文字列から基本的な値をデシリアライズすることではなく、 ビジネスロジックにおいてこれらのあらわす値 （あるいはその関連性）を検証することの筈です。

名前空間に関する貧弱さ

"start-" および "endElement" SAX イベントは、 要素の名前を識別するために３つの引数、 "名前空間 URI"、 "局所名(local name)" および "修飾された名前(qualified name)" を取ります。

これらの両イベントにおいて "名前空間 URI" および "局所名" を受け取るためには、 名前空間を扱うことの出来る SAXParser （SAXParserFactory に対する "setNamespaceAware(true)" 起動により生成） を利用する必要があります。 それ以外の場合は、"修飾された名前" のみしか受け取れません。

SAXParser の名前空間取り扱い可否に関わらずに利用可能なコードの記述は、 大変難しいのではないでしょうか？ 明らかに必要とされない（であろう）引数を授受するのは無駄ではないでしょうか？

それに加えて、 SAX フレームワークは、 要素や属性の名前に対する名前空間 URI 接頭辞の解決を自動的に行うにも関わらず、 要素や属性の値に対する解決を行いません。

SAX フレームワークは、 名前空間 URI の接頭辞マッピング管理のための通知 API は提供していますが、 完全なマッピングが SAX パーサ内部に保持されている筈であるにも関わらず、 名前空間 URI 接頭辞を調べる機能が全く提供されていません。 そのため、 接頭辞付きの要素値／属性値を検証するためには、 自前でこれを管理しなければなりません。