![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
developerWorks のXMLゾーンによく目を通している読者であれば、JAXPに関する記事がすでに出ているので、少し戸惑いを感じたかもしれません。1か月ほど前の「JAXPのすべて」という記事です。その記事では、JAXPについて詳しく説明しました。JAXPの機能はもちろん、特にJavaプログラムの中でXMLデータを扱う方法が取り上げられています。その記事の対象となっているのは、JAXPの1.0リリースです。
では、JAXPを再び取り上げるのはなぜでしょうか。筆者は、JAXP 1.1の専門家グループの一員であり、1.1の仕様が完成に近づいています。ほとんどの "小数点リリース" (たとえば、1.0から1.1、2.2から2.3などのリリース) では、既存のAPIに小さな (少なくとも簡単な) 変更が加えられるだけですが、JAXPの1.1リリースは、1.0から大幅に変更されています。実際に本稿でも、既存のクラスと機能の新しいメソッドを取り上げているのは全体の3分の1にすぎず、残りの3分の2は、JAXP 1.1の新しいクラスと機能の説明に当てています。要するに、JAXP 1.1にはたくさんの新機能 (便利な機能) が追加される予定なので、仕様の完成前にそのさわりの部分を説明したかったというわけです。
JAXPのことを初めて知ったあなた。JAXPを今使っているあなた。JAXPがもう少し安定するのを待っているあなた。本稿は、そんなあなたにぴったりの記事です。今回は、1.0からの変更点を取り上げ、TRaX (Transformations for XML) のためにかなりのスペースを割きます。TRaXは、今回からJAXPに組み込まれたAPIであり、XSL変換のためのベンダー非依存の手段を提供しています。XMLの構文解析については、すでにJAXPにベンダー非依存の手段がありましたが、このTRaXは、変換の分野に踏み込んでいるわけです。まずは、コーヒーでも飲みながらJAXPの最初の記事に目を通してから、今回のJAXP 1.1の学習に入るのはいかがでしょうか。
JAXP APIに対する変更点は、構文解析を中心としていました。JAXPの "P" は "Parsing (構文解析)" であることを考えれば、それも当然のことです。しかし、JAXP 1.1の最も重要な変更点は、XML変換にかかわっています。既存のJAXP機能については、ごく小さな変更点しかありません。一番大きな変更点は、SAX 2.0 (2000年5月完成) とDOM Level 2 (完成間近) のサポートが追加されたことです。JAXPの旧バージョンでは、SAX 1.0とDOM Level 1をサポートしているにすぎませんでした。SAX規格とDOM規格が改訂されているのに、JAXP 1.0では改訂後の規格をサポートしていないというのが、JAXP 1.0に対する最も大きな批判の1つだったわけです。
SAXとDOMの最新バージョンに合わせてJAXPを改訂する以外にも、APIに小さな変更がいくつか加えられています (前回の記事でも取り上げました)。そのほとんどは、JAXP専門家グループのさまざまな企業や個人からのフィードバックに基づいた重要な変更です。また、すべての変更は、JAXPの2つのファクトリー (SAXParserFactory とDocumentBuilderFactory) から戻されるパーサーの設定にかかわっています。これらの変更点や、SAXとDOMの規格サポートの改訂について、これから見ていきましょう。
JAXP 1.0から1.1への改訂で最も期待が大きかったのは、おなじみのSAX規格とDOM規格のサポートの改訂です。SAX (Simple API for XML) は、バージョン2.0が2000年5月にリリースされており、中でもXML名前空間のサポートが大幅に向上しました。この名前空間のサポートによって、XML Schema、XLink、XPointerなどの他のさまざまなXMLボキャブラリーを使用できるようになりました。これらのボキャブラリーは、SAX 1.0でも使用できましたが、開発者にしてみれば、要素のローカル名 (または修飾名) を名前空間から切り離したり、文書全体でそれぞれの名前空間を把握しておいたりするのに手間がかかったわけです。SAX 2.0では、開発者にこうした情報が提供されるようになったので、この面でのプログラミング作業が大幅に単純化されました。同じことは、DOM Level 2にも言えます。名前空間のサポートのほかに、DOMのクラスの多彩なメソッドが用意されています。DOM Level 2はまだ完成していませんが、JAXP 1.1では、現時点での仕様をサポートしています。DOM Level 2の最終段階で小さな変更があれば、もちろんJAXPにもそれらの変更が取り入れられることになっています。
たいへん喜ばしいのは、JAXPを使用する開発者にとって、こうした変更点が基本的に "見えない" ということです。要するに、ユーザーが細かな操作をしなくても、規格の改訂事項が "自動的に" 導入されるのです。SAXParserFactory クラスにSAX 2.0準拠のパーサーを指定し、DocumentBuilderFactory クラスにDOM Level 2準拠のパーサーを指定するだけで、改訂事項が取り込まれるというわけです。
規格の改訂事項に関連して、いくつかの重要な変更点があります。SAX 1.0では、ベンダーやXMLパーサー・プロジェクトが実装するパーサー・インターフェースは、org.xml.sax.Parser でした。それに対応して、JAXPのSAXParser クラスには、この基礎的な実装クラスを取得するためのメソッドとして、getParser() メソッドが用意されていました。そのメソッドのコードは、次のようになります。
リスト1. getParser() メソッド
public interface SAXParser {
public org.xml.sax.Parser getParser();
// Other methods
} |
ところが、SAX 1.0から2.0への改訂で、Parser インターフェースが廃止され、その代わりに、org.xml.sax.XMLReader という新しいインターフェースが導入されました。そのため、getParser() メソッドは、SAX 2.0のXMLReader クラスのインスタンスを取得するためのメソッドとしては使い物にならなくなったわけです。そのSAX 2.0のXMLReader クラスをサポートするために、JAXPのSAXParser クラスに新しいメソッドが追加されました。名前はもう予想できるでしょう。getXMLReader() です。こんな感じになります。
リスト2. getXMLReader() メソッド
public interface SAXParser {
public org.xml.sax.XMLReader getXMLReader();
public org.xml.sax.Parser getParser();
// Other methods
}
|
同じように、SAX 1.0でコールバックを実装するために使われていたクラスは、org.xml.sax.HandlerBase であり、そのクラスのインスタンスが、JAXP 1.0のすべてのparse() メソッドに対して提供されていました。ところが、SAX 2.0ではさらに廃止や変更があって、このクラスもSAX 2.0では使われなくなりました。その代わりに導入されたのが、org.xml.sax.ext.DefaultHandler という新しいクラスです。この変更に対応するために、SAXParser クラスのすべてのparse() メソッドには、SAX 2.0のDefaultHandler クラスのインスタンスを取り込むためのバージョンが追加されています。この違いを示すために、両方のメソッドをリスト3にまとめておきます。
リスト3. parse() メソッドの2つのバージョン
// The SAX 1.0 parse methods
public void parse(File file, HandlerBase handlerBase);
public void parse(InputSource inputSource, HandlerBase handlerBase);
public void parse(InputStream inputStream, HandlerBase handlerBase);
public void parse(InputStream inputStream, HandlerBase handlerBase,
String systemID);
public void parse(String uri, HandlerBase handlerBase);
// The SAX 2.0 parse methods
public void parse(File file, DefaultHandler defaultHandler);
public void parse(InputSource inputSource, DefaultHandler defaultHandler);
public void parse(InputStream inputStream, DefaultHandler defaultHandler);
public void parse(InputStream inputStream, DefaultHandler defaultHandler,
String systemID);
public void parse(String uri, DefaultHandler defaultHandler);
// Other methods
}
|
構文解析用のメソッドをこのように並べると、かなりややこしく思えるかもしれませんが、SAXの両方の バージョンを同時に使用しない限り、それほど込み入った話ではありません。SAX 1.0の場合は、Parser インターフェースとHandlerBase クラスを使用するわけなので、どのメソッドを使ったらよいかは明らかです。同じように、SAX 2.0の場合は、DefaultHandler インスタンスを受け入れて、XMLReader を戻すメソッドを使えばよいわけです。したがって、この部分をリファレンスとして使えば、そんなに心配するには及びません。ところで、このAPIのSAX部分には、ほかにも変更点があります。
既存のJAXP機能に対する変更点をすべて挙げるとすれば、JAXP SAXユーザーが利用できるいくつかの新しいメソッドについて触れないわけにはいきません。まず、SAXParserFactory クラスには、setFeature() という新しいメソッドがあります。JAXP 1.0ですでにご存じかもしれませんが、SAXParserFactory クラスでは、そのファクトリーから戻されたSAXParser インスタンスの設定ができます。前から提供されていたメソッド (setValidating() とsetNamespaceAware()) とこの新しいメソッドでは、新しいパーサー・インスタンスのためにSAX 2.0の機能を要求できます。SAX 2.0には、ベンダーが自社パーサー独自の機能を作成するための機能 (feature) が用意されており、ユーザーは、SAX経由でそれらの機能を利用できるようになっています。たとえば、ユーザーはhttp://apache.org/xml/features/validation/schema という機能を要求できます。つまり、XML Schemaの妥当性検査のオン / オフを切り替えるための機能です。このような要求が、今回からSAXParserFactory クラスで直接実行できるようになりました。そのためのコードがリスト4です。
リスト4. setFeature() メソッドの使用法
SAXParserFactory myFactory = SAXParserFactory.newInstance();
// Turn on XML Schema validation
myFactory.setFeature("http://apache.org/xml/features/validation/schema", true);
// Now get an instance of the parser with schema validation enabled
SAXParser parser = myFactory.newSAXParser();
|
もちろん、setFeature() メソッドとコンビを組むgetFeature() メソッドも用意されています。つまり、特定の機能を探し出すためのメソッドです。このメソッドからは、シンプルなブール値が戻されます。
SAXでは、機能を設定する (true 値またはfalse 値) だけでなく、プロパティー も設定できます。SAXのプロパティーとは、実際のJavaオブジェクトに関連付けられている名前です。たとえば、SAXパーサーのインスタンスの使用時に、http://xml.org/sax/properties/lexical-handler というプロパティーを設定し、そのプロパティーをSAXのLexicalHandler インターフェースの実装に割り当てるとしましょう。その場合、パーサーは、字句処理のためにその実装を使用することになります。この字句処理用のプロパティーもそうですが、プロパティーはいずれも、機能のようにファクトリー固有ではなく、パーサー固有なので、setProperty() メソッドは、JAXPのSAXParserFactory クラスではなく、SAXParser クラスに用意されています。ただし、機能の場合と同じように、このSAXParser クラスにも、コンビを組むgetProperty() メソッドが用意されており、特定のプロパティーに関連付けられている値を戻すことができるようになっています。
JAXPのDOM部分にも、いくつかの新しいメソッドが用意されています。既存のJAXPクラスに新しいメソッドが追加されているのは、DOM Level 2のオプションをサポートするためであり、さらには、昨年から一般化してきたある種の設定状況に対応するためでもあります。ここでは、それらのオプションと対応メソッドをすべて取り上げるわけではありません。その多くはかなり特殊な (きわめて特殊な状況でしか使用しない) ものであり、実際にアプリケーションの中で必要になることもあまりないからです。そうした点については、最新のJAXP仕様をオンラインでチェックしてみてください (参考文献のセクションを参照)。ここまでの部分で、規格の改訂事項、SAXの変更点、DOMの追加メソッドを取り上げてきました。ここからは、JAXP 1.1の最も重要な変更点について見ていきましょう。つまり、TRaX APIです。
これまで取り上げてきたのは、JAXPのXML構文解析にかかわる変更点でした。ここからは、JAXP 1.1のXML変換の話に移ります。おそらく、SunのAPIの最新バージョンにかかわる最も画期的な進展は、JAXP 1.1でベンダー非依存のXML文書変換が可能になることでしょう。XML変換やXSLT (XML Transformations) について詳しくない読者は、dW のチュートリアルをチェックしてみてください (参考文献を参照)。このベンダー非依存の機能は、単なる構文解析用のAPIだったJAXPの幅をさらに広げるものであると同時に、必要性がきわめて高い機能でもあります。現在の各種XSLプロセッサーは、ユーザーや開発者の対話方式として、さまざまなメソッドや手段を採用しているからです。実際のところ、XSLプロセッサーは、XMLパーサーの場合よりも、ベンダー間の差異がはるかに大きくなっているのが現状です。
JAXP専門家グループでは元々、シンプルなTransform クラスにいくつかのメソッドを用意して、スタイルシートの指定による文書変換を実現する予定でした。こうした当初の試みはかなり怪しくなってきましたが、JAXP専門家グループとして、さらに作業を進めていることをお知らせできるのはたいへんうれしいことです。XSLプロセッサーの2人の大家、Scott Boag氏とMichael Kay氏 (それぞれApache XalanとSAXONで活躍) が、いろいろな人との共同作業でTRaXを開発しました。TRaXには、多種多様なオプションや機能が用意されており、ほとんどすべてのXML変換が完全にサポートされています。それがすべてJAXPの枠組の中で実現するわけです。
JAXPの構文解析部分と同じように、XML変換を実行するには、3つの基本的なステップが必要です。
-
Transformerファクトリーの取得 -
Transformerの取得 - 操作 (変換) の実行
JAXPの変換部分の場合、処理するファクトリーは、javax.xml.transform.TransformerFactory になります。このクラスは、JAXPの前回の記事でも本稿の前半でも取り上げたSAXParserFactory クラスやDocumentBuilderFactory クラスによく似ています。もちろん、処理対象のファクトリー・インスタンスを取得するだけなら、とても簡単です。
リスト5. TransformerFactoryインスタンスの取得
TransformerFactory factory = TransformerFactory.newInstance(); |
ファクトリーを取得したら、そのファクトリーについていろいろなオプションを設定できます。設定したオプションは、そのファクトリーから作成されるTransformer (後で説明します) のすべてのインスタンスに影響します。(ちなみに、TransformerFactory からは、javax.xml.transform.Templates のインスタンスを取得することもできます。テンプレートとは、JAXPの上級概念であり、ここで取り上げる余裕はありません。)
まず設定するオプションは、属性 です。XMLの属性ではなく、XMLパーサーの説明で取り上げたプロパティーとよく似ています。属性を設定すると、基礎的なXSLプロセッサーにオプションが渡されることになります。基礎的なXSLプロセッサーとしては、Apache Xalan、SAXON、OracleのXSLプロセッサーなどがあります。これらのプロセッサーは、ベンダー依存度が高くなっています。JAXPの構文解析部分と同じように、setAttribute() メソッドとそのコンビであるgetAttribute() メソッドが用意されています。setProperty() と同じく、setAttribute() は、属性名とObject 値を取り込みます。さらに、getProperty() と同じく、getAttribute() は、属性名を取り込んで、関連するObject 値を戻します。
次に設定するオプションは、ErrorListener です。javax.xml.transform.ErrorListener インターフェースで定義されているErrorListener は、変換時のエラーを検出し、プログラムに基づいて処理します。SAXに詳しい読者であれば、このインターフェースは、org.xml.sax.ErrorHandler インターフェースとそっくりだということがわかるはずです。
リスト6. ErrorListenerインターフェース
package javax.xml.transform;
public interface ErrorListener {
public void warning(TransformerException exception)
throws TransformerException;
public void error(TransformerException exception)
throws TransformerException;
public void fatalError(TransformerException exception)
throws TransformerException;
}
|
このインターフェースの実装を作成し、3つのコールバック・メソッドを記述し、処理対象のTransformerFactory インスタンスでsetErrorListener() メソッドを使用すれば、どんなエラーにも対応できます。
最後に、ファクトリーから生成されるインスタンスのURI (Uniform Resource Indicator: 基本的にはURL) リゾルバーを設定したり取得したりするメソッドが1つ用意されています。javax.xml.transform.URIResolver で定義されているインターフェースも、SAXの対応インターフェースであるorg.xml.sax.EntityResolver と同じような動作をします。このインターフェースには、1つのメソッドがあります。
リスト7. URIResolverインターフェース
package javax.xml.transform;
public interface URIResolver {
public Source resolve(String href, String base)
throws TransformerException;
}
|
このインターフェースを実装すると、XMLコードの中で検出されたURI (xsl:import やxsl:include など) が処理されることになります。特定のURIが検出された場合にSource (後で説明します) を戻すことによって、変換プログラムが指定の文書を指定の場所で検索するように設定できます。たとえば、http://www.oreilly.com/oreilly.xsl というURIの組み込みが検出された場合、その代わりにローカルの文書oreilly.xsl を戻すようにして、ネットワーク・アクセスを回避する、といった具合です。URIResolver インターフェースの実装は、TransformerFactory のsetURIResolver() メソッドで設定し、getURIResolver() メソッドで取得します。
いろいろなオプションを設定したら、最後にファクトリーのnewTransformer メソッドによってTransformer のインスタンス (複数も可) を取得できます。
リスト8. Transformerの取得
// Get the factory
TransformerFactory factory = TransformerFactory.newInstance();
// Configure the factory
factory.setErrorResolver(myErrorResolver);
factory.setURIResolver(myURIResolver);
// Get a Transformer to work with, with the options specified
Transformer transformer = factory.newTransformer(new StreamSource("sheet.xsl"));
|
お気づきのとおり、このメソッドは、そのTransformer インスタンスのあらゆる変換で使用するスタイルシートを入力として取り込みます。つまり、1つの文書をスタイルシートAとスタイルシートBによって変換したいと思う場合は、各スタイルシート用に1つずつ、合わせて2つのTransformer インスタンスを作成する必要があるということです。ただし、複数の文書を1つのスタイルシート (たとえば、スタイルシートC) で変換する場合は、スタイルシートCを指定したTransformer インスタンスを1つ作成するだけで済みます。
Transformer インスタンスを取得したら、実際にXML変換を実行できます。この処理には、2つの基本的なステップがあります。
- 使用するXSLスタイルシートの設定
- 変換の実行 (XML文書と結果の宛先を指定)
すでに説明したとおり、最初のステップは実に簡単です。ファクトリーからTransformer インスタンスを取得するときに、スタイルシートを指定する必要があります。このスタイルシートの位置は、その位置のjavax.xml.transform.Source というかたちで指定する必要があります。これまでのサンプル・コードにも出てきたSource インターフェースは、スタイルシートであれ、文書であれ、その他の情報セットであれ、入力として使用するものの位置を指定するための手段です。TRaXには、Source インターフェースだけでなく、次のような具体的な実装が3つ用意されています。
-
javax.xml.transform.stream.StreamSource -
javax.xml.transform.dom.DOMSource -
javax.xml.transform.sax.SAXSource
最初のStreamSource は、ある種の入出力装置から入力を読み込みます。InputStream、Reader、String のいずれかのシステムIDを入力として受け入れるためのコンストラクターが用意されています。作成したStreamSource は、Transformer に渡して使用することもできます。これはまさに、Source の実装の中で一番よく使う実装でしょう。ネットワーク上の文書、入力ストリーム、ユーザー入力などの静的な表現を読み込むための便利な実装です。
次のSource であるDOMSource は、既存のDOMツリーから情報を読み込むための実装です。DOMのorg.w3c.dom.Node を取り込むためのコンストラクターが用意されており、そのNode から情報を読み込むことになります。特に、構文解析がすでに済んでおり、XML文書がすでにDOM構造のメモリー内に入っている状況で、変換処理に対して既存のDOMツリーを指定するのにたいへん便利な実装です。
SAXSource は、SAX生成プログラムから入力を読み込むための実装です。このSource 実装は、SAXのorg.xml.sax.InputSource かorg.xml.sax.XMLReader を入力として取り込み、これらのソースからのイベントを入力として使用します。SAXがすでに使用されており、コールバックが設定されている状態で、変換前にコールバックを実行する必要があるようなケースでは、たいへん便利な実装です。
適切なSource というかたちでスタイルシートを指定した上で、Transformer インスタンスを取得したら、次の段階として変換を実行できます。そのためには、transform() メソッドを次のように使います (もう予想できるでしょう)。
リスト9. 変換の実行
// Get the factory
TransformerFactory factory = TransformerFactory.newInstance();
// Configure the factory
factory.setErrorResolver(myErrorResolver);
factory.setURIResolver(myURIResolver);
// Get a Transformer to work with, with the options specified
Transformer transformer = factory.newTransformer(new StreamSource("sheet.xsl"));
// Perform transformation on document A, and print out result
transfomer.transform(new StreamSource("documentA.xml"),
new StreamResult(System.out));
|
transform() メソッドは、2つの引数を取り込みます。Source 実装とjavax.xml.transform.Result 実装です。このようなコンビの仕組みについてはすでに見ているなので、Result インターフェースの機能についても想像できるはずです。Source では、変換対象のXML文書を指定し、Result では、変換後の出力の宛先を指定するわけです。Source と同じように、Result インターフェースについても、TRaXとJAXPに3つの具体的な実装が用意されています。
-
javax.xml.transform.stream.StreamResult -
javax.xml.transform.dom.DOMResult -
javax.xml.transform.sax.SAXResult
StreamResult は、構造メカニズムとして、OutputStream (上記のサンプルのSystem.out と似ている) かWriter を取り込みます。DOMResult は、変換の出力先としてDOMのNode を取り込みます (基本的にはDOMのorg.w3c.dom.Document)。また、SAXResult は、変換後のXMLに起因するコールバックの起動先としてSAXのContentHandler を取り込みます。これらはいずれも、Source の対応実装とよく似ているので、使用法についても簡単に予想できるでしょう。
上記のサンプルでは、ストリームからストリームへの変換を示していますが、ソースと結果は、どのように組み合わせてもかまいません。例をいくつか挙げておきます。
リスト10. 各種TRaX/JAXP変換
// Perform transformation on document A, and print out result
transformer.transform(new StreamSource("documentA.xml"),
new StreamResult(System.out));
// Transform from SAX and output results to a DOM Node
transformer.transform(new SAXSource
(new InputSource("http://www.oreilly.com/catalog.xml")),
new DOMResult(DocumentBuilder.newDocument()));
// Transform from DOM and output to a File
transformer.transform(new DOMSource(myDomTree),
new StreamResult(new FileOutputStream("results.xml")));
// Use a custom source and result (JDOM)
transformer.transform(new org.jdom.trax.JDOMSource(myJdomDocument),
new
org.jdom.trax.JDOMResult(new org.jdom.Document()));
|
ここまでの部分から理解できるとおり、TRaXには、さまざまな入力タイプからさまざまな出力タイプに変換する点でも、いろいろな形式 (ファイル、メモリー内DOMツリー、SAXリーダーなど) でXSLスタイルシートを使用する点でも、非常に柔軟な設定が可能です。
TRaXにはほかにも重要な項目がいくつかありますが、ここで取り上げた項目に比べれば、それほど頻繁に使われるわけではありません。それに、すべてをここで取り上げる余裕もありません。したがって、JAXP仕様にTRaX APIが実際に組み込まれた時点で (遠からずそうなるはずです)、ご自分でチェックしてみることをお勧めします。まさに機能の充実した、安定性の高いXML変換用APIです。出力プロパティーをいろいろ試してみたり、エラー処理 (XSL変換時と入力ソース検出時の両方のエラー処理) を設定してみたり、ほかにもこのAPIの便利な機能をいろいろ見つけてみたり、といった具合に、楽しんでみてください。そして、何かご意見があれば、ぜひ専門家グループまでお知らせください。
まとめに移る前に、注意を一言付け加えておきます。たとえば、本稿を3か月後に読んでJAXP 1.1をダウンロードしたときに、コンパイル・エラーや実行時エラーが発生した場合は、これがJAXP 1.1の完成前の記事であることを思い出してください。リリース前の記事はどれもそうですが、本稿の場合も、時間の経過と共に状況が変化するかもしれません。原稿の執筆段階からdeveloperWorks の編集段階に移るごく短い間にさえ、状況が変化するもあり得るわけです。要するに、本稿で取り上げたメソッドや機能は、あくまでも執筆時点のメソッドや機能であって、JAXP仕様は現時点でも流動的な 部分を残しています。そういう事情からすれば、ここで取り上げた概念は重要ではあっても、1、2のメソッドについては、名前の変更や、場合によっては動作の若干の変更があるかもしれないということを忘れないようにしてください。いずれにしても、本稿で説明した中心的な概念は、何らかのかたちでJAXP 1.1に取り入れられるはずです。とりあえず、JAXP 1.1の仕様と参考実装が完成するまでは、今回の概念の説明が正しいと思っていただいて差し支えありません (もちろん、詳細については変更があり得ますが)。
今回は、JAXPの次のバージョンに関する内幕を披露しました。仕様の最終的な公開草案は、2000年の末に完成するはずです。その後しばらくして実際の参考実装が発表され、2001年3月末までには残り仕事も完全に終了する予定です。JAXPの参考文献を調べるときには、少し注意してください。現時点 (2000年11月初旬) の仕様の草案には、本稿で取り上げたTRaX APIがまだ組み込まれていません。本稿の執筆時点でも仕様の改訂作業が進められているので、まもなく最新の仕様が発表されることになるはずです。
JAXPがさらに安定するのを待っていた読者であれば (1.0バージョンの制限事項からすれば、それもなかなか賢い選択だったと言えます)、この機会に本格的に始めてみるのはどうでしょうか。筆者のこれまでの記事や「Java and XML」という書籍では、SAX 2.0とDOM Level 2のサポートがまだなかったこともあって、JAXP 1.0をそれほど強くお勧めしていませんでしたが、今度のJAXP 1.1については、大きな前進として心からお勧めしたいと思います。JavaとXMLの開発者にとっては、XML文書の構文解析や変換を実行するベンダー非依存コードを記述するためにどうしても欠かせないツールと言えます。このツールを必ずチェックして、アプリケーションを快調に走らせてください。
-
JAXP 1.1仕様を読んで、ソースから詳細情報を得てください。
- 今すぐ始めたい方には、JAXP 1.0の仕様と参考実装がすでに公開されています。
- JAXP 1.1以前の状況については、JAXP 1.0 に関する総合的な記事をお読みください。やはり今回と同じBrett McLaughlin氏の記事です。
-
SunのXMLプロジェクトの全体像については、JavaとXMLに関するオンライン本部を参照してください。
- Apache XMLのApache JAXP実装 を入手できます。
- SAXでサポートしているXMLの別の側面については、W3CのWebサイトでDOM をご覧ください。
- 490ページ余りのXML専門書「Java and XML」(O'Reilly) をお読みください。最新テクノロジーに関するBrett McLaughlin氏の書籍です。
- developerWorks には、Java言語開発者向けのXMLツールとAPIのニュースグループがあります。ぜひご参加ください。
- XMLやXSLTの基本を知りたいという方は、developerWorks の教育プログラムをお試しください。たいへん初歩的な内容になっています。
Brett McLaughlin氏は、Logo (小さな三角形を覚えていますか?) の時代からコンピューターの仕事をしています。現在の専門は、JavaおよびJava関連のテクノロジーを使ったアプリケーション・インフラストラクチャーの構築です。ここ数年は、Nextel Communications and Allegiance Telecom, Inc. でこれらのインフラストラクチャーの実装に携わっています。Brett氏は、Javaサーブレットを使ってWebアプリケーション開発のための再利用可能なコンポーネント・アーキテクチャーを構築するJava ApacheプロジェクトTurbineの共同設立者の1人です。同氏はまた、オープン・ソースのEJBアプリケーション・サーバーであるEJBossプロジェクトと、オープン・ソースのXML Web公開エンジンであるCocoonにも貢献しています。
目次
タグ
スライダーバーを使用することで、より多く（少なく）タグを表示します。
人気のタグは、この特定のコンテンツ・ゾーン（例えば、Java テクノロジー、Linux や WebSphere など）に対するトップのタグを表示します。
マイ・タグは、この特定のコンテンツ・ゾーン（例えば、Java テクノロジー、Linux や WebSphere など）に対するお客様ご自身のタグを表示します。
記事の人気タグ |
記事のマイ・タグタグ・リストへスキップ
記事の人気タグ |
記事のマイ・タグ