巷でウワサのXMLに就いて学習する。
この書類から分かることは、学習進捗度の悪さがよくわかる。書きかけの未完成の暫定版。
XMLとは・・・
Webなどのハイパーテキストを記述するのに用いられているHTMLよりも、柔軟でより
メタな情報を記述できるのが特長です。
従来のHTMLとは違ってタグをユーザが自由に決めて使うことができる用にもなって
おり、データベースのレコードみたいな性格も持ち合わせています。
また出力結果のスタイルと、データの構造を分離して管理することによって、汎用
性の高い書類を記述できるといえましょう。
またXMLは、私が昭和６０年代から平成１桁年代ぐらいに構想して発表したユニバーサルなハイパーテキストに大変よく似た言語です。
昭和６０年代から平成１桁年代といいますと・・・ 当時の日本では、たくさんのワープロ専用機が家電製品とともにお店に並んでいました。 パソコンもありましたが今のようにどこにでもある品物ではありませんでした。 そう、１０年前のマイコンブームなど面影を感じることも出来ませんでした。
またワープロ専用機もパソコンで動くワープロアプリケーションも、各社各々が独自に開発したもので、たとえばテキストデータに制御コードを埋め込んだようなファイル形式でした。 各々別々なファイル形式なので、データの交換や流通はほとんど考慮されていませんで、初期のワープロ専用機ではプレーンテキストすら扱えません。 専用ファイル形式では制御コードなどが邪魔でデータの流通には支障があるし、プレーンテキストは他の機種でも読み取ることができる代償として制御コードを全部切り捨ててしまいますので、せっかく苦労して格好のよい体裁をつくっても文章以外の部分は全部捨てることになってしまいます。
パソコン用ソフトといえばジャストシステムの「一太郎、花子」や、管理工学の「桐、松」といったアプリケーションが代表的なものでした。 パソコンへの関心も、店頭に並ぶNEC PC-9801シリーズの製品をみて「これ一太郎でしょ。会社にもある。」っていう声が聞こえるぐらいの程度でした。
ワープロ専用機も短期間で複雑な市場の要求に応えていくためにMS-DOSのような基本ソフトで開発されるようになりはじめて、ようやくプレーンテキストの交換ができるようになってゆきました。 MS-DOSなどOSを利用した製品作りなど年々高度化してゆくワープロ専用機とパソコンの価格差が縮まってゆきましたし、（当時はGUIを動かすには十分なハードとはいえない面もありましたが）パソコンにもMicrosoft Windowsなどが出現しつつある時代でマニアに影響された人々が再びパソコンに注目をしはじめていましたので、それが恐らく専用機の末期だとおもわれます。 これらのパソコン用ソフトも、各社各々で開発されたものでファイル形式にはやはり互換性がないのが恒でした。
なぜドキュメントのファイルをハイパーテキストにしようとおもったのは、東京大学助教授の坂村健が大口叩いているTRONについて、幼き日にニュース報道やマンガはじめて物語、坂村先生の著書でアップルコンピュータ社ハイパーテキストのスタックで実現されているハイパーリンクが紹介されていたこと、などで見聞きしたことも若干影響されていたかもしれません。 それじゃTRONはどうかといいますと、TRONの標準ドキュメントファイルであるTADはTRONコンピュータからみればプレーンなテキストでも、他のアーキテクチャから見ればワープロ専用機と同様に制御コードを含む独自ファイルのひとつにしか過ぎません。 やはりハイパーテキストのデータ構造の全てを目に見えるテキストで表現するべきだと思いました。
当初ユニバーサルなハイパーテキストは、ワープロのファイル形式に互換性がないのが一番の不満だったことから、始めにテキストの体裁をマークアップを考えました。 実際のところどのようにデータを表現すれば問題解決に近いのかというのも、解決しなくてはならない問題でした。
たとえばキャノレーザみたいにページ全てをプログラミング言語LISPで記述するようなものもありましたので、テキストの全てをLISPのようなでプログラミング言語で記述するこも一瞬頭を過ぎりましたが、Lispの入り組んだ括弧の対応に寒気がして止めました。
そして次に<と>で括ったタグを思い浮かべました。
たとえば「ここの文字は<４倍角>４倍の大きい文字</４倍角>になっています。」のようにです。
ワープロにおける制御文字の使われ方にも不満がありましたし、制御の指定も「ここの文字は<４倍角>４倍の大きい文字</４倍角>になっています。」のようにテキスト文章中に埋め込めばとりあえずテキストエディタでも読み書きできるので「タグは自由に命名できるようにするべきだ。」と強く思いました。
<と>で括ったタグが思い浮かんだことで、とりあえず制御文字を含まない目に見える文字だけで、ワープロの体裁の全てを表現できることが予言できました。
ハイパーテキストの構想を創造しているうちに、お正月の住所録などデータベースのことが気になってきました。 データベースのファイルといえば、アプリケーション独自のファイル形式と、BASIC言語の初心者でも簡単に扱える「タブや空白文字で区切ったASCII形式」や、「コンマとクォートで区切ったCSV形式」が主流でした。 当然ながらアプリケーション独自のファイル形式では他のデータベースと交換するのは無理があります。 ASCII形式ではテキストエディタで開いたときにデミリタの空白文字やタブ文字がどこにあるかということを強く意識しなければなりません。 CSV形式では、データがクォートしてあるのでスペースを含むことができるなど、データベース向けのファイル形式の中では柔軟性が高いということでそれなり活用する価値はあるでしょうけど、 ASCII形式やCSV形式では、どの順番にデータが並んでいるフォーマットなのかは、一概にして分かりにくいということで、データの読み込みや書き出しは若干雑多で不便であると感じていました。
そこでASCII形式やCSV形式のレコードに含まれる要素をタグで括ってしまうことを考えました。
ASCII形式やCSV形式のレコードに含まれる要素は、ファイルの用途によって意味が異なります。 タグの名前が固定されたものだとASCII形式やCSV形式のデミリタと代わり映えがしないきがすることをなんとなく予感させていました。 よってデータベースに応用する場合でも「タグは自由に命名できるようにするべきだ。」という考え方のおかげで、人間が見ても「此処から此処までが住所なだ。名前だな。」ということがある程度見当がつきますし、テキストベースでも複雑なデータ構造をもっているデータ表現が可能であることがある程度予言できました。
たとえば住所録の場合に
<住所録>
<連絡先>
<名前>安部がん子</名前><ふりがな>あべがんご</ふりがな>
<郵便番号>180</郵便番号><住所>東京都武蔵野市御殿山１丁目ざわざわ荘５号</住所>
<電話>0422-34-5678</電話>
</連絡先>
<連絡先><名前>磯野香子</名前><ふりがな>いそのきょうこ</ふりがな>
<郵便番号>240</郵便番号><住所>神奈川県三浦郡葉山町４０３１</住所>
<電話>04680-8-6420</電話>
</連絡先>
<連絡先><名前>音在明日香</名前><ふりがな>おとありあすか</ふりがな><郵便番号>106</郵便番号>
<住所>東京都港区芝高輪門前横町３メゾン旭日１０６１号</住所><電話>03-280-5113</電話>
</連絡先>
</住所録>のようにすれば、連絡先というレコードに、住所やフリガナ、名前などどの順番に出現しても処理することが可能になります。 タグ付けすることによって、一般的なデータベースの正規データに比較して柔軟性が増しています。
またタグをどのうように使うかという取り決めさえ分かっていれば、電子商店の注文や支払いなどへの応用も容易に実現するのではないかと予感させてくれました。
XMLは、どのように使われているのだろうか。
最近では
ほかにもWEBを記述するためのXHTMLや平面図のベクトルデータを記述するSVGなどさまざまな応用がある。
XMLの資料はW3Cをみると膨大な仕様書などが存在します。
しかし、読むのが面倒臭いので、藪から棒に書いてしまうのだ。
<?xml version="1.0" encoding="utf-8"?>
<全体>
<題名>XMLサンプルよ～ん。</題名>
</全体>
ここで、1行目の<?xml version="1.0" encoding="utf-8"?>は、書類がXMLのバージョン1.0を用いて記述することを意味しており、書類の記述がUnicodeのUTF-8であることを伝えようとする。
2行目の<全体>は、ドキュメント構造の根っことなるところをユーザが<全体>という名前をつけたタグ。ようするにここからドキュメントが始まる。
2行目の<題名>は、題名を記述する目的でユーザが題名と名前をつけたタグ。
サンプル001のXMLファイルをMS Internet Explorerで表示させると、ソースのツリービューというドキュメントの構造が表示されます。
XMLには、出力のための書式情報が含まれていないので、ただたんに表示すると、このようなドキュメント構造を表現するツリービューがブラウザに表示されます。またタグの間違えがある時などは、エラーメッセージが表示されて、ツリービューは表示されません。もし間違いがあった場合はエラーメッセージを頼りにXMLファイルを編集しなおせばよろしいわけです。
XMLファイルを、Webページの形にして表示させるには、XSLスタイルシート・ファイルを作成してXMLと関連づけると、XSLに記述されている規則に従ってWebページに表示されます。
サンプル002
DTDは、XML文章で使用する「タグの
属性や階層構造および出現順序など」を定義した書類です。
つまりDTDでは「XML書類を記述する文
法」を記述しているのです。
DTDは、EBNFというBNFの方言を用いて記述することになっている。
また、EBNFには、いくつかの方言が存在するらしい。
XMLのDTD記述で用いられるEBNFに関しては、
XMLの仕様書にノートがある。
EBNFの関連規格としてISO/IEC 14977:1996 Information technology -- Syntactic metalanguage -- Extended BNF
がある。
DTDはXML文章のDOCTYPE宣言で、定義されます。
DOCTYPE宣言の書式は<!DOCTYPE ルート・エレメント名
外部サブセット参照 [内部サブセット記述]>となっています。
たとえば、XMLでHTMLを再定義したXHTMLのDOCTYPE宣言をみてみると、
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
のようになっています。
この場合のDOCTYPE宣言で、はで最初に出現するタグは<html>であることを意味します。
つづいてPUBLICと"-//W3C//DTD XHTML 1.1//EN"が公開識別子での指定であることを意味しています。
さらにつづいて、 "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"外部で定義してあるＤＴＤの存在する場所(URI)を指している。
HTMLやXHTMLに内部サブセットを記述しても、インターネットエクスプローラやネットスケープは記述内容を無視してしまうようだ。
どうやらブラウザのHTMLパーサが内部サブセットのDTDを無視するという説が濃厚のようだ。
XHTMLの場合は、.xhtmlのようにHTMLとは別の拡張子をファイルネームを与えることでメディアタイプの切り分けをすることによってXMLパーサで処理される。
大抵のXMLパーサは内部サブセットのDTDを処理してくれる。
エンティティとはなんだろうか。辞書を引くと実体なんていう言葉が出てくる。
実体となるオブジェクトに対して名前を付けておき、文章に埋め込んでおけば、
プログラミングで変数の値を修正する如く文章を管理することができる。
たとえば、<!ENTITY わが社 "有限会社へなちょこシステムズ">
などというエンティティが埋め込まれていたときに
<ニューズレター>XMLテクノロジーを駆使した文章管理システムを&わが社;でも販売することになりました。</ニューズレター>
のようなXML文章は・・・
XMLテクノロジーを駆使した文章管理システムを有限会社へなちょこシステムズでも販売することになりました。のように、オブジェクトの実体に置き換えられる。
テキストを文字コードで管理することは人間にとって少し厄介である。
そこで、文字コードを参照するエンティティを定義しておけば、判りやすい名前でテキスト中の文字を管理できる。
たとえばJISマーク文字を参照する<!ENTITY JIS "〄">
のような定義です。
サンプルファイルEntitySample001.xmlはDOCTYPE宣言で、エンティティの定義をした例です。
XHTMLなどのタグセットで、すでに定義済みのエンティティがあります。
たとえば、著作権の©シンボルを参照する©などです。
DTDの内部サブセット記述にエンティティを定義すると、定義を記述したファイル内のXML文章に対して局所的に有効となります。 たとえばXHTMLのエンティティを拡張する場合の例を以下に示します。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" [
<!ENTITY JIS "〄"> <!-- JIS Mark Symbol U+12292 -->
<!ENTITY kabu "㈱"> <!-- Kabusikigaisya Mark Symbol U+x3231 -->
]>
一つの例として、シンボル ::= 式
と書いた場合は、「シンボルは式と定義される」といったぐあいに説明するのに用いる。
たとえば、母音は「あ・い・う・え・お」であることを説明するのには、
母音 ::= [あいうえお] と書ける。
また、５０音を説明するのに、「あ・い・う・…ん」の総てを列挙しなくとも、
５０音 ::= [あ-ん]のように記述してもよい。
七曜日を説明する場合、
七曜日 ::= (日曜日 | 月曜日 | 火曜日 | 水曜日 | 木曜日 | 金曜日 | 土曜日)
のようにかいて、「七曜日は、日曜日・月曜日・火曜日・水曜日・木曜日・金曜日
・土曜日と定義される」のように説明できる。
土曜と日曜以外を平日を定義する場合は、
平日 ::= ( [^土曜 日曜] | 週間 )と記述できます。
ここで、開き角カッコ[に続くキャレット^が排他集合の始まりで閉じ角カッコ]が集合の終わりです。
XMLはタグを自由に定義できる柔軟な仕様になっている。
つまり書類書式の設計者の気分で様々なタグが定義されることとなる。
ということは熊助さんと八兵衛さんとでは、同じ名前のタグでも用い方の異なるタグを設計する可能性がある。
もしタグのシンボルがもつ意味合いが異なるタグが出現すると、タグの定義が衝突することになる。
そんなことで、定義されている意味の有効である範囲を自明的にしておく必要がある。
注釈文はHTMLと同様に書くことが出来ます。注釈文の始まりが <!-- で、注釈文の終わりが --> です。
<!-- つまりここに注釈文を書くのね -->
でも、コメントの中に-を書くのは、余りお勧めできないようです。
補足情報などいろいろ。
とりあえず、関連サイトへのリンク
順不同。
バッカス・ナウア記法は、プログラミング言語ALGOLの文法を説明するために 考案された言語です。
プログラミング言語の文法を定義したり説明する用途のほかに、多くの情 報科学に関する教科書で、アルゴリズムの説明などに用いられていることがよ くあります。
XMLではDTD書類を記述するのに「拡張バッカス・ナウア記法(EBNF)」が用いられています。 拡張バッカス・ナウア記法には、いくつか方言が存在するそるです。 XMLで用いるバッカス・ナウア記法については、XMLの仕様書にノートがあります。
著作権 大槻昌弥 © 2001年, 2003年
無断転載厳禁。