| |
XML Schema内でコメントを定義する | |
|
スキーマ定義の中にコメントを表現するには、<xsd:annotation>要素を使います。この配下には、システム的に利用される情報用の<xsd:appInfo>要素、人間によって利用される情報用の<xsd:documentation>要素を記述します。
|
2004/5/26
XML Schemaは、データ型やノードの階層関係を極めて柔軟に、かつ高度に定義できる、優れたスキーマ言語ですが、それはあくまでコンピュータ上で自動的にデータを検証、操作するためのものです。
つまり、XML Schemaは、<title>要素が1〜50けたの文字列で構成されることを表現できたり、<price>要素が正数で構成されていることは表現できても、<title>要素が書名であるのか、それともスキーマのタイトルなのか、あるいは、人の階位なのかは表現できないのです。
このようなセマンティックな定義については、適宜、コメントとしてスキーマ文書に加え、後からそのスキーマ文書を人間が見たときにある程度の内容を理解できるようにしておく必要があります。
このコメントを表現するのが、<xsd:annotation>要素の役割です。まずは、以下に具体的なコードを見てみることにしましょう。
[books_annotation.xsd]<?xml version="1.0" encoding="Shift_JIS" ?> |
<xsd:annotation>要素はコメント全体を規定する要素で、パーサは配下の内容を完全に無視します。<xsd:annotation>要素は、スキーマ文書内のありとあらゆる要素の配下に記述できます。
<xsd:annotation>要素配下には、<xsd:appInfo>要素と<xsd:documentation>要素とを記述することが可能です。単なるコメントであるのに、なぜ2種類のタグに分類されているのか不思議に思うかもしれません。これらタグの使い分けは、スキーマ文書をXML文書として処理する場合に非常に重要なポイントです。
通常、<xsd:appInfo>要素にはシステム的に利用される情報を、<xsd:documentation>要素には人間によって利用される情報を記述します。例えば、スキーマ文書から動的に仕様書ドキュメントを生成する場合、2つのタグを明確に分類しておくことで、人間にとって必要な<xsd:documentation>要素の内容だけを抽出できるのです。
なお、<xsd:appInfo>、<xsd:documentation>要素のいずれにもsource属性を指定することが可能です。source属性には、スキーマ文書内には書ききれない、より詳細なドキュメントの場所をURI参照の形式で指定します。また、<xsd:documentation>要素にのみxml:lang属性を指定できます。これによって、配下に記述されている情報がどの言語に属するものなのかを規定でき、自動的なドキュメント生成の場合にも対応言語ごとに分岐できるようになるというわけです。
<xsd:annotation> |
| 実際に、妥当性検証を行いたい場合には、別稿「XML SchemaでXML文書の妥当性を検証する」のサンプルを参考にするとよいでしょう。変更個所は、XMLSchemaCache.addメソッドの第2引数(XML Schemaのファイル名)のみです。スキーマ文書を書いてみるだけでは、スキーマ文書そのものの妥当性を判断できませんが、パーサの処理を介することでスキーマの正否を確認できます。 |
| 「XMLテクニック集」 |
TechTargetジャパン
- QAフレームワーク:仕様ガイドラインが勧告に昇格 (2005/10/21)
データベースの急速なXML対応に後押しされてか、9月に入って「XQuery」や「XPath」に関係したドラフトが一気に11本も更新された - XML勧告を記述するXMLspecとは何か (2005/10/12)
「XML 1.0勧告」はXMLspec DTDで記述され、XSLTによって生成されている。これはXMLが本当に役立っている具体的な証である - 文字符号化方式にまつわるジレンマ (2005/9/13)
文字符号化方式(UTF-8、シフトJISなど)を自動検出するには、ニワトリと卵の関係にあるジレンマを解消する仕組みが必要となる - XMLキー管理仕様(XKMS 2.0)が勧告に昇格 (2005/8/16)
セキュリティ関連のXML仕様に進展あり。また、日本発の新しいXMLソフトウェアアーキテクチャ「xfy technology」の詳細も紹介する
|
|
キャリアアップ
スポンサーからのお知らせ
- - PR -
イベントカレンダー
- - PR -
