mojix.org
いまごろXSLTに目ざめる
最近、仕事でXSLTを使っているのだが、これが実に楽しい。
XSL Transformations
http://ja.wikipedia.org/wiki/XSL_Transformations
＜XSLTはXML形式の文書を変換する。XPathによる選択と検索にもとづき、XML文書全体または文書の一部に対して変換を行い、別のXML文書または表示・印刷用形式（XSL-FO、HTML、RTF、TeX文書など）の文書を生成することができる＞。
（XSLTの実例は英語ページにあります）
かんたんに言えば、XSLTとは「XMLの変換用言語」だ。Web開発では、XSLTは「XMLをHTMLに変換」するのに使われることが多い。
サーバサイドのWeb開発者であれば、データベースから取り出したデータを、HTMLにレンダリングするという処理を書くのは日常茶飯事だろう。この処理を書くとき、小さなCGIみたいなものであれば、ロジックの中で直接HTMLを書き出してしまう場合もあるだろうし、ある程度以上の規模になってくれば、ライブラリやフレームワークの力を借りて、何らかのテンプレート言語を使い、プレゼンテーション（表示）情報をロジックからできるだけ分離するのが普通だ。
私は以前から、このプロセスにおいて、元のデータと最終的にできるHTMLにギャップがありすぎる、と感じていた。いまのWebサイトに求められるHTMLはかなり複雑で、ほとんどが表示情報（純粋なコンテンツではなく、「どう表示するか」の情報）であり、コンテンツ部分はせいぜい１～２割くらいではないかと思う。
私がいまXSLTを使っているプロジェクトでは、最終的にできる複雑なHTMLの前に、ほぼコンテンツのみからなるXMLをいったん生成して、それをXSLTで最終的なHTMLに変換する、という方法を使っている。これは、プロジェクトの事情からそうせざるをえない部分もあるのだが、私はこの方法をかなり気に入った。
いったん「中間形態」としてのXMLを経て、そこからXSLTで最終的なHTMLにする、というこのプロセスの主な利点は、最終的なHTMLに含まれる表示情報の多くを、XSLTの中に「封じ込める」ことができる点だ。つまり、いわゆる「テンプレート」ファイルから、HTMLの詳細な表示情報をほぼ駆逐できるので、システムがそのぶん見通しのいいものになるのだ。
このことが「利点」になるかどうかは、もちろんそのプロジェクトの内容による。たいていの場合は、RDBなどのデータから直接HTMLを生成すれば十分であって、わざわざXMLやXSLTを経由する意味がないという場合がむしろ普通だと思う。しかし、私の今回のプロジェクトのように、いったんXMLを生成することに意味があり、XSLTによる変換のパフォーマンスなども問題にならず、変換ルールをXSLTに集約することで、テンプレート部分を大きく単純化できるような場合は、この方法はメリットがある。
私がXSLTを使うのは今回が初めてではなく、以前もいちど、元のデータがXMLのものをXSLTで変換してHTMLにする、というものがあった。そのときはXSLTを「仕方なく」使っていた感じで、また当時はPythonでXSLTをやろうと思うと、やや骨が折れる状態だった（いくつか検討した上でlibxml2/libxsltを使ったが、これは高速なのはいいがAPIが使いにくい）。しかし今回は、lxmlという強力なライブラリ（libxml2/libxsltをきれいにラップしたもの）もあり、XSLTという「XML変換専門」言語の強みもわかってきて、上記のようなプロセスで「関心の分離（separation of concerns）」が実現できることが気持ちよく、XSLTは「楽しい」と感じられるようになった。
かつてCSSが出てきたとき、テーブルネストのような「視覚効果」のためのコードをHTMLレベルで書く必要がなくなり、HTMLがだいぶすっきりした。しかしそれでもまだ、HTMLは「コンテンツ」にはほど遠く、きれいな表示のためだけのタグや画像が入りまくっている。XSLTは、そのHTMLからもういちど「表示情報」を剥ぎ取るものなのだ。HTMLから表示情報を剥ぎ取ると、「コンテンツの骨組み」であるXMLが残る。ちょうどCSSがHTMLの表示方法を規定しているように、XSLTは、XMLというコンテンツの骨組みに「どういう服（HTML）を着せるか」を決めるものなのだ。
XMLにしても、WebサービスやSOA、セマンティック・ウェブなどにしても、こういう新技術というのはたいてい、まず大きく話題になってから、いったん沈静化して、その後じわじわ進化し、使いやすくなってくる（ガートナーの言う「ハイプ曲線」）。XSLTにしても、われながら「いまごろXSLTか」という感じもしないでもないが、こういう技術がほんとうの真価を発揮しはじめるまでには、時間がかかるものだ。XSLTも、むしろ「これからがおもしろい」技術なのかもしれない。
関連エントリ：
HTMLはもはや「コンテンツ」ではなく、プログラムで自動生成される「画面」だ
http://mojix.org/2008/09/05/html_is_not_content
CMSにおける「コンテンツ」のフォーマット問題
http://mojix.org/2008/07/23/cms_content_format
XSL Transformations
http://ja.wikipedia.org/wiki/XSL_Transformations
＜XSLTはXML形式の文書を変換する。XPathによる選択と検索にもとづき、XML文書全体または文書の一部に対して変換を行い、別のXML文書または表示・印刷用形式（XSL-FO、HTML、RTF、TeX文書など）の文書を生成することができる＞。
（XSLTの実例は英語ページにあります）
かんたんに言えば、XSLTとは「XMLの変換用言語」だ。Web開発では、XSLTは「XMLをHTMLに変換」するのに使われることが多い。
サーバサイドのWeb開発者であれば、データベースから取り出したデータを、HTMLにレンダリングするという処理を書くのは日常茶飯事だろう。この処理を書くとき、小さなCGIみたいなものであれば、ロジックの中で直接HTMLを書き出してしまう場合もあるだろうし、ある程度以上の規模になってくれば、ライブラリやフレームワークの力を借りて、何らかのテンプレート言語を使い、プレゼンテーション（表示）情報をロジックからできるだけ分離するのが普通だ。
私は以前から、このプロセスにおいて、元のデータと最終的にできるHTMLにギャップがありすぎる、と感じていた。いまのWebサイトに求められるHTMLはかなり複雑で、ほとんどが表示情報（純粋なコンテンツではなく、「どう表示するか」の情報）であり、コンテンツ部分はせいぜい１～２割くらいではないかと思う。
私がいまXSLTを使っているプロジェクトでは、最終的にできる複雑なHTMLの前に、ほぼコンテンツのみからなるXMLをいったん生成して、それをXSLTで最終的なHTMLに変換する、という方法を使っている。これは、プロジェクトの事情からそうせざるをえない部分もあるのだが、私はこの方法をかなり気に入った。
いったん「中間形態」としてのXMLを経て、そこからXSLTで最終的なHTMLにする、というこのプロセスの主な利点は、最終的なHTMLに含まれる表示情報の多くを、XSLTの中に「封じ込める」ことができる点だ。つまり、いわゆる「テンプレート」ファイルから、HTMLの詳細な表示情報をほぼ駆逐できるので、システムがそのぶん見通しのいいものになるのだ。
このことが「利点」になるかどうかは、もちろんそのプロジェクトの内容による。たいていの場合は、RDBなどのデータから直接HTMLを生成すれば十分であって、わざわざXMLやXSLTを経由する意味がないという場合がむしろ普通だと思う。しかし、私の今回のプロジェクトのように、いったんXMLを生成することに意味があり、XSLTによる変換のパフォーマンスなども問題にならず、変換ルールをXSLTに集約することで、テンプレート部分を大きく単純化できるような場合は、この方法はメリットがある。
私がXSLTを使うのは今回が初めてではなく、以前もいちど、元のデータがXMLのものをXSLTで変換してHTMLにする、というものがあった。そのときはXSLTを「仕方なく」使っていた感じで、また当時はPythonでXSLTをやろうと思うと、やや骨が折れる状態だった（いくつか検討した上でlibxml2/libxsltを使ったが、これは高速なのはいいがAPIが使いにくい）。しかし今回は、lxmlという強力なライブラリ（libxml2/libxsltをきれいにラップしたもの）もあり、XSLTという「XML変換専門」言語の強みもわかってきて、上記のようなプロセスで「関心の分離（separation of concerns）」が実現できることが気持ちよく、XSLTは「楽しい」と感じられるようになった。
かつてCSSが出てきたとき、テーブルネストのような「視覚効果」のためのコードをHTMLレベルで書く必要がなくなり、HTMLがだいぶすっきりした。しかしそれでもまだ、HTMLは「コンテンツ」にはほど遠く、きれいな表示のためだけのタグや画像が入りまくっている。XSLTは、そのHTMLからもういちど「表示情報」を剥ぎ取るものなのだ。HTMLから表示情報を剥ぎ取ると、「コンテンツの骨組み」であるXMLが残る。ちょうどCSSがHTMLの表示方法を規定しているように、XSLTは、XMLというコンテンツの骨組みに「どういう服（HTML）を着せるか」を決めるものなのだ。
XMLにしても、WebサービスやSOA、セマンティック・ウェブなどにしても、こういう新技術というのはたいてい、まず大きく話題になってから、いったん沈静化して、その後じわじわ進化し、使いやすくなってくる（ガートナーの言う「ハイプ曲線」）。XSLTにしても、われながら「いまごろXSLTか」という感じもしないでもないが、こういう技術がほんとうの真価を発揮しはじめるまでには、時間がかかるものだ。XSLTも、むしろ「これからがおもしろい」技術なのかもしれない。
関連エントリ：
HTMLはもはや「コンテンツ」ではなく、プログラムで自動生成される「画面」だ
http://mojix.org/2008/09/05/html_is_not_content
CMSにおける「コンテンツ」のフォーマット問題
http://mojix.org/2008/07/23/cms_content_format