本書は、XmlLite の利用を検討した際の作業メモになります。 環境の構成は、以下を前提とします。
記述範囲は、利点と欠点、躓きやすいポイントだけとなります。 サンプルコードは掲載しません。
結論は、相当に便利です。 使いやすいです。
XML 形式でファイルを交換する事を検討しているならば、これを使うことをお勧めします。
大雑把に利点と欠点を挙げると以下のようになります。
【利点】
【欠点】
当然ですがXML がどういうものかを理解している事が前提です。
大まかに機能を整理すると以下のようになります。
入出力種別 | 処理のフェーズ | 機能提供の有無 | 備考 |
---|---|---|---|
入力 | 字句解析 | ○ | テキストファイルから漢字コードをエンコードした上でトークンに切り出す |
構文解析 | ○ | トークンから要素(element)属性(attribute)要素に挟まれた文字列などを認識 | |
意味解析 | × | 要素、属性、文字列などの意味を認識 要素の入れ子、順序の誤りを検査 |
|
出力 | 意味変換 | × | 内部データを文字列に変換 |
要素出力 | ○ | XML タグに変換して出力 | |
エンコード | ○ | 漢字コードを変換 |
純粋なプレーンテキストファイルを入出力する際に便利なストリーム系のライブラリ関数がありますが、 XML 形式でテキストファイルを書き出す為に必要な機能が追加されたライブラリと理解しました。
恐らくですが存在が広く周知されれば、確実に普及すると感じました。
日本語で解説されたサンプルコードがネットワークに幾つかありましたので、サンプルコードは割愛します。
躓きやすいポイントと用語を記述します。
箇条書きで記します。
最後の項目は(XmlLiteは)デフォルトだとDTD を参照しない為に検査しようがないという話です。
尚、DTD を参照する設定にした場合は検査してくれるのか?どうかは、必要な方が調べてください。
以下で言う用語とは、XmlLite が定義する意味になります。
用語 | 意味 |
---|---|
nodeType | ノードの種類を指す。 検出した字句やXML が定義する特殊な要素をノードと呼ぶ様子 |
prefix | 調べていません |
localName | 殆どの場合、XML 要素の属性を指す |
namespaceUri | XML 名前空間を指す。 詳しく調べていません |
value | 属性の値を指す |
element | 要素の名前を指す |
elementString | 要素で囲まれた文字列を指す |
nodeType、localName、value、elementStringだけ意識しておけば、利用する上で困らないと推測します。
XML 自体が機械的にテキストファイルを記述し、かつ読める事を目的しているので「だからどうした」という話です。
XML を利用したから機能面で直接にプラスとなる事はありません。
データの保守性を強化できるような気がするだけです。
実際プレーンファイルで充分に記述できる事柄を、敢えてXML 形式で記録する利点はありません。
データ保存形式の一つと認識しておけば、問題ないかと思います。
但し、不特定多数の人間と幅広くファイルを交換する要件がある場合、XML 文書の規格に沿った形式で仕様を定めるとメリットがあると考えます。
こういった要件がある上でWindows 上で実現したい時、本文書が役に立てば幸いです。
【駄文】
書く上で必要性は薄いが、XML 文書形式で保存されたファイルを読む機会は増えてくる気がします。
実際、一つ前のページでCOLLADA DOMについて記述しましたが、あれもXML 文書形式で記述されています。
自力でパーサを記述するのは、検査と実装の工数が膨らみます。
MsXml や.netFrameworkを利用する場合、ネットワーク接続を必須とするので、このXmlLite は選択肢として「あり」だと考えます。
作成日:2010/11/01