気の向くままに辿るIT/ICT/IoT
XSLT

【Conformance / 一致】XSLT 2.0/XSL Transformations Version2.0/Extensible Stylesheet Language Transformations Version2.0

ホーム前へ次へ
XSLT一致とは?

【Conformance / 一致】XSLT 2.0/XSL Transformations Version2.0/Extensible Stylesheet Language Transformations Version2.0

XSLT 2.0一致とは

 W3C勧告XSLTバージョンXSLT 2.0の「Conformance / 一致」

 XSL Transformations (XSLT) Version 2.0 / W3C Recommendation 23 January 2007の目次に沿った日本語訳です。

 当サイト管理人が2009年04月、意訳したものですが、構文解釈の違いや翻訳の違いが含まれるかもしれません。正式文書はW3C 各種仕様書(英語版)である事を予めご了承ください。

<< 20. シリアライゼーション / Serialization

XSLT 2.0一致目次


21 一致 / Conformance
 21.1 基本XSLTプロセッサ Basic XSLT Processor
 21.2 スキーマ認知XSLTプロセッサ Schema-Aware XSLT Processor
 21.3 シリアライズの特徴 Serialization Feature
 21.4 後方互換性の特徴 Backwards Compatibility Feature

21 一致

この仕様との一致を要求するプロセッサは、 基本XSLTプロセッサ、 または、スキーマ用XSLTプロセッサ としていずれかとの一致を要求しなければいけません。 レベルに一致するこれら2つにおける規則は、次に続くセクションで定義されます。

これら2つのレベルのいずれかとの一致を要求するプロセッサは、付加的にいずれかとの一致、または、次に続くオプション特性の両方との一致を要求する場合があります: シリアライゼーション特性は、21.3 シリアライゼーション特性で定義しました、そしてまた、 21.4 後方互換性特性では、後方互換性特性を定義しました。

注釈:

[XPath 2.0]で記述した静的に区分している特性の手法を要求するこの仕様で定義した存在しない一致レベル、または、特性があります。 XSLT プロセッサは、静的な区分を実行する為のユーザーオプションを提供する場合がありますが、静的区分利用不可を伴って処理されるスタイルシートを許容しなければいけないこの仕様と一致していなければいけません。 XSLT スタイルシートの XPath 2.0 の静的に区分した特性との相互作用は、記述されていません、その為、その結果が、もし利用可能であれば、静的な区分を利用する事は implementation-defined です。

XSLT プロセッサは、スタイルシートと[データモデル]で定義したデータモデルと一致する1つ以上のXDMツリーをその入力として受け取ります。 プロセッサが構築するXDMツリーのいくつかの固有のメソッドをサポートする事は、要求されませんが、一致は、唯一テストされる事ができ、それは、 スタイルシートと構築される、そしてプロセッサに入力として提供した初期の(primary)ソース文書を表しているXDMツリーを利用可能とするメカニズムを提供します。

XSLT プロセッサの出力は、ゼロ以上の最終結果ツリーで構成されます。 プロセッサがアクセスしている最終結果ツリーのいくつかの固有のメソッドをサポートする事は、要求されませんが、 もし、それがシリアライゼーションモジュールをサポートしない場合には、 もし、それが、変換の結果へのアクセスを可能とするいくつかの代替メカニズムを提供する場合には、一致は、唯一テストされる事が可能です。

この仕様での確かな利便性は、生成したimplementation-defined結果が明記される事です。 この仕様との一致を仮定する要求は、[implementation-defined] 特性ごとの効果を状態を保持している文書化によって伴われなければいけません。 利便性については、[implementation-defined] 特性の非標準チェックリストが、 F [implementation-defined] 特性のチェックリストで提供されます。

一致するプロセッサは、 個別のエラー条件、または、前方互換性動作 (参照先: 3.9 前方互換性処理)において一般的に用意されたものの下で他に記述した場合を除き、 スタイルシート、または、いくつかの XPath に出現するいくつかの静的エラーをシグナル出力しなければいけません。 このようなエラーをシグナル出力した後、プロセッサは、付加的なエラーをシグナル出力する目的において継続する場合がありますが、 いくつかの変換を実行することなく異常終了しなければいけません

動的エラーが変換の進行中に出現する場合には、動作は、 回復可能なエラーとして分類されるエラーかどうかに依存します。 もし、回復不能なエラーが出現する場合には、プロセッサは、それをシグナル出力しなければならず、そしてまた、結局は異常終了しなければいけません。 もし、回復可能なエラーが出現する場合には、プロセッサは、それをシグナル出力するか、異常終了するかいずれかにしなければならないか、 または、定義した回復動作と継続処理を採らなければいけません

いくつかのエラーは、特にタイプエラーは、プロセッサの判断で 静的エラー、または、動的エラー として扱われる場合があります

一致しているプロセッサは、スタイルシートの処理によって消費した処理リソース上の限界を課す場合があります

21.1 基本XSLTプロセッサ

[定義:  基本XSLTプロセッサは、スキーマ処理に関連した確実な明示的に識別した構築という例外を伴うこの仕様の全ての命令要求に手段を提供する XSLT プロセッサです。 ] これらの構築は、下記で列挙されます。

この仕様の命令要求は、[XPath 2.0]で記述したように XPath 2.0 の命令要求を含む為に受け取られます。 要求は、仕様が、それがオプションである事を明確に示す(語句 should/べき 、または、 may/場合がある といった利用のような)言い回しを含む場合を除き、命令があります。

基本XSLTプロセッサは、次に続く制限を(強制)適用しなければいけません。 それは、以下に記述したように、制限が違反される場合に静的エラーまたは、動的エラーをシグナル出力しなければいけません

[ERR XTSE1650] 基本XSLTプロセッサは、もし、 スタイルシートが、 xsl:import-schema 宣言を含む場合には、 静的エラーをシグナル出力しなければいけません

注釈:

xsl:import-schema 宣言を拒絶するプロセッサは、 スキーマの中で定義したユーザー定義タイプ、または、ユーザー定義要素、または、属性宣言の為のいくつかの参照をも拒絶するでしょう; それは、しかしながら、3.13 ビルトイン(組み込み)タイプで列挙したビルトイン(組み込み)タイプを拒絶されないでしょう。

[ERR XTSE1660] 基本XSLTプロセッサは、もし、 スタイルシートが、 strip 以外の値を伴う [xsl:]type 属性、または、 [xsl:]validation 、または、 default-validation 属性を含む場合には、静的エラーをシグナル出力しなければいけません

基本XSLTプロセッサは、次に続くようにデータモデルを制約します:

  • 原子化された値は、(以下で注記した場合を除き) 3.13 ビルトイン(組み込み)タイプで列挙した原子化されたタイプの1つに沿っていなければいけません

    原子化された値は、 拡張関数、または、拡張命令 を伴う利用において文脈の為に追加されている[implementation-defined] タイプに属している場合もあります。

    利用可能なコンストラクタ関数のセットは、上記の原子化されたタイプの値を構築するそれらに制限されます。

    XSLT プロセッサ、また、 XPath プロセッサによって認識されるタイプ名の完全なセットを定義する静的文脈は、これらの原子化されたタイプに加え、 xs:anyTypexs:anySimpleTypexs:untypedxs:anyAtomicType をも含みます。

  • 要素ノードは、タイプ注釈 xs:untyped そしてまた、タイプ注釈 xs:untypedAtomic を伴う属性ノードを伴って注釈を付記されなければいけません

[ERR XTDE1665] 基本XSLTプロセッサは、もし、プロセッサへの入力が、 xs:untyped 、または、 xs:untypedAtomic 、または、基本XSLTプロセッサがサポートするそれら以外のタイプの原子化された値以外の タイプ注釈を伴うノードを含む場合には、回復されない動的エラーを 出現させなければいけませんこのエラーは、もし、 input-type-annotations 属性が strip に設定される場合には、現れないでしょう。

注釈:

たとえ、これが、妥当でない入力を回避する為の要求という目的で表現されるとしても、代替アプローチは、 現れるシチュエーションを許容するであろういくつかのインタフェースを提供しない事によって出現しているこのエラー条件を防ぐ基本XSLTプロセッサの為にあります。 プロセッサは、例えば、データモデルからPSVIをマッピングする手法は、全てのありふれていない(non-trivial)タイプ注釈を失う場合があり、または、全てにおいてPSVIからの入力を許容しない場合があります。

プロセッサに入力する フレーズは、ゆうゆうと(deliberately)幅広いものです:それは、ツリーが含んでいる初期文脈ノードdocumentdocFOcollectionFO 関数を利用してアクセスしたツリー、 拡張関数拡張命令によって返したツリー をスタイルシートパラメータとして通過したツリーを含みます。

21.2 スキーマ用XSLTプロセッサ

[定義:  スキーマ用XSLTプロセッサは、基本XSLTプロセッサがエラーとしてシグナル出力するそれらの特性を含んでいるこの仕様の全ての義務的な要求を満たす手段である XSLT プロセッサです。 この仕様の義務的な要求は、[XPath 2.0]で記述したように、 XPath 2.0 の義務的な要求を含む為に受け取られます。 要求は、それがオプションであると明確に示す(語句 should/すべき 、または、 may/場合がある といった)言い回しを含む仕様である場合を除き、強制的です。 ]

21.3 シリアライゼーション特性

[定義:  シリアライゼーション特性との一致を要求するプロセッサは、20 シリアライゼーションで定義した規則に続いているオクテットのシーケンスにおける 最終結果ツリーの変換をサポートしなければいけません] それは、 xsl:outputxsl:character-map 宣言の全ての属性と関連しなければならず、 そしてまた、 xmlxhtmlhtmltext の4つ全ての出力メソッドを提供しなければいけません。 仕様が、must/なければいけないrequired/必須・要求される というような語句を利用する場合には、 それは、記述した明確な方法で結果ツリーをシリアライズしなければいけません; 他のケースでは、それは、同等な表現である代替手段を利用する場合があります

プロセッサは、 xsl:text 、または、 xsl:value-of において disable-output-escaping="yes" を設定する事をサポートするかどうかというシリアライゼーション特性との一致を要求する場合があります。

シリアライゼーション特性との一致を要求しないプロセッサは、 スタイルシートが、 xsl:output 、 または、 xsl:character-map 宣言、 または、 xsl:result-document 命令におけるシリアライゼーション属性を含むので 単にエラーをシグナル出力してはいけません。 このようなプロセッサは、これらの宣言と妥当な値を持つ属性をチェックする場合がありますが、そうする事を要求されるわけではありません。 付加的な妥当性検証は別として、これらの宣言は、無視されるべきです。

21.4 後方互換性特性

[定義:  後方互換性特性との一致を要求するプロセッサは、 3.8 後方互換性処理で定義したように、後方互換性挙動を伴う スタイルシート命令とXPath式の処理をサポートしなければいけません]

注記としては、後方互換性特性との一致を要求しないプロセッサは、もし、命令が後方互換性挙動を実行する [xsl:]version 属性を含んで評価される場合には、 回復されない動的エラーを生じなければいけません[参照:ERR XTDE0160]

注釈:

これが、静的エラーではなく、動的エラーである理由は、XSLTプロセッサが提供する手段が XSLT 1.0、または、XSLT 2.0かどうかに依存している 異なるパスに続いている条件付きロジックを含むスタイルシートを許容する為です。 利用される為のパスのセレクションは、 xsl:version システムプロパティをテストする為の system-property 関数を 利用する事によって操作される事が可能です。

後方互換性特性との一致を要求するプロセッサは、 後方互換性挙動が利用可能である場合に XPath式にある名前空間軸(axis)の利用を許可しなければいけません。 他の状況では、名前空間軸(axis)はオプションとしてサポートします。

巻末 / Appendices >>


ホーム前へ次へ