![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
一太郎Ark1.1で始めるXML/XHTML(後編)
このページでは、一太郎Arkの様々な面に焦点を当てて解説をしております。
本稿で述べる XT, Xerces-J 及び XTサンプルプラグインのインストール作業は一太郎Ark本体の動作に影響を及ぼす可能性があります。作業後の状態での一太郎Ark本体の動作は保証対象外となりますのでご了承下さい。
作業後の状態で一太郎Arkの動作に不具合があった場合、作業前の状態に復旧して不具合が再確認できれば、当社サポートセンターをご利用下さい。
XHTML 1.0 規格の仕様が固まり W3C 勧告(Recommendation)になりました。今後世に出る Web ブラウザでは XHTML 文書を表示できるようになるでしょう。
一太郎Arkの開発中の最新の XHTML 仕様ドラフトは 8月24日版 でした。その後 2 回の改訂を経て今回の勧告となったのですが、その間に名前空間 URI の仕様が変更になりました。
一太郎Arkでは XHTML 1.0 の名前空間 URI を http://www.w3.org/TR/xhtml1/transitional として XHTML 文書を保存していますが、XHTML 1.0 の最終仕様では名前空間 URI が http://www.w3.org/1999/xhtml になっています。
このため、出荷された一太郎Arkは XHTML 1.0 の最終仕様には適合していませんが、近いうちに対応する予定です。
今回は Ark で作成した XHTML 文書をプログラムで処理するという約束でした。XML/XHTML 文書の処理というと業務用の定型文書を扱う話をよくが多いようですが、ここでは非定形な XHTML 文書の中に埋まっている定型の部分を抽出して処理する例として、「読書日記から図書一覧を作成する」をテーマにします。
◆「読書日記」のリンク先はブラウザで見られるように HTML 文書になっています。実際に処理するのは XHTML 形式の文書です。
処理方法には様々な方法がありますが、ここでは IE5 でスタイルシート言語として採用され、汎用技術としても注目されている XSLT を使います。
また、Ark にはプラグインという便利な仕組みがあるので、編集中の文書を XSLT で変換して表示するプラグインも作ります。
プラグインのソースはもう一つの XML 汎用技術である DOM の使用例にもなっています。
なお、今回は Ark で作成した文書を処理対象にするため、XHTML 1.0 の名前空間 URI を http://www.w3.org/TR/xhtml1/transitional としています。
テキストファイルを処理する仕事なり遊びなりをする習慣のある人なら、普通は Perl や Awk などのテキスト処理ツールを使うと思います。これらのツールは基本的にテキストデータを文字の羅列(あるいは行の羅列)とみなして処理します。
私たちが扱おうとしている XML データは、ファイル上ではテキストデータですが、それはタグによって構造化されています。 そのため XML データはノードのツリーとして扱わなくてはなりません。ツリーですから一次元の文字の羅列に比べると立体的な構造を持っているわけです。
◆要素(タグで囲まれた範囲)やコメント、テキストなどを総称してノードと言います。
そのため XML データを従来のテキスト処理ツールでそのまま扱うのは不可能ではないですが困難で非効率的です。可能な限り XML に適した、XML のために作られたツールを使いましょう。ここではそのようなツールとして XSLT プロセッサを紹介します。
◆ Perl をテキスト処理ツールと言いましたが、Perl では拡張モジュールを使って XML をツリーとして扱えるようになります。必要なモジュールはCPANあたりで探してみてください。
XSLT は、ある XML 文書を別の XML 文書に変換するための言語です。この言語で書かれた変換方法の定義のことを XSLT スタイルシートと呼びます。
図2
XML 文書と XSLT スタイルシートを読み込んで、変換結果をファイルなどに吐き出すツールが XSLT プロセッサです。
用途別に XSLT スタイルシートを使い分ける事で、一つの XML 文書を目的に適した形(ホームページ用、印刷用、スライド用、など)に変換して再利用することができます。変換結果の出力形式には、XML 文書以外にも HTML 文書やテキスト文書などが選べます(図2)。
XSLT の言語仕様は XML や XHTML と同様に W3C で標準化され、1999年11月16日に W3C 勧告になりました。正式な仕様書は http://www.w3.org/TR/xsltを参照して下さい。インフォテリア株式会社による邦訳も公開されています。
現在入手できる XSLT 勧告対応 XSLTプロセッサ は複数ありますが、今回は Java で実装されたフリーソフトウェアで、広く利用されている XT を取り上げます。
◆XSLTプロセッサはXTに限らず Java で実装されたフリーウェアが多いのですが、インフォテリア株式会社の iXSLT のようにネイティブコードで実装された商用の XSLT プロセッサもあります。
◆その他の XSLT プロセッサについては山本陽平さんの『XSLT プロセッサの現状(第2版)』が参考になります。
XT は James Clark 氏が開発したオープンソースの XSLT プロセッサで、Java で実装されています。
XTはJames Clark氏のWebサイトhttp://www.jclark.com/xml/xt.htmlからダウンロードできます。常に xt.zipとして最新のバージョンしか公開されていないようですが、今回使用したのは Version 19991105 でした。
作者の James Clark 氏は XSLT 仕様書の編者でもあり、仕様と共に成長してきた実装です。古くから公開されていることもあって、広く使われており、仕様に忠実な動作をするとの定評があります。
XT には XML パーサが含まれていませんので別に Xerces-J を用意しましょう。
Xerces-J は、Apache XML Project で開発されているオープンソースの XML パーサの Java 版です。Xerces には他に C++ 版や、C++ 版を Perl から利用する Perl 版もあります。
Xerces-J は Apache XML Project の Web サイト http://xml.apache.org/ からダウンロードできます。今回はバージョン 1.0.3 (Xerces-J-bin.1.0.3.zip)を使用します。
Xerces-J は XML パーサーの定番と言われるほど広く使われている IBM の XML4J (XML Parser for Java)を元に作られたものです。信頼できる実装と言ってよいでしょう。
◆ バージョン 1.0.2 またはそれ以前の Xerces-J では、XT でうまく動作しない場合があります。
◆ 一太郎 Ark は XHTML を読み込むために内蔵のパーサーを持っていますが、互換性の点で Xerces-J がより優れているのでこちらを使います。
XT と Xerces-J をダウンロードできたら Java でそれらを使えるようにします。単に XT を起動するだけでなく、後で作るプラグインから XT のライブラリを使えるようにします。
一番簡単なのは JRE の機能拡張ディレクトリにそれらのライブラリをコピーすることです。
ダウンロードした xt.zip を展開し xt.jar があるのを確認。
ダウンロードした Xerces-J-bin.1.0.3.zip を展開し xerces.jar があるのを確認。
{JREのインストール先}/jre/lib/ext のディレクトリに xt.jar と xerces.jar をコピー。
・ 一太郎Ark付属の JRE を使う場合は {JREのインストール先} は、{一太郎Arkのインストール先}/justsystem です。
◆ XML4J 2.0.15 を使う場合は xerces.jar ではなく xml4j.jar をコピーします。
UNIX 系の OS などで、システム管理者が JRE をインストールしている場合、一般ユーザーには jre/lib/ext に書き込み権限がない場合は、任意のディレク トリに jar ファイルをコピーして、そのディレクトリを java の起動時オプションで機能拡張ディレクトリとして追加指定することができます。
例えば ~/jar/ を機能拡張ディレクトリにしたい場合は、以下のようにオプションを追加して java を起動します。
java -Djava.ext.dirs="~/jar" ...
以上のようにして XT と Xerces-J のインストールができたら、XT がちゃんと動くか動作確認をしておきましょう。XT の起動は DOS プロンプトなどのコマンドシェルで以下のようにします。
$ java -Dcom.jclark.xsl.sax.parser=org.apache.xerces.parsers.SAXParser com.jclark.xsl.sax.Driver
以下のように出力されればインストール成功です。
usage: java com.jclark.xsl.sax.Driver source stylesheet [result] [param=value]...
◆ XML4J 2.0.15 を使う場合は、org.apache.xerces.parsers.SAXParser の代わりに com.ibm.xml.parsers.SAXParser を指定して下さい。
XT を起動するたびにこんな長いコマンドを入力するのは大変なので以下のようなバッチファイル(Windows系の場合)を作っておきましょう。
xt.bat
001:@set PARSER=org.apache.xerces.parsers.SAXParser
002:@set MAIN=com.jclark.xsl.sax.Driver
003:@java -Dcom.jclark.xsl.sax.parser=%PARSER% %MAIN% %1 %2 %3
UNIX系の場合は以下のようなシェルスクリプトを作っておきます。
xt.sh
001:#!/bin/sh
002:PARSER=org.apache.xerces.parsers.SAXParser
003:MAIN=com.jclark.xsl.sax.Driver
004:java -Dcom.jclark.xsl.sax.parser=$PARSER $MAIN $*
◆ xt.sh に実行属性を付ける(chmod +x xt.sh)のをお忘れなく。
それでは実際に XT を使ってみましょう。処理対象としては前編で作ったタグセットを使った読書日記(diary.xhtml)です。
まずは簡単なタグ検索をやってみます。ここでは読書日記の中から「book:タイトル」タグで囲まれた部分を抜き出しましょう。
適当なエディタ(あるいは一太郎 Ark)で以下のようなスタイルシート書いて search.xsl のファイル名で保存します。ここでは便宜的にスタイルシート及び出力の文字符号化方式(いわゆる文字コード)は Shift_JIS とします。
◆環境によって他の文字符号化方式を指定してください。スタイルシートの文字符号化方式は 1行目、出力の文字符号化方式は 6 行目の "Shift_JIS" の部分を適当な値("EUC-JP" など)に置き換えます
search.xsl
001:<?xml version="1.0" encoding="Shift_JIS"?>
002:<xsl:stylesheet version="1.0"
003: xmlns:book="http://www.justsystem.co.jp/arksample/book/0.1"
004: xmlns="http://www.w3.org/TR/xhtml1/transitional"
005: xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
006:<xsl:output method="html" encoding="Shift_JIS"/>
007:<xsl:template match="/">
008:<html>
009:<head><title>検索結果</title></head>
010:<body>
011:<xsl:apply-templates select=".//book:タイトル"/>
012:</body>
013:</html>
014:</xsl:template>
015:<xsl:template match="book:タイトル">
016:<h3><xsl:value-of select="."/></h3>
017:</xsl:template>
018:</xsl:stylesheet>
先に用意したバッチ(もしくはシェルスクリプト)を使って以下のようにして変換を実行します。
xt.bat diary.xhtml search.xsl result.html
結果(result.html)をブラウザ(あるいは一太郎 Ark)で見てみましょう。日記の中の図書のタイトルが全てリストアップされているのがわかります。
◆ バージョン 1.0.2 またはそれ以前の Xerces-J では [Fatal Error] で XT が強制終了したり、異常に長い時間処理が停止したりすることがあります。バージョン 1.0.3 以上の Xerces-J をご利用下さい。
このスタイルシートのどこに何が書いてあるかを簡単に見ておきましょう。
1行目は XML 宣言です。XSLT スタイルシートも一種の XML文書です。
2行目から18行目までを含む xsl:stylesheet 要素は、 XSLT スタイルシートのトップレベル要素として使われます。XSLT の処理内容はすべてこの要素の内側に書かれます。
3行目から5行目まではスタイルシートの中で名前空間を使うための名前空間宣言です。3行目が前回作った図書データ用タグセットの名前空間を、4行目が XHTML 1.0 の名前空間を、5行目が XSLT の名前空間を宣言しています。
6行目は xsl:output 要素で出力形式を指定しています。ここでは HTML 形式の出力を指定しています。encoding 属性では出力の文字符号化方式に Shift_JIS を指定しています。
◆ XHTML 形式の出力が欲しい場合は "xml" と指定します。但し XT は "xml" を指定すると文字符号化方式の指定を無視して UTF-8 で出力してしまって不便なので、ここでは HTML 形式にしています。なお、入出力の文字符号化方式に関わらず XT の内部処理は UNICODE で行われます。UNICODE の変換表は Java VM 内蔵の変換表が使われます。
本質的な処理内容は7行目から14行目までと、15行目から17行目までの二つの xsl:template 要素の中に書いてあります。
xsl:template 要素は大雑把に言うと「こんなタグが来たら、こういう出力をする」というルールを書くところです。これをテンプレートルールといいます。「こんなタグ」の部分は xsl:template 要素の match 属性に書いてあります。「こういう出力」の部分は xsl:template の要素内容が相当します。
7行目からのテンプレートルールには出力文書全体の雛形が書いてあります。xsl:template 要素の match 属性に "/" が指定されていますが、これは「ルートノードが来たら」という意味です。ルートノードというのは、文書のルート要素(XHTML なら html 要素)の親ノードにあたるノード、つまり文書自身のことです。
15行目からのテンプレートルールは book:タイトル 要素が来たときにその内容を h3 タグで囲んで出力するというものです。
続いて XSLT プロセッサがこのスタイルシートを使ってどのように入力文書を処理するのか、簡単に流れを追ってみましょう。
XSLT プロセッサは入力文書を頭から順番に読んでいきます。Perl や Awk ではこういう場合、入力から一行ずつ読みとりながら行単位で処理していくわけですが、XSLT プロセッサではノードを一個ずつ読みとりながらノード単位で処理を実行します。
具体的な処理はルートノードの処理から始まります。XSLT プロセッサは注目しているノードに対応するテンプレートルールを探します。ここでは二つあるテンプレートのうち最初のテンプレート(7行目)が該当します。
テンプレートルールは文字通りテンプレート(雛形)の役割を果たします。テンプレートには後から記入する空欄がつきものですが、その空欄に相当するのが11行目の xsl:apply-templates 要素です。ここには現在注目しているノード(カレントノードといいます)の子孫ノードの処理結果が埋め込まれます。
xsl:apply-templates の select 属性は、XSLT プロセッサが今後処理する子孫ノードを絞り込むための条件を指定するものです。11行目ではここに ".//book:タイトル" が指定されています。これは「カレントノード以下にある全ての book:タイトル 要素」を意味します。
ルートノードを処理中の XSLT プロセッサは、この xsl:apply-templates 要素を見つけると、ルートノードの子孫ノードを次々に辿っていき、上記の絞り込み条件に合致した子孫を探します。
そして XSLT プロセッサは book:タイトル 要素を見つけるたびに、対応するテンプレートとして二番目のテンプレートルール(15行目)を使った処理を実行していきます。
16行目の xsl:value-of 要素はそこに入力文書の内容の一部を引用するものです。どこを引用するかは select 属性で指定します。ここでは "." が指定されていますが、これは「カレントノードの内容」を意味します。
なお、カレントノードに子孫がある場合の「カレントノードの内容」はカレントノード以下のツリーからタグを取り除いてテキストだけを残したものです。このため、結果(result.html)には 直接処理対象にされていない book:サブタイトル 要素の内容が出力されています。
以上の説明には話を簡単にするために不正確になっている部分がいくつかあります。また、XSLT にはもっと複雑で高度な機能がたくさんあります。
XSLT についての正確な情報は、W3C の仕様書(あるいはその邦訳)を参照して下さい。とはいえ、W3Cの仕様書はバリバリの技術文書ですので、最初は取っつきにくいものです。XSLT については良いチュートリアルやリファレンスが公開されていますので、是非そちらを併せてご覧ください。日本語でかかれたものとしては Shu さんのXML Lessonがお勧めです。
◆それでもある程度 XSLT に慣れてきたら、あとはなるべく仕様書を読むようにしたほうが良いと思います。
一太郎Arkの特徴の一つは、その内部アーキテクチャに DOM が使用されている点です。DOM は Java などのプログラミング言語から XML 文書構造にアクセスするための標準インターフェースです。一太郎Arkのプラグインからは、この DOM インターフェースを通じて編集中の文書にアクセスすることができます。
ここではこの特徴を生かして、XT と一太郎Arkを合体させるプラグインを作りましょう。
プラグインの仕様
図3
今回作るプラグインでは以下のような操作で編集中の文書を任意の XSLT スタイルシートで変換した結果を表示できるようにしましょう。
処理したい文書を開いたウィンドウでツールメニューを選択。
ツールメニューから XT transform を選択。
サブメニューに設定済のスタイルシートの一覧が出る。
サブメニュー項目の中から使用するスタイルシートを選択。
新しいウィンドウが作成され、スタイルシートで変換済みの文書が表示される。
図3はメニューの例です。このプラグインは実用向けではなく説明用のサンプルですので、ソースコードをシンプルにするためにユーザーインターフェースは極力簡素化します。
スタイルシートファイルの設定はプラグイン設定で絶対パスを手で書くことにします。設定できるスタイルシートの数も 3 つに固定してしまいます(図4)。
図4
◆プラグイン設定の操作方法は「プラグイン作成講座第3回」の プラグインサンプル３の概要 を参照して下さい。
なお、処理はすべて一太郎Arkを実行している Java VM 内で完結するようにします。かつ、全ての処理はオンメモリで実行します。つまり、テンポラリファイルを作ることも外部コマンドが起動されることもありません。
実行例
図5
先に、できあがったプラグインを使った実行例をお見せします(図5)。入力は「XSLTで遊ぼう(実践編)」で使った diary.xhtml、スタイルシートは少し派手な例として、図書一覧表を作成するもの(table.xsl)を使いました。
とにかく使ってみたい! という方は...
コンパイル済みのプラグインがプラグイン研究室の ダウンロードセンター からダウンロードできます。
XT と Xerces-J をインストールした後、プラグインの JAR ファイルをプラグインディレクトリにコピーして下さい。
プラグインの構造
プラグインの構造は大まかには図6のようになります。
図6
ソースコードは XTSample.java です。リソースなど他の必要なファイルを全部まとめたもの(XTSamplePlugin_src.zip)も用意しました。
300 行弱の分量がありますが、コードの大半はプラグインとして実装するためのオマジナイです。
ソースの随所にコメントを書いておきましたので、詳細はソースコードを見て下さい。
以下ではこのプラグインのキモとなる XT を使った文書変換処理の方法と、XT とのデータのやりとりの仕方を説明します。
変換処理自体は非常にシンプルです。XT には XSLTransformEngine という、入出力を DOM で指定して変換する仕組みがあるので、それを利用します。入出力とスタイルシートの DOM が揃っていれば、変換処理はたったの2行で記述できます。
XTSample.java (抜粋その 1)
259:
260:
XSLTransformEngine engine = new XSLTransformEngine(); engine.createTransform(sheet).transform(source, result);
問題は入出力をどうやって XT に繋ぐかです。
入力用の DOM ツリーは以下のようにして取得できます。
XTSample.java (抜粋その 2)
197:
ArkActionEvent.getTargetDocumentModel(ev).getDocument();
ev は、メニュー選択時に発生したアクションイベントです。このコードでは、アクションイベントからイベントの発生元の文書(メニュー選択時にフォーカスがあった文書)を割り出し、そこから生の DOM ツリー(Document インスタンス)を取得しています。
出力用の DOM ツリーは以下のようにして作成します。
XTSample.java (抜粋その 3)
246:
Document result = new ArkDocument();
ArkDocument は一太郎Ark文書を表現するクラスで DOM API の Document インターフェースを実装しています。ArkDocument は通常の DOM の機能に加えて、XML エディタとしての編集操作を支援するための機能拡張(undo, mutation event など)がなされています。一太郎Arkで表示・編集するためには、文書の DOM ツリーはこの ArkDocument のインスタンスでなくてはいけません。
処理結果の DOM ツリーはそのままでは正しく表示・編集されないことがあります。例えば、一太郎 Ark は内部では HTML の属性で指定された書式情報(bgcolor="red" など)を極力 CSS スタイルシートに置き換えたものを扱うように設計されています。
そのため、処理結果の DOM ツリーには以下のような処理を施してから表示します。
XTSample.java (抜粋その 4)
272:
XMLDOMTreeNormalizer.normalize(result);
ここまでの内容で、一太郎Arkには以下のような良さがあることを説明しました。
一太郎Arkのユーザーインターフェースでは要素を自由にネストさせることができません。一太郎Ark で作成するタグセットでは、要素間の包含関係はブロック要素(段落タイプ)がインライン要素(文字タイプ)を包含できるだけで、ブロック要素同士やインライン要素同士をネストさせることができません。
◆これはデータ構造に関わる包含関係が、ブロック・インラインというレイアウト上の属性に影響される、という良くない状況です。
このため、例えば前編で作った図書データのタグセットを使った場合、図書のタイトルと著者と出版社の情報が、同じ一つの図書についての情報であることを表現するのは困難です。
「XT プラグインを作ろう」の実行例で使った XSLT スタイルシート table.xsl の場合は、それらの情報が連続して一つずつ順番に並んだものを一つの図書の情報として認識しています。DTD で言うとだいたい以下のような制約を想定しています。
!ELEMENT body (#PCDATA | p | div | (book:タイトル, book:著者など, book: 出版社など)
)*>
要素の順番が違ったり、省略があったり、余計なものが間に挟まったりすると、どこからどこまでが一つの図書の情報なのかわからなくなって、出力が壊れてしまいます。
例えばdiary.xhtmlで、最初の「一太郎Arkでみるみる痩せる!」の図書情報から出版社が書いてある段落を削除してみてください。 table.xslで変換すると、「一太郎 Ark でみるみる痩せる!」の出版社の欄に一つ下の「一太郎Ark解体新書」の出版社名が誤って引用されています。
このような問題は、
文書作成者が厳しい DTD に従った正しい文書を書く。
スタイルシート作成者が、様々な条件を考慮した複雑なスタイルシートを書く。
などの方法で対処できなくもありませんが、どちらもあまり嬉しくない方法です。
しかし、個々の情報用の要素を包含する要素を導入すれば、もっとゆるい制約でもそこそこ正しく動くスタイルシートが書けます。
!ELEMENT body (#PCDATA | p | div | book:図書情報)* >
!ELEMENT book:図書情報 ANY>
「book:図書情報」タグで囲まれた部分を一つの図書の情報として扱い、個々の図書に関する情報はその子孫として書けばよいことにします。こうしておけば、少なくとも図書の情報と、そうでない情報、あるいは連続して並んだ図書の情報を確実に切り出せます。図書情報用のタグが増えてもスタイルシートがおかしな振る舞いをする可能性はぐっと少なくなります。
具体的には「book:図書情報」を導入した文書の例 diary2.xhtmlと、これを table.xsl と同様に変換する table2.xsl をご覧下さい。
しかし、このようなネストしたタグの設定をするためのユーザーインターフェースが今の一太郎 Ark にはありません。この問題はコピー&ペーストの裏技を使ったり、適切なプラグインを作成することである程度回避できるでしょう。しかし、挿入後の要素に対する要素分割や要素の融合、カーソル移動などにおいて不都合が生じる場合があります。
上で挙げた例のように文書構造を工夫してツールで処理しやすくできる場合もありますが、一般には文書構造に何らかの制約条件を仮定しないとツールは機能しません。XML エディタたるものは、文書の構造制約に基づいて編集操作にも制約を加え、常に制約を満たした正しい文書だけを作成できるようになっているのが理想です。
しかし一太郎Arkはユーザーが定義したタグセットに対して構造制約を定義することも編集操作に制約を加えることも出来ません。
この問題は汎用のパーサーモジュールを流用して文書全体を DTD に基づいて検証(validation)するようなプラグインを作成することである程度解決できると考えられます。しかし、この方法では検証でエラーが出た場合は、後から人間が手作業で修正しなくてはなりません。
内部処理の都合上、ファイル入出力時に文書構造に修正が加えられて内部表現が変わってしまう場合があります。そのため、ファイルに対して正しく動作した XSLT スタイルシートが、XT プラグインでは正しく動作しない(あるいはその逆)ことがあります。
問題になると思われる振る舞いには以下のようなものがあります。
PRE 要素の内容に含まれる改行がファイル読み込み時に br 要素に変換される (ファイル保存時には改行に戻される。)
class 属性あるいは id 属性を持たない span 要素のネストがファイル読み込み時に解除される。また他のインラインタグと span 要素のネストの順番が入れ替えられ、span がツリーの一番末端にくるように構造が変換される(ファイル保存時には戻されない。)
HTML のスタイル系属性(color, bgcolor, width, height 等)の多くが CSS スタイルシートに変換される(ファイル保存時には戻されない。)
ファイル保存時に連続したスペースが (または ) とスペースに置換される(ファイル読み込み時には逆変換する。)
ファイル保存時にブロック要素の開始タグの後ろと終了タグの手前に改行が挿入される(ファイル読み込み時には除去される。)
◆いずれも将来改善するべき点だと思います。
前後編に渡って長々と XML/XHTML についてお話ししてきましたが、皆様のお役にはたちましたでしょうか?
XML は電子商取引のようなビジネス分野での話題が多いのですが、この連載では敢えて個人的で日常的な応用例をとりあげてみました。というのも、「XML でビジネスを効率化」という話になると技術的なハードルよりも高いハードルが沢山あって、もっと大変な話になってまうからです。
前編でも少し触れましたが、XML は開かれたコミュニケーションのための技術です。そのような技術には、ビジネスへの参入障壁を低くし、競争原理を強める働きがあります。XML のそのような働きが、新しいビジネスの誕生を促進し市場を活性化させる、といった良い効果を生むことが期待されているのです。
しかし、これは同時に、閉ざされたコミュニケーションから生まれる情報格差に依存したビジネスが廃れてしまうことを意味します。当然そこでは既得権益を巡る政治的闘争が繰り広げられ、、、という話になりかねないわけですが、この連載はあくまで「開発の現場から」であって決して「ビジネスの修羅場から」ではないのでこのくらいでお茶を濁しておきましょう。
だいたい筆者も含めた現場の開発者は、そこまで政治的な意図を持って一太郎 Ark を作ったわけではありません。私たち開発者の気持ちとしては、コンピュータでいろんなことをしたいのに、いつのまにかできていた悲しい壁があるせいで本来出来るはずのことが出来なくなっている状況をなんとかしたかっただけなのです。
しかし「出来るはずのことが出来ないのをなんとかしたい」という思いは、XML コミュニティの人たちも同様だと思います。XML コミュニティには「XML は空気のような存在になる」という言葉があります。これは単なる未来予測ではなく、XML がもたらすものは、人が空気を吸うのと同じくらいあたりまえに手にするべきものである、と宣言しているのです。
一太郎 Ark はまだまだ発展途上のソフトウェアで、決して「空気を吸うのと同じくらい」簡単に XML を扱えるわけではありません。
しかしその目指すところ、志だけは高いのがウリですので、今後の発展に是非ご期待下さい。
zu_text.gif 26件
[詳細]
zu_xslt.gif 31件
[詳細]
zu_xt.gif 23件
[詳細]
XTSample-result.jpg 30件
[詳細]
XTSample-options.jpg 27件
[詳細]
XTSample-menu.jpg 33件
[詳細]
