【XSLT 2.0概念・コンセプト】XSLT 2.0/XSL Transformations Version2.0/Extensible Stylesheet Language Transformations Version2.0

2.1 専門用語

用語の全ての用語辞典については、C 用語辞典参照。

[定義：  XSLTスタイルシートを利用して結果ツリーにあるソースツリーを変換する為の責任を持つソフトウェアは、プロセッサとして参照されます。 これは、例えば、XMLプロセッサといった他のプロセッサとの混同を避けるために時折XSLTプロセッサに拡張されます。 ]

[定義：  XSLT プロセッサ関数を実行する生成仕様は、implementation(手法・手段・装置・プロセッサ)として参照されます。 ]。

[定義：  用語結果ツリーは、スタイルシートにある指示命令によって構築したいくつかのツリーを参照する為に利用されます。 結果ツリーとは、最終結果ツリー、または、一時的なツリーの事です。 ]

[定義：  最終結果ツリーとは、変換の最終出力の一部を形作る結果ツリーです。 一度創出された最終結果ツリーのコンテンツは、スタイルシートそれ自身の中身はわかりやすいものではありません。 ] xsl:result-document命令は、最終結果ツリーを常に創出します、また最終結果ツリーは、初期テンプレートによって厳密に創出される場合もあります。 これが生じる下での条件は、2.4 変換を実行する内で記述されます。 最終結果ツリーは、20 シリアライゼーションの中で記述したようにシリアライズされる場合があります。

[定義：  用語ソースツリーは、変換の為の入力として提供したいくつかのツリーという意味です。 これは、スタイルシートパラメータ、document、doc^FO、collection^FO、拡張関数または、拡張命令によって返した文書のような関数の結果から文書を含んだ値として提供したノードを含んでいる文書、もしあれば、初期の文脈ノードを含んでいる文書を含みます。 固有のXSLT命令の文脈では、用語ソースツリーは、命令として入力する際に提供したいくつかのツリーという意味です。； これは、全体としての変換のソースツリーである場合、または、それは変換の進行中に生成した一時的なツリーである場合があります。 ]

[定義：  用語一時的なツリーは、ソースツリーでも最終結果ツリーでもない、いくつかのツリーという意味です。 ] 一時的なツリーは、変換の実行中に直ちに結果を保持する為に利用されます。

この仕様では、must/しなければならない、must not/してはいけない、

should/べき、should not/べきでない、may/場合がある・かもしれない、required/必須・要求される、recommended/推奨といったフレーズは、[RFC2119]の中で記述されたものとして解釈される為です。

must/しなければならない、must not/してはいけないというフレーズ、または、XSLTプロセッサのふるまいに関連する要求がある場所では、それが21 一致内でより詳細化された規則における項目で記述したようにふるまう場合を除き、一致・順応する方法ではありません。

must/しなければならない、must not/してはいけないというフレーズ、または、スタイルシートに関連する要求がある場所では、プロセッサは、もし、制約が満たされない場合にはエラーを報告する事によってスタイルシート上にこの制約を強制しなければいけません。

should/べき、should not/べきでないというフレーズ、または、スタイルシートに関連する推奨(recommended)がある場所では、もし、制約が満たされない場合には、プロセッサが警告メッセージを発する場合がありますが、必ずしもエラーとして扱わなければいけないというわけではありません。

[定義：  この仕様では、用語implementation-definedは、いくつかの柔軟性が許容される方法の特性、いくつかの一致要求を伴って起こる文書の中に記述されなければならない方法によってなされる選択の特性を参照します。 ]

[定義：  用語implementation-dependentは、その他の方法から変更されるふるまいの特性を参照する場合があり、ベンダーは、ふるまいの全ての仕様を提供する事を期待されません。 ] (これは、例えば、変換可能なソース文書のサイズを制限する為に提供する場合があります。)

この仕様が無視するふるまい全てにおいて、[implementation-defined]、または、[implementation-dependent]といったその手法は、振る舞いの影響を受けるユーザーを許容する提供しているメカニズムのオプションを持ちます。

段落は、注記としてラベル付けされるか、または、非標準として例を記述しました。

この文書で利用した多くの用語は、XPath 仕様 [XPath 2.0]、または、XDM 仕様 [データモデル]の中で定義されます。 固有の注意事項は次に続けて設計されます。：

• [定義： 用語atomizationは、 セクション 2.4.2 Atomization^XP内で定義されます。 それは、ノードと原子化された値のシーケンス入力として取得されるプロセスであり、そのノードが[データモデル]で定義したものとしてのそれらの区分値によって返される中で原子化された値のシーケンスを返します。 ] いくつかのノード (例えば、要素だけのコンテンツを持つ要素)においては、動的エラーの生成を細分化します。

• [定義：  用語 typed 値は、セクション 5.15 typed-value Accessor^DMで定義しました。 要素だけを内容に持つ要素を伴うスキーマで定義した要素を除くそれぞれのノードは、区分値を持ちます。 例えば、xs:IDREFSタイプの属性の区分値は、1つのゼロのシーケンス、または、多くのxs:IDREF値です。 ]

• [定義：  用語 string 値は、セクション 5.13 string-value Accessor^DMで定義されます。 それぞれのノードは、string 値を持ちます。 例えば、その要素のstring値は、その全ての子孫テキストノードのstring値の結合です。 ]

• [定義：  用語 XPath 1.0 互換性モードは、セクション 2.1.1 静的な文脈^XPで定義されます。 これは、XPath式の静的な文脈の中で設定しています。それは、trueとfalseという2つの値です。 その値が「true」の際には、関数のセマンティクスが呼ばれ、確実にオペレーションが、XPath 2.0とXPath 1.0間の後方互換性の最大限の同意を与える為に調整されます。 ]

[定義：  用語 主要な関数は、[関数と演算子]に記述される関数とその標準関数 名前空間の中にある関数を意味しています。 ]

2.2 表記法

[定義：  XSLT 要素は、この仕様の中で定義されるシンタックスとセマンティクスのあるXSLT名前空間にある要素です。 ] XSLT要素の非標準リストについては、D 要素シンタックス要約参照。

この文書内では、それぞれのXSLT 要素仕様は、その要素タイプの要素の為の型の枠組みの中にあるそのシンタックスの要約によって優先されます。 これらの仕様の全リストは、D 要素シンタックス要約で見つけることができます。シンタックス要約表記法の意味するところは、次のようになります。：

• requiredという属性は、太字のその名称を伴って表示されます。省略される属性がある場合は、その名称につづけてクウェスションマーク(？)を伴って表示されます。

• deprecatedという属性は、角ブラケット内で灰色フォントで表示されます。

• 属性値の位置で要求する文字列は、属性の許容した値を記述します。 もし、これが({...})のように波カッコでくくられている場合には、属性値は、属性値テンプレートとして扱われ、 波カッコ内で要求している文字列は、属性値テンプレートを評価する結果として許容した値を記述します。 許容した値のとり得る値は、|によって区切られます。 括られた文字列は、記述した文字列と等しい値を表示します。 括られていない、イタリック体の名称は、値のタイプ固有の記述をします。

  限定された値セットにしなければならない属性の値というこの仕様ステータスの全てのケースでは、属性値にある先行するホワイトスペースと後ろに続くホワイトスペースは、無視されます。 属性値テンプレートのケースでは、これは、属性値テンプレートが拡張される際に含まれた有効な値を提供します。

• 要素が、空になるように要求されない限りは、そのモデル要素は、許容した内容を記述しているコメントを含みます。 許容した内容は、XMLにある要素タイプ宣言の方法に似た記述がなされます。; シーケンスコンストラクタは、許容される指示命令カテゴリからのリテラル結果要素、拡張命令、XSLT 要素といったテキストノードのいくつかの混合物という意味です。; その他の宣言は、xsl:importではなく、宣言カテゴリからのXSLT要素のいくつかの混合物という意味であり、ユーザー定義データ要素を伴って一緒に許容されます。

• 要素は、もし、instructionカテゴリまたは、declarationカテゴリ、または、その両方に沿うならば、表示しているコメントによって始められます。 限定的に作用するように、そのカテゴリは、シーケンスコンストラクタ、または、その他の宣言を許容する要素の内容の中で許容されます。

[ERR XTSE0010]もし、必須属性が省略、または、もし、要素の内容が、要素の為に許容される内容と一致しない場合には、もしそれが、許容されない文脈の中で利用されるXSLT定義要素であれば、静的エラーがシグナル出力されます。

属性は、次のように有効にされます。これらの規則は、前と後ろに続くホワイトスペースを削除した後で属性の値に適用します。

• [ERR XTSE0020] もし、属性値テンプレートが許容される位置で波カッコを利用して書かれた属性ではなく)その属性における許容した値の1つではない値を含んでいる属性の場合には、それは静的エラーです。

• [ERR XTDE0030] もし、許容された属性値テンプレート位置で波カッコを利用して書かれた属性の有効な値である場合には、それは、その属性における許容した値ではない値であり、それは回復されない動的エラーです。 もし、プロセッサが、静的なエラーを回避する事を可能にする場合(例えば、静的に評価される事が可能な波カッコ内にXPath式がある際)には、プロセッサは、付加的にこのような静的エラーのシグナルを出力する場合があります。

特別な規則は、もし、前方互換性動作を伴って処理されるスタイルシートの一部の中での出現を構築する場合に適用します。：参照 3.9 前方互換性処理。

[定義：  この仕様の中で定義したいくつかの構築は、deprecated(非推奨)となると記述されます。 この用語の利用は、スタイルシート作者が構築に利用するべきではない事を意味し、その構築は、この仕様の最終バージョンで削除される場合があります。 ] この仕様の中でdeprecated(非推奨)となる全ての構築は、(そうなった時のように)implementationsが提供する事を要求しない付加的な特性もあります。

XSLTは、[関数と演算子]の中で付加的に定義される標準関数のセットを定義します。 [関数と演算子]の中で利用したものとしての同じ表記法を利用して記述されるこれらの関数の用法表示が記述されます。 これらの関数の名称は、標準関数 名前空間に全てあります。

2.3 変換を初期化する

この文書は、初期化変換の為のいくつかのアプリケーションプログラミングインタフェース、または、他のインタフェースを記述しません。 このセクションは、しかしながら、他方でその情報がrequiredされると示される場合を除き、変換が開始される際に提供される情報を記述します。

Implementations は、2つ以上のフェーズとして実行する為の変換、例えば、解析、編集、実行を許容する場合があります。 このような識別はこの仕様のスコープ外であり、 XML文書のフォーム内で提供したスタイルシートモジュールのセットを利用して操作される単独のプロセスとして変換を扱います。

次に続く情報は、変換を実行する為に提供されます。：

• スタイルシートモジュールは、変換の為の主要なスタイルシートモジュールのように動作します。 完全なスタイルシートは、3.10.2 スタイルシート含有と3.10.3 スタイルシート取り込みに記述したように主要なスタイルシートモジュール内での宣言xsl:importとxsl:includeの再帰的な拡張によって組み立てられます。

• スタイルシートパラメータにおける値(カラも可)のセット(参照先： 9.5 グローバル変数とパラメータ)。 これらの値は、スタイルシートにある式の中で利用する為に使用します。

• [定義：  ノードは、5.4.3.1 継続位置：フォーカスで記述したようにXPath式 .(dot)とself::node()の初期値としてスタイルシート内でアクセスされるノードを変換する為の初期の文脈ノードのように動作します。 ]

  もし、提供される初期の文脈ノードがない場合には、文脈アイテム、文脈位置、文脈サイズは、最初に未定義となり、これらの値を参照するいくつかの式の評価は、動的エラーにある結果となるでしょう。(初期の文脈サイズと文脈位置としての注釈は、初期の文脈ノードが提供される際に、常に1となるでしょう。そして、もし、提供される初期の文脈ノードがない場合には未定義になるでしょう。)。

• 付加的な名前付きテンプレートの名称は、変換する為の入力ポイントとして実行される為にあります。 このテンプレートは、スタイルシート内に存在しなければいけません。 もし、提供される名前付きテンプレートがない場合には、変換は、6.4 テンプレートにおける干渉解決規則に定義した規則と一致している初期の文脈ノードとのベストマッチするテンプレート規則を伴って開始します。 名前付きテンプレート、または、初期の文脈ノードのいずれか、または、その両方が提供されなければいけません。

• 付加的な初期モード. これは、既定モード、または、スタイルシート内にあるxsl:template宣言のモード属性内で明示的に名前付けされるモードのいずれかにしなければいけません。 もし、初期モードが提供される場合には、テンプレート規則の中で検索され、初期の文脈ノードとベストマッチし、プロセッサは、初期モードを適用するこれらの規則に限定して配慮します。 もし、提供される初期モードがない場合には、既定モードが利用されます。

• URI出力基準。 [定義：  基準出力URIは、解決する際に基準としてURIが利用される為に関連URIは、最終結果ツリーに領域を確保されます。 もし、変換が1つ以上の最終結果ツリーを生成する場合には、この基準URIに関連するURIをそれぞれ1つずつ領域確保するでしょう。 ] 基準出力URIが発行される為の手法は、implementation-definedです。

• 含んでいる文書ノードとメディアタイプにおけるメカニズムは、完全なURIを与えます。 (URIから文書ノードにマッピングするように作った)利用可能な文書の全セットは、XPath式を評価する為の文脈の一部、特にdoc^FO関数を整形します。 いくつかのフラグメント識別子を解釈する中で利用する為のリソース再表示の付加的なメディアタイプ要求であるXSLTdocument関数は、URI参照内で提供します。

  注釈：

  文書のセットは、与えられるURIを利用して取得したリソースを再表示するツリーを構築する為に運び出される処理であるかのようにスタイルシートがimplementation-dependentを利用可能にします。 いくつかの文書構築可能な方法(特に情報セットやPSVIからの文書の為の文書構築の為の規則)は、[データモデル]に記述されます。

[ERR XTDE0040] もし、スタイルシートの適用がテンプレート名を記述し、スタイルシートの中で定義した名前付きテンプレートの拡張QNameと一致しない場合には、回復されない動的エラーです。

[ERR XTDE0045] もし、スタイルシートの適用が(他のモードではなく)初期のモードを記述し、スタイルシートの中で定義したいくつかのテンプレートのモード属性にある拡張QNameと一致しない場合には、回復されない動的エラーです。

[ERR XTDE0047] もし、スタイルシートの適用が初期モードと初期テンプレートの両方を記述する場合には、回復されない動的エラーです。

[ERR XTDE0050] もし、スタイルシートが実行される場合には、スタイルシートの実行中に提供されるこのパラメータにおけるrequired="yes"とnoという値を伴う可視化スタイルシートパラメータの宣言が実行される場合には、回復されない動的エラーです。 その他のグローバル変数、または、同じ名称を持つパラメータでより高い重要な優先度によって隠されない場合には、スタイルシートパラメータは可視状態です。

[定義：  変換は、初期テンプレートの評価によって実行されます。もし、名前付きパラメータが変換が初期化される際に提供される場合には、これは、初期化テンプレートです。； 他方で、初期化テンプレートは、初期モードの中で初期の文脈ノードを処理するxsl:apply-templates命令の規則と一致する選択したテンプレート規則です。 ]

クライアントアプリケーションによって変換を通過したパラメータは、スタイルシートパラメータと一致し(参照：9.5 グローバル変数とパラメータ)、 初期テンプレート内で定義したテンプレートパラメータとは一致しません。 実行される初期テンプレートにある全てのテンプレートパラメータは、それらの既定値を取るでしょう。

[ERR XTDE0060] もし、初期テンプレートが、required="yes"を記述するテンプレートパラメータを定義する場合には、回復されない動的エラーです。

変換が実行される際に提供したそれらの追加の中でスタイルシートは、(異なる)別のソース文書を処理する事ができます。 これらの付加的な文書は、関数document(参照：16.1 複数のソース文書)、または、doc^FOまたは、collection^FO(参照：[関数と演算子])を利用して読み込まれる事ができ、 または、それらは、スタイルシートパラメータ(参照先： 9.5 グローバル変数とパラメータ)として、または、拡張関数(参照：18.1 拡張関数)の結果として提供される事が可能です。

2.4 変換を実行する

[定義：  スタイルシートは、テンプレート規則(参照先： 6 テンプレート規則)を含みます。 テンプレート規則は3つの部分から成っています。：ノードに対して一致するパターン、(カラである事が可能な)テンプレートパラメータのセット、アイテムのシーケンスを生成する事を評価されるシーケンスコンストラクタ。 ] 多くのケースでは、これらのアイテムは、新たなノードが構築され、それはその時、結果ツリーに記述されます。

全体としての変換は、5.7 シーケンスコンストラクタに記述したように初期テンプレートのシーケンスコンストラクタを評価する事によって実行されます。

もし、初期テンプレートがas属性を持つ場合には、初期テンプレートの結果シーケンスは、他のいくつかのテンプレートの場合と同じ方法で要求タイプに対してチェックされます。 もし、この結果シーケンスが空(カラ)ではない場合には、 厳密な最終結果ツリーを構築する為に利用され、5.7.1 複雑な内容を構築するに記述した規則に続きます。：その効果は、初期テンプレートTが型式の厳密なテンプレートによって呼ばれたかのようになります。：

<xsl:template name="IMPLICIT">
	<xsl:result-document href="">
		<xsl:call-template name="T"/>
	</xsl:result-document>
</xsl:template>

厳密な結果ツリーは、結果シーケンスが空(カラ)の際にも生成され、提供したxsl:result-documentのない命令は、変換の進行中に評価されています。このシチュエーションでは、その厳密な結果ツリーは、子を持たない文書ノードで構成されるでしょう。

シーケンスコンストラクタは、スタイルシートにあるXSLT命令、リテラル結果要素、テキストノード、または、拡張命令のいずれかの内のそれぞれの同じ氏族ノードのシーケンスです。

[定義：  instructionは、XSLT命令、または、拡張命令のいずれかです。 ]

[定義：  XSLT 命令は、この仕様にあるシンタックス要約のあるXSLT要素に<!-- カテゴリ: 命令 -->表記を含みます。 ]

拡張命令は、18.2 拡張命令に記述されます。

XSLT 命令の主なカテゴリは、次のようになります。：

• 新しいノード生成命令: xsl:document, xsl:element, xsl:attribute, xsl:processing-instruction, xsl:comment, xsl:value-of, xsl:text, xsl:namespace;

• XPath式を評価する事によって任意のシーケンスを返す命令: xsl:sequence;

• 条件付き実行命令または、ネストされた命令の再帰的な評価: xsl:if、xsl:choose、xsl:for-each, xsl:for-each-group;

• テンプレートを実行する命令: xsl:apply-templates, xsl:apply-imports, xsl:call-template, xsl:next-match;

• 変数を宣言する命令: xsl:variable, xsl:param;

• その他の特別な命令: xsl:number、xsl:analyze-string, xsl:message, xsl:result-document。

しばしば、シーケンスコンストラクタは、xsl:apply-templatesを含み、処理されるノードのシーケンスを選択します。 テンプレート規則との一致とそのテンプレート規則のシーケンスコンストラクタを評価する事によって選択されたそれぞれのノードは処理されます。 アイテムのシーケンス結果出力は、6.3 テンプレート規則を適用するで記述したようにxsl:apply-templates命令の結果を与える為に、その中で命令が結合されます；このシーケンスは、しばしば結果ツリーに追加されます。 選択したテンプレート規則のシーケンスコンストラクタは、xsl:apply-templates命令、ノード選択のサイクルの中にあるこの結果のいくつかを含み、テンプレート規則を識別し、シーケンスを構築し、そしてソースツリーを通して繰り返され、結果ツリーを構築する場合があるからです。

2.5 文脈を評価する

スタイルシートにあるいくつかの式や命令の結果は、提供した文脈情報に依存する場合があります。 この文脈情報は、2つのカテゴリに分けられます。： 静的文脈は、スタイルシートの静的解析実行中に認知され、動的文脈は、スタイルシートが評価されるまでは認知されません。 けれども静的文脈にある情報は、解析時に認知され、時にスタイルシート評価中に利用されます。

いくつかの文脈情報は、スタイルシートそれ自身の中で宣言するという意味合いによってセットする事が可能です。 例えば、いくつかのXPath式の為に利用をバインディングする名前空間は、スタイルシートにおいてその中で記述した名前空間宣言を含む事によって決定されます。 他の情報は、例えば、現在の日付と時刻(のように)外部から、または、厳密に提供される場合があります。

XSLTスタイルシートを処理する中で利用した文脈情報は、XPath式評価時に要求した文脈情報全てをサブセットとして含みます。 XPath 2.0仕様は、静的文脈と動的文脈を定義し、ホスト言語(このケースでは、XSLT)は、初期化する場合があり、その文脈の中で利用したXPath式の結果に影響を及ぼします。 XSLTは付加的な情報を持つ文脈を引数に取る: この付加的な情報は、最初にXPathのスコープ外のXSLT構築(例えば、xsl:sort要素)によって利用され、 次に、(keyとformat-numberのような)XSLT仕様の中で定義された関数によって利用され、 それは、スタイルシート内で現れるXPath式の中で利用する為に利用可能となります。

式における静的文脈、または、他のスタイルシート内での構築は、語彙的な出現の中にある位置によって決定されます。 静的文脈の異なるコンポーネントについては詳細は違いますが、一般にスタイルシートモジュール内にある要素は、同じスタイルシートモジュール内にあるそれらの子孫要素における静的文脈に作用します。

動的な文脈は、スタックとして保持されます。 命令、または、式が評価される際には、スタックする為の文脈情報を動的に追加する場合があります； 評価が完全であるとき、動的な文脈は、その前の状態に立ち返ります。 式は、スタックのトップにある値を常に利用する動的な文脈からの情報にアクセスします。

もっと一般的には、動的な文脈を利用したコンポーネントは、文脈アイテムです。 これは、値が現時点で処理されているアイテム(それは、1つのノードまたは、1つの原子化された値になる場合があります。)である暗黙の変数です。 文脈アイテムの値は、その式. (dot)を利用してXPath式内で参照される事が可能です。

静的文脈と動的文脈の全詳細は、5.4 静的文脈と動的文脈の中で提供されています。

2.6 解析とシリアライゼーション

XSLTスタイルシートは、ソースツリーのセットから最終結果ツリーのセットを構築するプロセスを記述します。

スタイルシートは、ソースツリーがどのように構築されるかについては記述しません。 ソースツリー構築のいくつかの可能な方法は、[データモデル]の中で記述さます。 しばしば、implementationは、 XMLパーサー (または、より厳密に[XML 1.0]の専門用語にあるXMLプロセッサ)を伴う結合の中で操作され、XML文書を入力するソースツリーを構築します。 (この条件を)満たすには、直接構築されるツリーを許容している、または、文書オブジェクトDOM(参照先： [DOMレベル2])の構成の中で提供される事を許容しているアプリケーションプログラミングインタフェースを提供する場合もあります。 (しかし)これは、この仕様のスコープ外です。 ユーザーは、(この事を)心得ておくべきですが、しかしながら他方で、その変換の為の入力は、[データモデル]で記述したものとしてのXDMデータモデル、オリジナルXML文書、または、DOMの中に存在するかもしれない構築に一致するツリーですが、それは、データモデルのスコープ内ではなく、スタイルシートによって処理される事ができず、変換出力の中で未変更のままにしておく事を保証する事もできないからです。 このような構築は、CDATAセクション境界、実体参照の利用、DOCTYPE宣言と内部DTDサブセットを含みます。

[定義：  頻繁に起こる要求は、XML文書(他のフォーマットの中ではまたはHTMLのような)最終結果ツリーを出力する事です。 このプロセスは、シリアライゼーションとして参照されます。 ]

解析の時、シリアライゼーションは、変換プロセスの一部ではなく、XSLTプロセッサが、シリアライゼーションを実行できなければならないという事は必須ではありません。 しかしながら、実用的な理由において、この仕様は、宣言(xsl:output要素とxsl:character-map宣言：参照 20 シリアライゼーション)、シリアライズされた出力ファイルの要求されたプロパティを記述する為にスタイルシートを許容するxsl:result-document上の属性命令を記述します。 シリアライゼーションが実行されていない時というのは、implementationが、シリアライゼーションオプションをサポートしていない為か、または、ユーザーがシリアライゼーションを実行しない方法で変換を実行してる為かのいずれかであり、その時にはxsl:outputのコンテンツとxsl:character-map宣言は、効果がありません。 これらの状況下では、プロセッサは、xsl:output、または、xsl:character-map宣言、または、xsl:result-document属性のシリアライゼーションの中で、いくつかのエラーを報告する場合がありますが、そうする事は必須ではありません。

2.7 拡張性

XSLTは、条件を満たす事によって、または、仮にユーザーによってその性能を提供する事を選ぶ条件を満たす事によって拡張される為の言語を許容する特性の番号を記述します。 これらの特性は、非常に幅広い可能性やインターオペラビリティを犠牲にする事なく利用できるように設計されています。 この仕様の中で明示的に定義したそれら以外の他の拡張は、許容されません。

これらの特性は、すべてXML名前空間上で基準とされます。；名前空間は、異なる条件(の名前空間)を伴って壊れることなく、(ただ)1つの条件によって提供される拡張を保証する為に利用されます。

たいてい言語を拡張する普通の方法は、XPath式から行使できる付加的な関数を提供する事によるものです。 これらは拡張関数として知られており、18.1 拡張関数に記述されます。

それは、新しい指示命令を提供する事によって言語を拡張する事を許容することでもあります。 これらは、拡張命令として参照され、18.2 拡張命令の中で記述されます。 スタイルシートは、拡張命令の利用を宣言しなければならず、それは、[xsl:]extension-element-prefixes属性を利用するまでそれを行います。

これらの規則と一致するように定義した拡張命令と拡張関数は、XSLTプロセッサの条件を満たす事によって提供される場合があり、条件を満たすには、より一層の拡張命令と拡張関数を生成する事をユーザーに許容する利便性を提供する場合もあります。

この仕様は、拡張命令と拡張関数がどのように実行されるのかを記述しますが、新しい拡張命令と拡張関数を生成する為の利便性は、implementation-definedです。 より一層の詳細については、18 拡張と縮退参照。

XSLT言語は、ユーザー定義データ要素(参照：3.6.2 ユーザー定義データ要素)という意味において拡張属性の利用によって拡張される事も可能(参照：3.3 拡張属性)です。

2.8 スタイルシートとXMLスキーマ

XSLTスタイルシートは、スキーマからの情報を利用させる事が可能です。 XSLT変換は、スキーマ(さらに、実際には、DTD)の不足の中に場所を確保する事が可能ですが、ソース文書は、スキーマ妥当性評価を経ており、XSLTプロセッサは、ただの区分されていないテキストではない個別のノードを結びつけたタイプ情報へのアクセスを持ちます。

スキーマからの情報は、(スタイルシートがコンパイルされた時の)静的なものと、(ソース文書を変換する為のスタイルシートの評価中の)動的なものの両方に利用される事が可能です。

これらは、スタイルシート内とXPath 式内、スタイルシート内のパターンの位置で スキーマの中の名前付きタイプ定義や要素と属性宣言を参照する事を可能にします。 例えば、関数のパラメータにおいて期待されるタイプを宣言する事を可能にします。 これは、SequenceType ^XPを利用して行われます。シンタックスは、[XPath 2.0]で定義されます。

[定義：  タイプ定義と要素と属性宣言は、スキーマコンポーネントとして集積する為に参照されます。 ]

[定義：  スキーマコンポーネントは、スコープ内のスキーマコンポーネントのように参照されるスタイルシート内の名称によって参照される場合があります。 このセットは、全てのスタイルシートのモジュール全体と同じです。 ]

21 一致で定義したXSLT 2.0における一致規則は、基本XSLTプロセッサとスキーマ用XSLTプロセッサを区別します。 名称提案のように基本XSLTプロセッサは、静的、動的問わずスキーマ情報へアクセス要求するXSLTの特性をサポートしません。 基本XSLTプロセッサを伴って作業するスタイルシートは、(それらがスキーマに対して妥当でない)区分されないソース文書を提供したスキーマ用XSLTプロセッサを伴う結果と同様に作成されるでしょう。 しかしながら、もし、スキーマに対して妥当性があるソース文書であれば、その結果は、そのケースとは異なる場合があり、それらは、妥当ではありません。 区分されないデータ上での作業であるいくつかの構築が区分されたデータを伴って失敗する場合があります。 (例えば、区分xs:dateの属性は、substring^FO関数)の引数として利用される事はできず、他の構築は、データタイプ((要素<product price="10.00" discount="2.00"/>が与えられ、もし、属性が、区分xs:decimalを持つ場合には、「true」、しかし、もし、それらが区分されない場合には、「false」を返すであろう式@price gt @discount)に依存する異なる結果を生成する場合があります。)

これらは、区分定義の標準セットであり、それは、常にスタイルシートごとにあるスコープ内スキーマコンポーネントとして利用可能です。 これらは、3.13 ビルトイン(組み込み)タイプの中で定義されます。 ビルトイン(組み込み)タイプのセットは、基本XSLTプロセッサとスキーマ用XSLTプロセッサを違うものにします。

このセクションの残りは、スキーマ用XSLTプロセッサを伴うものに限定して利用可能になる利便性を記述します。

付加的なスキーマコンポーネント(区分宣言、要素宣言と属性宣言)は、スタイルシートの中でxsl:import-schema宣言するという意味でスコープ内スキーマコンポーネントに追加される場合があります。

URIの意味付けによってxsl:import-schema宣言は、外部スキーマ文書を参照する場合があり、またそれは、インラインxs:schema要素を含む場合があります。

もし、スキーマコンポーネントの1つ以上が、スタイルシート内で明示的な名前によって参照される場合には、単に明示的にスキーマを取り込む必要があります； それは、単にスキーマに対して結び付けられているソース文書を処理する為に利用されるスタイルシートに起因してスキーマを取り込む事は必要ではありません。 それは、万一、スタイルシートに取り込まれるべきスキーマがない場合でさえ、スキーマ評価からの情報結果の利用をさせる(例えば、実際に固有の属性[date]を保持する)事を可能にします。

もっといえば、スキーマを取り込む事は、スタイルシートが処理する事を期待されるソース文書のタイプについて言っているのではありません。 取り込まれた区分定義は、一時的なノードの為に、または、ソース文書にあるノードにおいてとちょうど同じように結果ツリー上にあるノードにおいて利用される事が可能です。 それは、スタイルシート内でテストするという意味で入力文書の区分について主張させる事を可能にします。例：

<xsl:template match="document-node(schema-element(my:invoice))" priority="2">
. 
. 
.
</xsl:template>
<xsl:template match="document-node()" priority="1">
	<xsl:message terminate="yes">Source document is not an invoice</xsl:message>
</xsl:template>

スタイルシートによって取り込まれるタイプの1つではないタイプ注釈のノードを含む場合のあるソース文書を利用可能にします。 これは、タイプxs:integerからの制限によって搬送される文脈ノードのタイプ注釈にある名付けられたタイプかどうかを知る事を必要とするシステムxs:integer のインスタンス data(.)のような式のケースの中にあるので潜在的な問題を創出してしまいます。 この情報は、[データモデル]内に定義したかのようにXDMツリー内で明示的に利用できるものではありません。 その手法は、このシチュエーションを伴う扱いにおいていくつかの方策の1つを選ぶ場合があります。：

1. プロセッサは、もし、ソース文書がプロセッサに知られていないタイプ注釈を含む事を発見される場合には、回復されない動的エラーシグナルを出力します。

2. プロセッサは、もし、スキーマ情報を必要とする全てがxsl:import-schemaを利用して取り込まれていたかのように処理される場合には、ソース文書を許容する[データモデル]内に記述した(範囲を)越えて、付加的なメタデータを保持する場合があります。

3. プロセッサは、変換の為の入力として提供される事が可能な以前に、すべてのソース文書を有効にする為に自動的に利用したスキーマの固定したセットを利用する為に設計される場合があります。 このケースでは、ソース文書においてプロセッサが認知していないタイプ注釈を持つ事を可能にします。

4. プロセッサは、もし、実行されていたスキーマ処理がないかのようにソース文書を扱う為に設計される場合には、それは、xs:untypedとxs:untypedAtomicというそれぞれのタイプを持っているかのように代わりにそれらをマーキングする入力上の要素と属性から全てのタイプ注釈を効果的に除去します。

スタイルシート作者がノードのタイプ、または、変数とパラメータのタイプについて主張を述べる事を選ぶときには、それは、スタイルシートの静的な解析を実行する為にXSLTプロセッサにおいて利用可能にします。 (それは、いくつかのソース文書の不足の中で解析します)。 このような解析は、そうでなければ変換が実際に実行されるまでは、発見されないというエラーを示す場合があります。 XSLTプロセッサは、このような静的区分チェックを実行する事は必須ではありません。 いくつかの環境下で(参照先： 2.9 エラー操作)区分エラーは、静的エラー時に報告される場合を素早く見抜かれます。 付加すると手法は、警告のように静的な解析中に発見したいくつかの条件を報告する場合があり、提供したこれは、この仕様によって記述したかのように評価されているスタイルシートを予期しません。

スタイルシートは、また、最終結果ツリー、または、一時的なツリーの中で構築するノードのタイプ注釈を操作する事も可能です。 ？？？これは、方法の番号の中で行われる事が可能です。

• それは、文書ノードでルートにしたツリーである完全な文書の系統だてられた妥当性を要求する事を可能にします。 これは、xsl:document (または、xsl:copy)命令を利用して構築した一時的なツリーとxsl:result-documentを利用して構築した最終結果ツリーにおいてもまた、その両方に適用します。 妥当性検証とは、[XML スキーマ Part 1]に記述したように妥当であるか、または、妥当でないかのいずれかです。 もし、結果ツリーの妥当性検証が失敗する場合(厳密には、妥当性評価の結果がinvalidという場合)には、変換失敗ですが、他の全てのケースでは、ツリーの要素と属性ノードは、これらのノードが一致する名前を伴って表記されるでしょう。 これらタイプ注釈は、もし、結果ツリーがXML文書としてシリアライズされる場合には、破棄されるでしょうが、しかし、結果ツリーが違う処理におけるアプリケーション(おそらくその他のスタイルシート)では通過され、利用可能なまま残るでしょう。

• それはまた、それらが構築されたかのように個別の要素と属性ノードを有効にする事を可能にします。 これは、xsl:element、xsl:attribute、xsl:copy、xsl:copy-of命令のtypeとvalidation属性、または、リテラル結果要素のxsl:typeとxsl:validation属性を利用して行われます。

• 要素、属性、または、文書ノードがコピーされる時、または、明示的なxsl:copyを利用して、または、 xsl:copy-of命令、または、シーケンスにあるノードが、validation="strip"とvalidation="preserve"オプションを利用可能とし、潜在的なタイプ注釈が残されるかどうかを操作する為に新しい親ノードに暗黙のうちに結び付けられる時のいずれかです。

一時的なツリーにあるノードが妥当(有効)であるとき、タイプ情報は、スキーマ評価を経ているソース文書におけるものとして同じ方法で、一時的なツリー上に運び出す操作における利用を可能にします。

要素と属性ノード作業をどのように有効にするかの詳細については、19.2 妥当性参照。

2.9 エラー操作

[定義：  エラーは、実行開始前に静的エラーとして参照されるスタイルシートのテストを実行する事によって回避されます。 (それは、ソース文書とスタイルシートパラメータの値が利用可能となる前です。) ]

この仕様内で静的エラーとして分類されたエラーは、全ての手法によってシグナル出力されなければいけません：それは、プロセッサは、エラーがある事を示さなければならないという事です。 静的エラーは、決して評価されることのないスタイルシートの一部にある出現であったとしてもシグナル出力されなければいけません。 静的エラーは決して回復されません。 静的エラーシグナル出力後、プロセッサは、付加的なエラーシグナル出力の目的の為に継続する場合がありますが、しかし、それは、いかなる最終結果ツリーの生成もなく、結局は変則的に終わらせなければいけません。

スタイルシートが前方互換性動作(参照先：3.9 前方互換性処理)を記述する際にこの規則には例外があります。

一般的に、スタイルシートの構築中にあるエラー、または、スタイルシート内に含まれたXPath式のシンタックス内にあるエラーは、静的エラーとして分類されます。 スタイルシート内にある要素というこの仕様の位置づけは、確実な位置で出現しなければならない、または、出現してはいけない、 または、固有の属性を持っていなければならない、または、持っていてはいけない、 または、その属性が、その他で記述されるまで、この規則が、その時、この規則のいくつかの違反が静的エラーであるという条件記述を満たしている値を持っていなければならない、または、持っていてはいけないかどうかという事です。

[定義：  エラーは、ソース文書が動的エラーとして参照される変換をしている間は、回避されません。 ]

[定義：  いくつかの動的エラーは、回復可能なエラーとして分類されます。 回復可能なエラーが出現する際、この仕様がプロセッサに許容するのは、(エラー状態と終了させる実行を報告するまで)エラーシグナル出力か、または、回復動作と継続処理定義を取るかのいずれかです。 ] それは、implementation-definedが、エラーがシグナル出力されるか、または、動作回復が取られるかどうかという事です。

[定義：  もし、手法が回復可能な動的エラーから修復する事を選ぶ場合には、それは、この仕様の中でエラー条件について定義した付加的な回復動作を取らなければなりません。 ]

手法が、動的エラーシグナル出力と回復処理を選ばせる際には、どのように選ばせるかについて制限されません。；例えば、ユーザーによって設定される事が可能なオプションが提供される場合もあります。 手法が、動的エラーからの回復を選ぶ際には、他の実行に移り、このような警告メッセージを記録する場合もあります。

[定義：  回復可能ではない動的エラーは、回復されない動的エラーとして参照されます。. 回復されない動的エラーが出現する際には、プロセッサは、エラーをシグナル出力しなければならず、変換は失敗します。 ]

異なる手法は、異なる方法でスタイルシートの実行を最適化する場合があるので、動的エラーの回避は、 いくつかのimplementation-dependent段階の為にあります。 固有の構築を評価することなく最終結果ツリーの生成を可能にする手法のケースでは、 その手法は、動的エラーに起因して実行するかどうかを決める為に単独での構築を評価する事を決して要求されません。 例えば、もし、変数が、宣言されているにもかかわらず、全く参照されていない場合には、 変数宣言を評価しないかどうかを選ぶ場合もあれば、変数宣言を評価するとすれば、それは、動的エラーに起因する事を意味し、いくつかの手法は、このエラーをシグナル出力し、他はしないでしょう。

これらは、この仕様が、構築する要求が評価されてはいけないといういくつかのケースです。：例えば、xsl:if命令の内容は、もし、テスト条件が「false」である場合には評価されてはいけないという事です。 これが意味するところは、ある手法が、もし、構築が評価された場合に生じるであろういくつかの動的エラーをシグナル出力してはいけないという事です。

ある手法は、ソース文書が利用可能になる前に動的エラーシグナル出力をする場合もありますが、利用可能なソース文書と利用可能なパラメータ値のセットごとにシグナル出力されるであろうエラーを決定できる場合に限ります。 例えば、いくつかの循環性エラーは、このカテゴリに属します。：参照：9.8 循環性定義。

XPath仕様は、(参照先： セクション 2.3.1 エラーの種類^XP) もし、(いくつかのレベルにおいて)いくつかの式が解析フェーズ中に評価される事が可能な場合には、(その全てが厳密には、オペランド(演算の対象となる数値)が認識されておらず、動的文脈に依存していないので)この評価を実行中のいくつかのエラーは静的エラーとして報告される場合があります。 XSLTスタイルシート内で利用したXPath式においては、しかしながら、いくつかのこのようなエラーは、それらが、そのスタイルシートの可能な評価ごとに出現するまでは、スタイルシート内にある静的エラーとして報告されてはいけません。； 代わりに、それらは、動的エラーとしてシグナル出力されなければならず、XPath式が実際に評価される場合に限ってシグナル出力されます。

<xsl:choose>
	<xsl:when test="system-property('xsl:version') = '1.0'">
		<xsl:value-of select="1 div 0"/>
	</xsl:when>
	<xsl:otherwise>
		<xsl:value-of select="xs:double('INF')"/>
	</xsl:otherwise>
</xsl:choose>

[定義：  明らかなエラーは、type errorsとして分類されます。 区分エラーは、操作において不正な区分で構成する操作における入力として提供した値の出現です、例えば、整数がノードを除外した操作において提供された時など。 ] もし、実際に評価される命令内に区分エラーが出現する場合には、回復されない動的エラーと同じ方法でシグナル出力されなければいけません。 あるいはまた、ある手法では、評価されないスタイルシートの一部に出現する場合であったとしても、決して成功しないであろう固有の構築の実行を確立する事が可能である状態を提供された場合であったとしても、解析フェーズ中に区分エラーを出力する場合もあります。

それは、静的にシグナル出力される区分エラーかどうかというimplementation-definedです。

<xsl:if test="false()">
	<xsl:apply-templates select="42"/>
</xsl:if>

<xsl:template match="para">
	<xsl:param name="p" as="item()"/>
	<xsl:apply-templates select="$p"/>
</xsl:template>

もし、1つ以上のエラーが生じる場合には、それを回避する最初の1つ以外は、手法は、必須ではありません。 それは、シグナル出力されるいくつかのエラーにおけるimplementation-dependentです。 これは、静的エラーにおいても動的エラーにおいても双方に適用します。 ある手法は、1つ以上のエラーをシグナル出力する事を許容されますが、もし、いくつかのエラーがシグナル出力される場合には、仮に変換が成功したものとして終了してはいけません。

動的エラーを1つ以上シグナル出力する際、変換がimplementation-dependentである事によっていくつかの継続するリソースの最終状態は更新されます。 手法は、それらの初期状態におけるこのようなリソースを修復する要求はなされません。 特に、変換が、複数の結果文書を創出する場合、それは、1つ以上のシリアライズした結果文書が、変換が終わる前に成功すると書かれている場合がありますが、アプリケーションは、この振る舞いを当てにする事はできません。

エラー操作について上記で述べている事すべては、XSLT命令を評価中に起こるエラー、XPath式評価中に起こるエラーと同じように適用します。 静的エラーと動的エラーは、双方のケースにおいて出現する場合があります。

[定義：  もし、変換が最終結果ツリー生成に成功したとしてもまだ、エラーは結果ツリーをシリアライズする中で出現する場合という可能性があります。 例えば、そのことは、ユーザーによって選択されたエンコード方式を利用して結果ツリーをシリアライズする事を可能にする場合があります。 このようなエラーは、シリアライゼーションエラーとして参照されます。 ] もし、プロセッサがシリアライゼーションを実行する場合には、20 シリアライゼーションに記述したようにそうしなければならず、固有のそれは、その出現におけるいくつかのシリアライゼーションエラーをシグナル出力しなければいけません。

エラーは、QNameによって識別されます。 この仕様の中で定義したエラーは、QNameの名前空間が、ローカル部分がPPSSNNNNというフォームにある8文字コードである間(それゆえに明示的に与えられない)、常にhttp://www.w3.org/2005/xqt-errorsです。 これには以下のものがあり、PPは、常にXT(XSLTの意)、SSは、SE(静的エラー／静的エラー)、DE(Dynamic Error／動的エラー)、 RE(Recoverable dynamic Error／回復可能なエラー)、または、TE(Type Error／区分エラー)の一つです。 これらのカテゴリの1つにおけるエラーの確保される領域という注釈は、純粋な利便性とエラー操作における方法についての非標準的手法です。 多くのエラーは、例えば、動的または静的のいずれかで報告される事が可能です。

これらのエラーコードは、この仕様でエラー条件を印づける為に利用され、E エラー条件の要約内で要約されます。 それらは、参照の容易さにおいて優先的に提供されます。 手法は、エラーをシグナル出力する際にこれらのコードを利用する場合がありますが、そのようにする為に要求されるわけではありません。 API仕様は、しかしながら、これらのQNameを基準としたエラーコードの利用を要求する場合もあります。 手法(または、アプリケーション)によって定義した付加的なエラーは、干渉のリスクなしで[implementation-defined](または、ユーザー定義)名前空間内でQNameを利用する場合があります。

[XPath 2.0]に定義したエラーと[関数と演算子]仕様は、同じ名前空間の中で似たような構造を持つQNameを利用します。 XPath式を処理する過程でエラーが出現する際には、XSLTプロセッサは、XPathプロセッサによって報告されたオリジナルエラーコードを利用すべきであり、XSLTがより多くの記述をするまでエラーコードは利用可能にします。