2006 年 9 月 24 日 23 時 51 分

Extensible Stylesheet Language (XSL)


このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。


XML は、1998 年あたりから急激に発展する。

DOM が出現したことで、プログラマは、
厄介であった XML や HTML の文法解析から解放され、
さらに、Dynamic HTML を併用した、
新世代の Web プログラミングが可能となった。

DOM は、Web ブラウザの組み込み機能だけにとどまらず、
C++ や Java など、多彩な言語でその実装が開発され、
ASP や JSP などでも利用することができた。
そのため、XML はサーバ側の汎用データ形式としても、
利用の機会が増えてくることになる。

さて、XML はそれ自身が文書としての構造を持つため、
XML を設定ファイルのように読み込むのではなく、
XML 自身を何か他の文書形式に変換するような用途が多い。
他の文書形式としては、PDF や Word 文書、
そして、HTML などが該当する。

DOM は、XML 文書の部分編集には向いているため、
元データを XML として持たせておき、
必要に応じてデータの修正をするには最適であったが、
XML 文書を他の形式の文書に変換する際は、
DOM による処理はかなり面倒なものであった。

例えば、XML を HTML に置き換える場合など、
単純にタグ名や属性の変換だけで済む場合であっても、
DOM による「プログラミング」が必要であったのである。

というのも、DOM は、プログラム処理用の規格であるため、
他の形式に変換させるためには、
どうしてもプログラムコードを書く必要があったのだ。

そもそも XML は、文法だけを定めているため、
その要素や属性などの名前や使い方は自由裁量であった。
そのため、XML を作成した人にしか、
要素や属性の使い道は分からないためである。

そこで XML と他の形式の架け橋として誕生したのが、
Extensible Stylesheet Language (XSL) である。

XSL は、XML を他の形式のデータ形式に変換するために、
その変換ルールと、処理手順などを規格化したものだ。

XSL にはスタイルシートという名前が付いているが、
CSS のように、修飾方法を定義するのではなく、
異なる形式に変換することでスタイル(形式)を決める。

XSL は大きく 3 つの異なる技術で成り立っている。

・XSL Formatting Objects (XSL-FO)
・XSL Transformations (XSLT)
・XML Path Language (XPath)

XSL-FO は、印刷文書向けの文書定義を定めた XML であり、
内容やデザインを表現するための要素や属性を定めている。

HTML は CSS の力を借りてデザインを記述したが、
XSL-FO では構造だけでなく、デザインに関することも、
全て属性を使って定義されており、規格に含まれている。
実際の文書向けに、HTML + CSS を発展させたものである。

HTML のように、要素や属性の使い方が決められているが、
HTML とは異なり、XML の規格に適合している。
つまり、XML に準拠した、XML 派生言語である。

以前、論理構造とデザインを分離するメリットを書いたが、
その考えでは、XSL-FO は退化しているような気もする。

XSL-FO のメリットは、それ自身が XML であることである。
つまり、全て XML だけで表現することができるので、
他の文書から、以下で説明する XSLT を使って、
自動的に生成することを目的としているのだ。
そのため、XSL-FO は非常に複雑な規格となっている。

いわば、XML 版の PostScript のようなものである。
PostScript を手書きする人が皆無なのと同じように、
XSL-FO も手書きする用途では考えられていないのだ。

その XSL-FO を活かすための規格が、XSLT である。

XSLT は、XML 文書を、異なる形式の XML 文書に
変換するルールを記述するための XML 派生言語である。

XSLT 自身も、独自の要素や属性を定めているが、
これらは、他の XML 文書に対する変換ルールである。
XSLT で作成した文書を適用すれば、任意の XML 文書を、
XSL-FO などの XML 文書等に変換することができる。

例えば、XML を Web ブラウザで利用する場合は、
HTML による表現へ変換する必要があるが、
DOM を使ってプログラム処理をしなくとも、
XSLT でルールを定めておけば、
XSLT に沿って XML を HTML へ変換することもできる。

最後の、XPath は、主に XSLT と共に使用する。
XML はファイルシステムのような階層構造を持つが、
XPath は、この XML 文書内の特定の要素や属性などを、
「ロケーションパス」と呼ばれる文字列で示す方法を定義する。

例えば、パス「//ul/li」は、文書内のあらゆる ul 要素の
直下の子供である li 要素全てを表す。
つまり、ol の直下にある li は含まれない。

また、「//a[@target='_blank']/@href」は、
target 属性が _blank である全ての a 要素の、
その href 属性全てを表す。
この例では、属性の集合を表している。

ロケーションパスは、ファイルシステムのパスと、
ワイルドカードなどを組み合わせた感じの文字列であり、
他にも細かな条件を表現することが可能である。

XSLT では、XPath に基づいてルールを記述するため、
文書全体にわたり、高度な変換処理を記述することができる。

XSL は非常に斬新で高度な考え方であるため、
実際に使って色々試して見ないと、
仕組みや利点が分かりにくいことも事実である。

では、明日は実際に XSLT を使ってみよう。



Copyright (c) 1994-2007 Project Loafer. All rights reserved.