| MAP | SASAX ドキュメント > 動機 [ <| 1| 2| > ] |
XML 文書の解析に DOM(Document Object Model) API を用いることで、 状態遷移の管理が不要になります。
しかしご存知のように DOM API は、 メモリ上に構築した XML 文書全体に相当する DOM ツリーを返却しますから、 （非常に？）多くのメモリを必要とします。
その一方で、 SAX API は XML 文書の構造を、 データ構造としてではなくイベント（＝メソッド起動）列として表現するため、 DOM API と比較して少ないメモリしか必要としません。 "メモリ効率" および "イベント駆動モデル" には訴えるものがあります。
備考: もちろん、常に誰もが "イベント駆動モデル" を気に入るわけではないことは承知しています。 "イベント駆動モデル" は人によっては難解なものに思えるようです。
DOM は "型無し" 性 ないし 名前空間に関する貧弱さによる複雑さを解決できません。
XML Schema のようなスキーマ言語を併用することで、 自分自身で XML 文書の正しさを検証する必要はなくなります。
しかし、 固有のデータ構造を作り上げるためには、 文字列から他の型へのデシリアライズや、 文脈の管理（例.: 入れ子構造における現在位置） が依然として必要とされます。
備考: 申し訳ありませんが、 私はスキーマ言語が接頭辞付きの要素／属性値の問題を解決可能か確証がありません。 解決できないように思われますが、 そうでないなら是非ご一報ください。
XML バインディングは、 文脈管理および"型無し" 性を解決可能と思われます。
備考: 申し訳ありませんが、 私は XML バインディングが接頭辞付きの要素／属性値の問題を解決可能か確証がありません。 解決できないように思われますが、 そうでないなら是非ご一報ください。
さてここで質問です： あなたのやりたいことは "XML 文書の取り扱い" ですか？ それとも "オブジェクトマーシャリングの形態の一つとしての XML 文書フォーマットの選択" ですか？
前者にとって XML バインディングは良い解決方法に思われます。 XML バインディングは、 XML 文書としてのデータ構造の正しさを保ち、 それを（再度）シリアライズすることを手助けしてくれます。
しかし、後者にとっては XML バインディングは重すぎませんか？ XML バインディングフレームワークによって生成されたコンテナは、 バインディングフレームワークに強く依存してしまいます。
Digesterも文脈管理および"型無し"性を解決可能と思われます。
備考: 申し訳ありませんが、 私は Digester が接頭辞付きの要素／属性値の問題を解決可能か確証がありません。 解決できないように思われますが、 そうでないなら是非ご一報ください。
では、何故 Digester ではないのでしょうか？
それは、 リフレクション機能ベースのメソッド起動は、 プログラムを実行してみるまでメソッド起動自身の成否が不明であることから、 コンパイラによるプログラムの検証を妨げるため、 私があまり好きではないからです。
備考: 私はリフレクション機能自体を嫌っているわけではありません。 名前の知れないクラス（ないしそのインスタンス）に対して、 インスタンス生成、デコレーションないし委譲を実現するためには、 非常に有用な機能です。
結論として、 私が必要としているのは、 前節で述べた問題以外に、 以下の問題も解決できるフレームワークである、 ということに気が付きました。
そして同時に、 それを自分自身で開発しなければならないことにも気付きました。
| MAP | SASAX ドキュメント > 動機 [ <| 1| 2| > ] |