混乱を招く方法でＸＭＬをややこしくしない事が重要

鶏が先か卵が先かの話ではありませんが、前回はＸＭＬは単独で開発するものではなく、必ずスキーマと共に開発することで、データは確実な実用性の高い保証が出来るということを書きました。単なるＸＭＬの”構造”についての妥当性が確認できても、何の意味もありません。ＤＴＤで使われる要素の種類やその役割を示す属性の付与、これにより構造を保証、XML Schemaはその内容までに深く言及することで、インターフェイスに入力プログラムがあれば「確実におかしな入力を防ぐ」事が可能になります。実際スキーマの設計はＸＭＬの中でもその大半であると言っていいでしょう。そもそもはじめから「対象実体外参照名前空間」などまったく意識する必要はありません。DTDであればELEMENT、XML Schemaであれば、最初からxsd:で設計していけば良いだけです。必要に迫られるまでATTLISTも、simpleTypeも考える必要はありません。まずはできあがりのXMLなど思い浮かべることを止めることです。どうしてもXMLを扱うシステムでは、そこに注視しがちですが、データに確実な保証を与えるつまり、信頼できるデーターとして定義できてないXMLは、とんちんかんな注文書を渡され推測しながら品だしを行うようなものです。（頭の悪い人のために努力することはとても疲れます。何せ理解できていない人のために意味のない指令に従うのですから）RELAX NGには、敢えて触れてはいませんが、これはDTDさえ理解できれば、記述に悩む仕様ではないからです。仕様書はXML Schemaに比べ、わかりやすいと言うよりやたらと”長い”ですが。（対象実体外参照名前空間の概念は理解しておいた方が良いでしょう）重要なのは「構造」ではなく「内容」です。妙な例ですがパスワードを内容に保つといった「気が違った」要素を考えてみましょう。この場合はじめは単なる文字列つまりCDATA(string）ですが、類推を容易にするようなものは避けたいと考え、少なくとも文字の中に数字を含んでいないとダメとすると、要素の結合を利用し２種類の内容を保証する定義を考えれば良いでしょうし、空白も含めるとなれば配列として考えることにもなるでしょう。このコンテナを複合型としたものを単純型に再定義して再利用・・・など、内容から始めると自然と構造のアイデアは出てきます。XMLSchemaは内容に関する制限に対し柔軟で階層的ではなく、コンテナとして保持できるのが特徴です。再利用する際も個別に考えることが出来、内容に対しより注視して考慮できます。余談ですがそれはそれは判りやすいXMLとしてはSOAPがありますね。プロトコルバインディングヘッダに基本的な情報、プロトコル、ホスト情報等があり、内容として要素に囲まれた内容が記述、要素定義を原始に対象外実体参照を利用し要素を定義するといった具合です。これをサーバ側で定義に基づき記述して、ＨＴＴＰプロトコルでデータを記述に基づきクライアントプログラムと通信というシステムですが、結局XMLを利用するプログラムが複雑である割に出来ることが「期待したほど成果がない」のが実体ではないでしょうか。サーバの処理とクライアントの処理が同じＡＰＩとは限らないので、実用的ではありません。（環境を整備しないと使えない。）形はシンプルですが処理方法に課題が多すぎですね。XMLの可用性ではなく単なるインターフェイスとしてしか捉えていないので、当たり前といえば当たり前です。大学での研究発表とは違って、何が出来るかではなく実現出来る成果の結果が価値を決めるのですから。（実現するのは事業ですから）
話がそれましたが、構造に注視すると、XMLをデータを入れておく入れ物としてしか見られなくなり、処理が多様化するだけで意味は全くありません。スキーマを考えたXMLからスタートすればかなり絞り込まれた内容でも、構造を辿ってより多くの情報を保つことが出来るのです。