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

【Features of the XSLT Language / XSLTの特徴】XSLT 2.0/XSL Transformations Version2.0/Extensible Stylesheet Language Transformations Version2.0

ホーム前へ次へ
XSLTの特徴とは?

【Features of the XSLT Language / XSLTの特徴】XSLT 2.0/XSL Transformations Version2.0/Extensible Stylesheet Language Transformations Version2.0

XSLTの特徴

 W3C勧告XSLTバージョンXSLT 2.0の「Features of the XSLT Language / XSLTの特徴」

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

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

<< 4. データモデル / Data Model

XSLT特徴目次


5 XSLTの特徴 / Features of the XSLT Language
 5.1 適格な名称 Qualified Names
 5.2 表記とパターンにおける接頭辞のないQNames Unprefixed QNames in Expressions and Patterns
 5.3 表記
 5.4 静的な文脈と動的な文脈 The Static and Dynamic Context
  5.4.1 静的な文脈の初期化
  5.4.2 XSLTによって利用される付加的な静的文脈 Additional Static Context Components used by XSLT
  5.4.3 動的な文脈の初期化
   5.4.3.1 位置の保持/フォーカス Maintaining Position: the Focus
   5.4.3.2 動的文脈におけるXPathの他のコンポーネント Other components of the XPath Dynamic Context
  5.4.4 XSLTによって利用される付加的な動的文脈 Additional Dynamic Context Components used by XSLT
 5.5 パターン
  5.5.1 パターン例
  5.5.2 パターン構文論 Syntax of Patterns
  5.5.3 パターンの意味する事
  5.5.4 パターンにおけるエラー
 5.6 属性値テンプレート
 5.7 シーケンスコンストラクタ Sequence Constructors
  5.7.1 複雑な内容の構築 Constructing Complex Content
  5.7.2 単純な内容の構築 Constructing Simple Content
  5.7.3 名前空間の取り決め Namespace Fixup
 5.8 URI参照・URIリファレンス

5. XSLT言語の特性

5.1 適格な名前

スタイルシート定義オブジェクトの名前は、具体的に言うと、 名前付きパラメータモード属性セットキー十進フォーマット変数、 または、 パラメータスタイルシート関数、 名前付き出力定義、または、[XML1.0における名前空間]で定義したようにQNameNamesにおけるシンタックスを利用してQNameとして記述される文字マップです。

[定義:  QNameは、常に(NCName ":")? NCNameという形式で書かれ、それは、ローカル名が、名前空間前置詞によって付加的に優先されるという事です。 2つのQNamesが比較される際には、しかしながら、もし、下のように記述したものとして一致する拡張QNamesが同じである場合には、等価です。 ]

タイプxs:QNameの原子化された値は、QNameとして曖昧な参照をされる事があるので、この仕様はまた、その拡張した形式ではなく、その語彙的な形式でQNameNamesを参照することである用語語彙的なQNameを利用します。 この用語は、語彙的なQNameを含んでいる文字列がrun-time値として巧みに扱われる際に利用されます。

[定義:  語彙的なQNameは、名前空間前置詞によって付加的に優先されるローカル名である形式(NCName ":")? NCNameにあるQNameを表示する文字列です。 ]

[定義:  語彙的なQNameの形式にある文字列は、スタイルシートモジュールにある属性ノードの値として、または、 このような属性ノードに含まれたXPath内で、または、このような属性ノードに含まれたXPath式の評価の結果として現れる場合があります。 この属性ノードを含んでいる要素は、QNameの定義している要素として参照されます。 ]

[定義:  拡張QNameは、換言すると、ローカル名と付加的な名前空間URIの値のペアを含みます。 それは、名前空間前置詞もまた含む場合があります。 もし、名前空間URIが同じ(または、共に不足)で且つ、ローカル名が同じ場合には、2つの拡張QNamesは、等価です。 前置詞は、比較における部分がないようにふるまいますが、拡張QNameが文字列に戻すように変換される必要がある場合に限定して利用されます。 ]

もし、QNameが前置詞を持つ場合には、前置詞は、その定義している要素上の影響の中にある名前空間宣言を利用してURI参照において拡張されます。 拡張QNameは、名前のローカル部分とオブジェクトの名前として利用されるNullが可能なURI参照で構成されています。 定義している要素(参照:セクション 6.2 要素 ノードDM)の既定名前空間は、前置詞のない名前においては、利用されません

前置詞なしQNameを拡張している際に利用される定義している要素の既定名前空間には、3つのケースがあります。:

  1. QNameがある場所は、構築されている要素の名前を定義する為に利用されます。 これは、静的に知られている名前のケース(それは、リテラル結果要素の名前)の為にと動的に評価されるケース(xsl:element命令のname属性の値)の為という両方のケースに適用します。

  2. 既定名前空間は、関数element-availableの最初の引数を拡張している際に利用されます。

  3. 既定名前空間は、 xsl:outputcdata-section-elements属性 または、xsl:result-documentで現れるいくつかの適格でない要素名に提供します。

XPath (参照先: 5.3 式)の中で、信頼できる他の文脈の中でNameTestとして利用した前置詞なしQNameのケースでは、 QNameを拡張している中で利用される為の名前空間は、5.2 式とパターンにある前置詞なしQNameで記述したように[xsl:]xpath-default-namespace属性という意味で記述される場合があります。

[ERR XTSE0280] 前置詞付きQNameが、 スタイルシートにある属性の値として利用した、または、 スタイルシートにあるXPath の中に現れている、 もし、 定義している要素が、QNameの前置詞と一致する名前を持つ存在しない名前空間ノードを持つ、といった場合には、それは、静的エラーです。

[ERR XTDE0290] XPath式 (または、属性値テンプレート)評価中の結果が、語彙的なQNameとする事を要求される場合には、 もし、 語彙的なQNameの前置詞と一致する名前を持つ存在しない名前空間ノードを持つ場合には、他で記述されるまでそれは、回復されない動的エラーです。 もし、式の値が、静的に決められる事が出来る場合には、このエラーは、静的エラーのようにシグナル出力される場合があります

5.2 式とパターンにある前置詞なしQName

属性[xsl:]xpath-default-namespace(参照先: 3.5 標準属性)は、 下に列挙した信頼できる他の文脈にあるXPath式にある前置詞なし要素名 または、タイプ名において利用されるであろう名前空間を定義するスタイルシートにある要素上で利用される場合があります。

属性の値は、利用される為の名前空間URIです。

スタイルシートにあるいくつかの要素においては、 この属性は、 もし、このような属性を記述する含んでいる要素がない場合には、要素上にある[xsl:]xpath-default-namespaceの値である、 または、このような属性を記述する最も内側の含んでいる要素上にある、または、ゼロの長さの文字列である有効な値を持ちます。

スタイルシートにあるいくつかの要素においては、 この属性の有効な値は、(属性値テンプレートにあるXPath式を含んでいる)要素の属性に含まれたいくつかのXPath式の静的な文脈にある要素とタイプ名における既定名前空間の値を決定します。 [XPath 2.0]で記述されたこの効果;要約では、それは、シーケンスタイプ生成物にあるいくつかの前置詞なしタイプ名において、そして且つ、 path式に現れているいくつかの要素名において、または、シーケンスタイプ生成物にある要素名において利用した名前空間を決めます。

この属性の値の効果は、そのスコープ内に現れている次に続く構築のいくつかへの適用ととてもよく似ています:

  • パターンの中で利用したいくつかの前置詞なし要素名、または、タイプ名

  • xsl:strip-space または、xsl:preserve-space命令のelements属性で利用したいくつかの前置詞なし要素名

  • XSLT 要素as属性で利用したいくつかの前置詞なし要素名、または、タイプ名

  • XSLT要素type属性で利用したいくつかの前置詞なしタイプ名

  • リテラル結果要素xsl:type属性で利用したいくつかの前置詞なしタイプ名。

[xsl:]xpath-default-namespace属性は、もし、XSLT名前空間にその親要素が存在しない場合、その場合に限っては、XSLT名前空間に存在しなければいけません

もし、属性の有効な値がゼロの長さの文字列である場合には、もし、ゼロの長さの文字列を明示的にセットする場合には、そのケースになり、 または、もし、全てにおいて記述されない場合には、前置詞なし要素名、または、タイプ名は、存在しない名前空間にある名前を参照するといういずれかです。 親要素(参照先: セクション 6.2 要素 ノードDM)の既定名前空間は、利用されません

属性は、他の名前、例えば、関数名、 変数名、または、 テンプレート名、または、 xsl:elementname属性の有効な値のようなスタイルシート評価中にある語彙的なQNamesとして解釈される文字列、 または、key関数に最初の引数として提供した文字列。。。等々には作用しません。

5.3 式

XSLTは、XPath 2.0 [XPath 2.0]によって定義した言語を式に利用します。 式は、含んでいる目的の多様性におけるXSLTの中で利用されます。:

  • 処理におけるノード選択;

  • ノードを処理する異なる方法における仕様条件;

  • 結果ツリーに挿入される為のテキスト生成。

[定義:  この仕様内では、用語XPath式、または、単にというのは、[XPath 2.0]で定義した生成物ExprXPと一致する文字列という意味です。 ]

XPath式は、XSLT定義要素にある信頼できる属性の値として、そしてまた属性値テンプレートで波カッコ内に現れる場合があります。

利用可能とされる前方互換性動作(参照先: 3.9 前方互換性処理)を除き、 もし、このような属性の値、または、XPath生成物ExprXPと一致しない属性値テンプレートにある波カッコ間にあるテキスト、 または、 もし、スコープ内にある変数を参照しなければならない全ての変数の例においてXPath仕様で定義した他の静的な制約を満たす事に失敗する場合には、 それは、静的エラーです。 エラーコードは、[XPath 2.0]で定義されます。

回復されない動的エラーを伴う変換は、もし、いくつかのXPath が、評価され、動的エラーを主張する場合には、失敗します。 エラーコードは、[XPath 2.0]で定義されます。

タイプエラーを伴う変換は、 もし、XPathがタイプエラーを生じさせる場合、 または、もし、XPathを評価している結果が評価され、タイプエラーを生じさせる場合、 または、もし、XPathプロセッサが、の静的な解析中にタイプエラーをシグナル出力する場合には、失敗します。 エラーコードは、[XPath 2.0]で定義されます。

[定義:  XPath が現れるスタイルシート内の文脈は、式の要求タイプ記述する場合があります。 要求タイプは、式が返す事を期待される値のタイプを示します。 ] もし、式に記述された要求タイプがない場合には、いくつかの値を返す場合があります。:効果がある中では、要求タイプは、その時、item()*です。

[定義:  他で示される場合を除き、の実体値は、関数変換規則を利用して要求タイプに変換されます。 これらは、関数用法表示で定義したように引数の要求タイプを呼ぶ関数の引数を提供した変換における[XPath 2.0]で定義した規則です。 関連する規則は、XPath 1.0互換性モードが、falseに設定される際にそれらを適用します。 ]

この仕様はまた、要求タイプにおけるXSLTシーケンスコンストラクタを評価する結果を変換する為のXPath 2.0 関数変換規則を実行します。 (例えば、xsl:variablexsl:template、または、xsl:function要素に入れるシーケンスコンストラクタ)。

いくつかの動的エラー、または、タイプエラーは、 エラーが式を評価している間に出現したかのように同じ方法で、失敗している変換の中にある結果を要求タイプとして値を変換する為の関数変換規則を適用中に現れます。

注釈:

エラーの2つの種類間の差異が現れる場合があります。整数から日付に変換しようとする試みは、このような変換が決して可能ではないのでタイプエラーです。 タイプエラーは、もし、それらが、論点における構築が、評価される事が可能か否かを静的に見つけられる事が可能であれば、静的に報告される事が可能です。 文字列 2003-02-29 から日付に変換しようとする試みは、その問題は、この固有の値を伴うのであって、そのタイプを伴うものではないのでタイプエラーではなく、動的エラーです。 動的エラーは、もし、命令、または、式が、それらが実体評価される要因となる場合に限り、報告されます。

5.4 静的文脈と動的文脈

XPathは、を評価する結果に作用する事が可能な全ての情報を含む式文脈XPのコンセプトを定義します。 式文脈は、静的文脈XP動的文脈XPの2つの部分があります。 式文脈が作り上げたコンポーネントは、XPath 仕様 (参照先: セクション 2.1 式文脈XP)で定義されます。 このセクションは、XPath式が、XSLTスタイルシート内に含まれる際に、これらのコンポーネントが初期化される中で方法を記述します。

XPath仕様で定義した静的文脈と動的文脈コンポーネントにおいて提供している値同様、XSLTは、それ自身の付加的な文脈コンポーネントを定義します。 これらの文脈コンポーネントは、XSLT命令によって、 (例えば、xsl:next-matchxsl:apply-imports)、 そしてまた、この仕様で記述した拡張関数ライブラリにある関数によって利用されます。

次に続く4つのセクション記述:

5.4.1 静的文脈を初期化する
5.4.2 XSLTで利用した付加的な静的文脈コンポーネント
5.4.3 動的文脈を初期化する
5.4.4 XSLTで利用した付加的な動的文脈コンポーネント

5.4.1 静的文脈を初期化する

XSLTスタイルシートに現れているXPath式の静的文脈XPは、次に続くように初期化されます。 これらの規則では、スタイルシートに含んでいる要素という意味である用語 including要素は、論点にあるXPath式、要素も含んでいるという意味の用語 enclosing要素、または、いくつかのその先祖での構成を含む値を持つ属性の親です。

5.4.2 XSLTによって利用した付加的な静的文脈コンポーネント

XPath静的文脈のコンポーネントのいくつかは、XSLT 要素によってもまた利用されます。 例えば、xsl:sort要素は、 静的文脈で定義した照合の利用をさせ、typeas のような属性は、スコープ内スキーマコンポーネントの中で定義したタイプを参照する場合があります。

スタイルシートにある多くのトップレベル宣言とxsl:stylesheet要素上の属性は、 スタイルシートにある命令の振る舞いに作用します。 これらの構築のそれぞれは、この仕様の中のその妥当な位置に記述されます。

これらの構築の番号は、スタイルシートにあるXPath式において利用する為に可能となる関数のライブラリに追加されるXSLTで定義した関数によって利用されるので固有の用法表示を構成します。 これらは、(以下の通りです):

  • key 関数によって利用した名前付きキーのセット

  • format-number 関数によって利用した名前付き十進フォーマット

  • system-property 関数によって利用したシステムプロパティの値

  • element-available 関数によって利用した利用可能な命令のセット

5.4.3 動的文脈を初期化する

利便性の為に、動的文脈は、2つの部分で記述されます:focus/フォーカスは、 現時点で処理されているソース文書にある位置を提示し、そして付加的な文脈変数を照合します。

もし、それらが、同じ引数を伴う同じ実行スコープFOである間に2回呼ばれる場合にはという意味でstable/共通の目的FOとなるように定義される[関数と演算子]で記述した関数の番号は、 それらが、同じ結果(参照:セクション 1.7 専門用語FO)を返します。 XSLTでは、スタイルシートの実行は、実行スコープを定義します。 これが意味するところは、例えば、もし、その時々で同じ結果を創出する変換中に関数 current-dateTimeFOが、繰り返して呼ばれる場合という事です。 手法によっては、これらの関数依存上の動的文脈は、変換の期間における共通の目的でもあります。 具体的に言うと、次に続くセクション 2.1.2 動的文脈XPで定義したコンポーネントは、共通の目的にしなければいけません: 関数手法現在の日付時刻暗黙のタイムゾーン利用可能な文書利用可能なコレクション既定照合。 グローバル変数とスタイルシートパラメータの値は、変換の期間における共通の目的でもあります。 focus/フォーカスは、共通の目的ではないものです;5.4.4 XSLTによって利用した付加的な動的文脈コンポーネントで定義した付加的な動的文脈コンポーネントもまた、共通の目的ではないものです。

[関数と演算子]で記述したように、手法は、docFO と 共通の目的結果を返すためのcollectionFO 関数 (そして一方で手法によっては、document 関数)における要求を緩和するユーザーオプションを提供する場合があります。 既定によっては、しかしながら、関数は、共通の目的にしなければいけません。 このようなユーザーオプションが提供される場合におけるマナーは、全てにおいてimplementation-definedです。

[xsl:]use-when 属性に含んだXPath式は、上で定義したように「変換の期間」を評価される為には考慮されません。 詳細については、3.12 条件付き要素含有 参照。

5.4.3.1 位置を保持する:Focus/フォーカス

[定義:  シーケンスコンストラクタが評価される際、 プロセッサは、focusとしての集積を参照する厳密な変数のセットという意味で処理されているアイテムのトラックを保持します。 ] より具体的に言うと、フォーカスは次に続く3つの値で構成します。:

  • [定義:  文脈アイテムは、現時点で処理されているアイテムです。 アイテム(参照:[データモデル])は、(整数、日付、または、文字列のような)原子化された値 、または、ノードのいずれかです。 文脈アイテムは、まず、変換(参照:2.3 変換初期化)が実行される際に提供した初期文脈ノードを設定します。 それは、xsl:apply-templatesxsl:for-eachのような命令が、 アイテムのシーケンスを処理する事によって利用されるかどうかを部分修正します; このようなシーケンスにある各アイテムは、アイテムが処理されている間、文脈アイテムとなります。 ] 文脈アイテムは、XPath . (dot)によって返されます。

  • [定義:  文脈位置は、現時点で処理されているアイテムのシーケンスにある文脈アイテムの位置です。 それは、文脈アイテムが変化するかどうかの変更点です。 xsl:apply-templates、または、xsl:for-eachのような命令がアイテムのシーケンスを処理する為に利用される際には、 シーケンス中の1の文脈位置を持つ最初のアイテム、次に2の文脈位置。。。のように処理されます。 ] 文脈位置は、XPath position()によって返されます。

  • [定義:  文脈サイズは、現時点で処理されているアイテムのシーケンスにあるアイテムの番号です。 それは、xsl:apply-templatesxsl:for-each のような命令が、アイテムのシーケンスを処理する為に利用されるかどうかの変更点です; それらのアイテムの個々の処理の間、文脈サイズは、シーケンスにあるアイテムの番号をカウントする為(または、シーケンス中のアイテムの最後の位置と等価(であるかを確認する為に))に設定されます。 ] 文脈サイズは、XPath last() によって返されます。

[定義:  もし、文脈アイテムが、(整数のような原子化された値から見つけられるような)ノードである場合には、 文脈ノードとしても参照されます。 文脈ノードは、独立した変数ではなく、それは、文脈アイテムが変化したか否かの変更点です。 文脈アイテムが、原子化された値であるときには、文脈ノードはありません。 ] 文脈ノードは、XPath self::node() によって返され、そして、それは、全ての関連path式における開始ノードのように利用されます。

XPath式の要素を含んでいる場合には、指示命令、または、リテラル結果要素、 XPath における初期の文脈アイテム、 文脈位置、文脈サイズは、命令の評価、または、リテラル結果要素においての文脈アイテム文脈位置文脈サイズ と同じです。

他のケース(例えば、要素が、xsl:sortxsl:with-param、または、xsl:keyを含んでいる場合) では、規則は、含んでいる要素の仕様の中で与えられます。

current 関数は、XSLTプロセッサによってXPath式 に文脈アイテムを提供したものとしてあったアイテムを選択する為のいくつかの XPath の中で利用される事が可能です。 . (dot)とは異なり、これは、XPath式内に現れる文脈アイテムにおける変更によって影響されません。 current 関数は、16.6.1 Current/カレントで記述されます。

(xsl:apply-templates、または、xsl:for-eachのような)focusを変更する命令の完了においては、フォーカスは、その前の値に戻ります。

スタイルシート関数が呼ばれる際に関数の本体にあるフォーカスは、初期値未定義です。 フォーカスは、もし、提供される初期文脈ノードが存在しない場合には、スタイルシートへの初期登録についても、未定義とされます。

フォーカスが未定義とされるとき、いくつかのの評価は、回復されない動的エラー [XPDY0002]にある文脈アイテム、文脈位置、または、文脈サイズ結果を参照します。

上記説明は、focus作業の方法のアウトラインを与えます。 各命令の作用における詳細規則は、その命令の説明を伴う個々に与えます。 特別規則の欠如では、命令は、その親命令としてのフォーカスと同じように利用します。

[定義:  ノード N上を基準にした 個々のフォーカス/focus は、 (それゆえに文脈ノード)が、Nに設定され、 更に 文脈位置文脈サイズ の双方は、「1」に設定される文脈アイテムを持ちます。 ]

5.4.3.2 XPath 動的文脈の他のコンポーネント

前のセクションでは、XSLTスタイルシートに現れるXPath式においてfocusが、どのように初期化されるかを説明しました。 このセクションでは、XPath式の動的文脈XPの他のコンポーネントが、どのように初期化されるかを説明します。

  • 動的変数XPは、 スコープ内可変結合要素の現時点の値です。

  • 現在日付と現在時刻は、変換の処理中にある位置をimplementation-dependentに提示します;それは、変換の進行中には、変更されません。

  • 暗黙のタイムゾーンXPは、implementation-definedです。

  • 利用可能な文書XP利用可能なコレクションXPは、変換を初期化する為のプロセスの一部として決められます。(参照:2.3 変換初期化)。

    利用可能な文書XPは、docFO関数をサポートする為のXPath 2.0 動的文脈の一部として定義されますが、一方、このコンポーネントは、とてもよく似ているXSLT document 関数によってもまた参照されます:16.1 複数のソース文書参照 。 この変数は、docFO、または、 document 関数を通過したURI間におけるマッピングを定義し、そして文書ノードが返されます。

    注釈:

    評価文脈の一部としてこれを定義する事は、仕様の公式な方法であり、URIが文書ノードについて取り戻す方法における言語仕様の操作を外に出し、 そして変換が位置を受け取る事については、ランタイム環境に完全に依存します。

    XSLT定義document関数は、フラグメント識別子を含んでいるURI参照の利用を許容します。 フラグメント識別子の解釈は、リソース表示のメディアタイプに依存します。 それゆえにXSLT処理における利用可能な文書XP内で提供した情報は、 XPathによって要求したかのようにURIから文書ノードにマッピングし、一方で、URIからメディアタイプへのマッピングも含め、これらに限定せずに提供しなければいけません。

  • 既定コレクションXPは、implementation-definedです。 これは、欠如しているシーケンスにする為の既定コレクションを設定するようなオプションを許容するか、または、未定義となります。

5.4.4 XSLTによって利用した付加的な動的文脈コンポーネント

追記すると、focus/フォーカスを作り上げる値において、XSLTプロセッサは、評価文脈の局面に影響する他の動的文脈コンポーネントの番号を保持します。 これらのコンポーネントは、それらの保持と利用仕様のセクションの中で完全に記述されます。 それらは(以下のようになります):

次に続く非標準テーブル要約は、評価文脈にあるコンポーネントごとの初期状態と変更するコンポーネントの状態に起因する命令についてです。

コンポーネント 初期設定 設定要因 消滅要因
focus/フォーカス 仮に提供した初期文脈ノードを基準とした singleton focus xsl:apply-templatesxsl:for-eachxsl:for-each-groupxsl:analyze-string スタイルシート関数を呼ぶ
カレントテンプレート規則 もし、名前付きテンプレートが、変換における入力位置として提供される場合には、Null; それ以外は、初期テンプレート xsl:apply-templatesxsl:apply-importsxsl:next-match xsl:for-eachxsl:for-each-groupxsl:analyze-string、 そしてスタイルシート関数を呼ぶ。
また、グローバル変数評価中にクリアした、または、スタイルシートパラメータの既定値、そしてxsl:keyxsl:sort に含まれたそのシーケンスコンストラクタ。
カレントモード 初期モード xsl:apply-templates スタイルシート関数を呼ぶ
カレントグループ カラのシーケンス xsl:for-each-group スタイルシート関数を呼ぶ
current グループ化 key カラのシーケンス xsl:for-each-group スタイルシート関数を呼ぶ
現在取得した部分文字列 カラのシーケンス xsl:matching-substring xsl:non-matching-substringスタイルシート関数を呼ぶ
出力状態 最終出力状態 xsl:variablexsl:attribute。。。等々のような命令によって、更にスタイルシート関数を呼ぶことによって一時的な出力状態を設定する なし

5.5 パターン

テンプレート規則は、パターンという意味を適用する為のノードを識別します。 テンプレート規則の中で利用しているのと同様で、 パターンは、番号付けにおいて(参照先: 12 Numbering)、 グループ化において(参照先: 14 グループ化)、 と宣言している keys において(参照:16.3 キー)利用されます。

[定義:  pattern は、ノード上に条件のセットを記述します。 ノードは、パターンと一致する条件を記述します;ノードは、パターンと一致しない条件を満たしません。 パターンにおけるシンタックスは、におけるシンタックスのサブセットです。 ] 以下の詳細で記述したようにノードは、もし、ノードが、等価な式を得る、またいくつかの利用可能な文脈に関連してこの式を評価する事によって選択される事が可能な場合には、パターンと一致します。

5.5.1 パターンの例
例:パターン

いくつかのパターンの例があります:

  • para は、いくつかの para 要素とマッチ。

  • * は、いくつかの要素とマッチ。

  • chapter|appendixは、 いくつかの chapter 要素 といくつかの appendix 要素とマッチ。

  • olist/entry は、いくつかの 親 olist を持つ entry 要素 とマッチ。

  • appendix//para は、 いくつかの appendix 先祖要素を持つ para 要素とマッチ。

  • schema-element(us:address) は、名前が、 us:address か、または、その部分文字列グループにあるその他の要素の名前のいずれかである us:address スキーマ要素宣言によって定義したタイプのインスタンスとして表記されるいくつかの要素とマッチ。

  • attribute(*, xs:date) は、タイプ xs:date となるように表記したいくつかの属性とマッチ。

  • / は、文書ノードとマッチ。

  • document-node() は、文書ノードとマッチ。

  • document-node(schema-element(my:invoice)) は、my:invoice と名前付けされる文書要素のある文書の文書ノードとマッチ、 また、 定義したグローバル要素宣言 my:invoice によって定義したタイプとマッチ。

  • text() は、いくつかのテキストノードとマッチ。

  • node() は、属性ノード、名前空間ノード、または、文書ノードではない、いくつかのノードにマッチ。

  • id("W33") は、一意のID W33 を持つ要素とマッチ。

  • para[1] は、その親の最初の para 子要素であるいくつかの para 要素とマッチ。 それはまた、親のない para 要素とマッチ。

  • //para は、親ノードを持つ、いくつかの para 要素とマッチ。

  • bullet[position() mod 2 = 0] は、偶数番号付けされた、その親の子 bullet であるいくつかの bullet 要素とマッチ。

  • div[@class="appendix"]//p は、値 appendix を伴う class 属性持つ div 先祖要素を伴う、いくつかの p 要素とマッチ。

  • @class は、いくつかの class 属性とマッチ (いかなる要素でもないものは、class 属性を持つ)。

  • @* は、いくつかの属性ノードとマッチ。

5.5.2 パターンのシンタックス

[ERR XTSE0340] パターンを含む事を定義した属性がある場合に、 もし、そのパターンが、パターン生成物と一致しない場合には、静的エラーです。 それぞれのパターンは、認められたXPath ですが、その(機械上の)会話(の結果)は、「true」ではありません。: 2+2 は、パターンではない認められたXPath式の例です。 パターンとして利用される事が可能なXPath式は、それらが以下に与えられるパターンにおける文法と一致します。

非公式には、パターンは、 child、または、 attribute 軸(axis)に限定した利用である AxisStepXP にする為に制約される path 式にあるステップごとの | によって分割した path 式のセットです。 パターンはまた、 // 演算子を利用する場合があります。 パターン内のPredicateListXPにあるPredicateXPは、 path 式にあるpredicateXPと同じ方法で任意のXPath式 (閉じた角ブラケット間)を含む事が可能です。

パターンは、リテラルか、または、変数、 または、文字列リテラルとして提供されるパラメータと(key 関数の場合には)キー名を参照するか、 のいずれかとして提供される一致した値を提供した idFO、 または、 key 関数呼び出しを伴って始まる場合があります。 これらのパターンは、文書ノードではないルートであるツリーにあるノードと決して一致しないでしょう。

もし、パターンが、後方互換性挙動 (参照先: 3.8 後方互換性処理)が利用可能にされるスタイルシートの一部に現れる場合には、 パターンのセマンティクスは、「true」に設定するXPath 1.0互換性モードを伴い評価されるXPath式と等価である基準上で定義されます。

パターン
[1]    Pattern    ::=    PathPattern
| Pattern '|' PathPattern
[2]    PathPattern    ::=    RelativePathPattern
| '/' RelativePathPattern?
| '//' RelativePathPattern
| IdKeyPattern (('/' | '//') RelativePathPattern)?
[3]    RelativePathPattern    ::=    PatternStep (('/' | '//') RelativePathPattern)?
[4]    PatternStep    ::=    PatternAxis? NodeTest XP PredicateListXP
[5]    PatternAxis    ::=    ('child' '::' | 'attribute' '::' | '@')
[6]    IdKeyPattern    ::=    'id' '(' IdValue ')'
| 'key' '(' StringLiteralXP ',' KeyValue ')'
[7]    IdValue    ::=    StringLiteralXP | VarRef XP
[8]    KeyValue    ::=    Literal XP | VarRef XP

その構築 NodeTestXPPredicateListXPVarRefXPLiteralXPStringLiteralXP は、 XPath式言語の一部であり、[XPath 2.0]で定義されます。

5.5.3 パターンの意味する事

パターンの意味する事は、公式には次のように定義されます。

まず、私たちは、等価式のコンセプトを定義します。 一般に、等価式は、書かれているものとしてのパターンと同じ語彙的なフォームを受け取るXPath式です。 しかしながら、もし、パターンが、 RelativePathPattern である PathPattern を含む場合には、 最初の PatternStep は、次に続く親のない要素、または、属性ノードと一致する事を許容するように調整されるこの RelativePathPatternPSです。:

  • もし、 PS にある NodeTest が、(付加的に引数を伴う) document-node() で、 そして、もし、記述される厳密な軸(axis)が存在しない場合には、 ステップ PS にある軸(axis)は、 child ではなく、 self として受け取られます。

  • もし、 PS が、子である(明示的に、または、暗黙のうちに)軸(axis)を利用する場合、 そして、もし、 PS にある NodeTest が、(付加的に引数を伴う) document-node() でない場合には、 ステップ PS にある軸(axis)は、次に続くように定義される child-or-top によって置き換えられます。 もし、文脈ノードが、親のない要素、コメント、処理命令、または、テキストノードである場合には、 child-or-top 軸(axis)は、文脈ノードを選びます;その他のものは、それは、文脈ノードの子を選びます。 それは、主要なノード種別のある前方軸(axis)です。

  • もし、 PS が、属性軸(axis)を利用する場合には、ステップ PS にある軸(axis)は、次に続くように定義される attribute-or-top によって置き換えられます。 もし、文脈ノードが、親のないものを伴う属性ノードである場合には、 attribute-or-top 軸(axis)は、文脈ノードを選びます;その他のものは、文脈ノードの属性を選びます。 それは、主要なノード種別が属性である前方軸(axis)です。

軸(axis) child-or-topattribute-or-top が定義上の目的においてのみ紹介されます。 それらは、ユーザーが記述したパターン、または式の中で明示的に利用される事はできません。

注釈:

これらの調整の目的は、それがもし、親を持たない場合でさえ、いくつかの要素名付き person と一致する person のようなパターンを確保する事です。; そしてとてもよく似た、パターン @width は、親なし属性でさえ、いくつかの属性名付き width と一致します。 規則はまた、 document-node(...) が、文書ノードと一致するフォームの NodeTest を利用してもパターンを確保します。 パターン node() は、それが親を持つか否かで、いくつかの要素、 テキストノード、コメント、または、処理命令と一致するでしょう。 後方互換性根拠において、厳密な軸(axis)なしで利用した際には、パターン node() は、文書ノード、属性ノード、または、名前空間ノードと一致しません。 規則はまた、もし、それらがそれを持つ場合には、それらの親に関連するノードのカウントを継続するフォーム para[1] の位置パターンを確保する事もまた表現されます。

等価式は、 EE になるこれらの規則に一致する計算をさせました。

ノード N がパターンと一致するかどうかを決める事は、 N を基準とした 1つのfocus を伴う root(.)//(EE) を評価します。 もし、その結果が、 N を含むノードのシーケンスであれば、 ノード N は、パターンと一致します;その他のものは、ノード N は、パターンと一致しません。

例:パターンのセマンティクス

パターン p は、いくつかの p 要素と一致します、なぜなら、 p 要素は、常に、 root(.)//(child-or-top::p) の評価結果で提示されるからです。 とてもよく似た / は、文書 ノードと、そしてまさに文書ノードにだけ、一致します、なぜなら、もし、仮にそれが文書ノードである場合に限られる場合には、文脈ノードを含んでいるツリーのルートノードを返す root(.)//(/) の結果だからです。

パターン node() は、要素、テキスト、コメント、処理命令ノード全てが、親を持つか否かである式 root(.)//(child-or-top::node()) によって選択した全てのノードと一致します。 それは、その式が、属性を利用してノードを選択していない、または、名前空間軸(axis)であるといった場合には、属性または、名前空間ノードと一致しないという事です。 後方互換性根拠においては、 child-or-top 軸(axis)は、文書ノードと一致しないので、それは、文書ノードと一致しないという事です。

だけれども、パターンのセマンティクスは、式評価の用語の中に公式に記述され、それは、異なるモデルを利用して一致しているパターンを認識する事が可能となっています。 パターンでは、 | は、 代替手段を示しています。; 1つ以上の | を伴うパターンは、もし、いくつかの代替手段が一致するものがあれば、分割した代替手段が一致します。 book/chapter/section のようなパターンは、右から左へ審査される事ができます。 ノードは、もし、それが、 section 要素であれば、このパターンとだけ一致します。; そしてその時、もし、その親が、 chapter であれば、このパターンとだけ一致します。;その時、もし、book である chapter の親であれば、このパターンとだけ一致します。 パターンが、 // 演算子を利用するとき、それは、その親ではなく、ノードの先祖をテスト中のその時に、右から左へフォームをまだ読む事が可能です。 例えば、 appendix//section は、先祖 appendix 要素を持つ section 要素ごとに一致します。

公式な定義は、しかしながら、 para[1] のようなパターンの意味する事を理解する為に有益です。 これは、式 root(.)//(child-or-top::para[1]) によって選択したいくつかのノードと一致します: それは、いくつかの para 要素は、その親の子である paraまたは、親が存在しないものを持つ para 要素という事です。

注釈:

ある手法は、当然のことながら、いくつかのアルゴリズムを利用する場合があり、それは、上記の公式な定義との一致する結果として非常に長いパターンを評価する事が望まれます。 ある手法は、等価式を評価する事によって公式定義に続き、そして、その時、結果にあるノード仕様の資格テスト中は、おそらく、余りにも効果のないものになるでしょう。

5.5.4 パターンにあるエラー

固有のノードに対してパターンの評価をしている最中に現れるいくつかの動的エラー、または、タイプエラーは、 仮にそのエラーが他の要因下での修復ではない時でさえ、回復可能なエラーとして扱われます。 付加的な回復動作は、一致しているのが、そのノードではないものとしてパターンを扱うようにします。

注釈:

この条項がある理由は、実際に評価されるであろうパターンにある述語(predicate)が実際に評価されるかどうかを予測する事はスタイルシート作者にとって難しくなるからです。 テンプレート規則にあるパターンと一致するケースでは、それは、固有のノードに対して評価されるであろうパターンを予報する事を可能にする事とは同じではありません。 パターン修復の中でエラーを創り出す事は、ある手法を可能にします。もし、それが、そうする事を選ぶ場合には、「スタイルシートは、(未だ)開発下にあります。」、もし、それらが、製品として走っている(既に出荷されている)間に現れる場合には、「マスキング中です。」のようなエラーを報告する事です。

ある固有の最適化は、この仕様によって要求されます: PathPattern においては、/、または、 //、または、IdKeyPatternではじまり、 ルートが、文書ノードではないツリーにあるノードに対してのこのパターンのテスト結果は、動的エラーではなく、一致するものがないとしなければいけません。 この規則は、パターンにある PathPattern ごとに提供します。

注釈:

上記規則がない場合、もし、スタイルシートが、 match="/" を記述しているテンプレート規則を持つ場合には、 親のない要素ノードにテンプレートを適用するようにするいくつかの試みは、動的エラーのリスクを創り出すでしょう。

5.6 属性値テンプレート

[定義:  リテラル結果要素の属性のような属性値テンプレートとして設計される属性では、 は、波カッコ ({}) を伴い、式を囲む事によって利用される事が可能です。 ]

属性値テンプレートは、固定部分と可変部分の交互のシーケンスで構成します。 可変部分は、波カッコ ({}) で囲ったXPath で構成します。 固定部分は、左波カッコが、 {{ のように書かれなければならず、右波カッコが、 }} のように書かれなければならない場合を除き、いくつかの文字列を含む場合があります。

注釈:

可変部分にある式は、StringLiteralXP 内で、または、コメント内でエスケープされない波カッコを含む場合があります。

[ERR XTSE0350] もし、エスケープされない左波カッコが、一致する右波カッコなしで属性値テンプレートの固定部分に現れる場合には、それは、静的エラーです。

もし、属性値テンプレートにある一致する波カッコ間に含んだ文字列が、XPath 生成物 ExprXP と一致しない場合、 または、 もし、他のXPath静的エラーを含む場合には、それは、静的エラーです。 エラーは、妥当なXPathエラーコードを利用するシグナルが出力されます。

[ERR XTSE0370] もし、エスケープされない右波カッコが、属性値テンプレートの固定部に現れる場合には、それは、静的エラーです。

[定義:  属性値テンプレートを評価する結果は、その属性の 有効な値 として参照されます。 ] その有効な値は、固定部分と可変部分の拡張を結合する事によって含まれた文字列です:

  • 固定部分の拡張は、一重の波カッコと一致する事によって、いくつかの二重波カッコ ({{、または、 }}) に置き換える事によって含まれます。

  • 可変部分の拡張は、囲んだXPath を評価する事によって含まれ、文字列へ結果値を変換します。 この変換は、5.7.2 単純なコンテンツを構築するで与えられる規則を利用して行われます。

注釈:

このプロセスは、動的エラーを生成する事が可能です、例えば、もし、シーケンスが、(原子化される事が不可能な)複雑なコンテンツタイプを伴う要素を含む場合など。

もし、 後方互換性挙動が、属性において利用可能となる場合には、文字列へ式の値を変換する事における規則は、次に続くように意味を限定します。 (atomizing後) 式の結果は、結果シーケンスにある最初のアイテムではなく、すべてのアイテムは、破棄し、その有効な値は、文字列におけるシーケンスの中にある最初のアイテムに変換する事によって含まれます。 もし、原子化されたシーケンスがカラである場合には、結果は、ゼロの長さの文字列です。

波カッコは、属性が、具体的に言うと、属性値テンプレートを許容するものとして設計された属性が、;要素シンタックス要約の中では、このような属性の値が、波カッコによって囲まれるまで、XSLT スタイルシートの中にある属性値で特別には扱われません。

注釈:

属性全てが属性値テンプレートとして設計されるわけではありません。 値が、、または、パターンである属性は、 名前付きXSLTオブジェクトを参照する宣言の属性と要素の属性は、 一般には、属性値テンプレートとして設計されません。(例外は、xsl:result-documentformat 属性です)。 名前空間宣言は、XDM 属性ノードではなく、そして、それゆえに、決して属性値テンプレートとしては扱われません。

例:属性値テンプレート

次に続く例は、ソースにある photograph 要素から img 結果要素を創出します; src 属性と width 属性の値は、属性値テンプレートに囲まれたXPath式を利用して算出されます。:

<xsl:variable name="image-dir" select="'/images'"/>
<xsl:template match="photograph">
	<img src="{$image-dir}/{href}" width="{size/@width}"/>
</xsl:template>

このソースを伴う

<photograph>
	<href>headquarters.jpg</href>
	<size width="300"/>
</photograph>

その結果は、(以下のように)なるでしょう

<img src="/images/headquarters.jpg" width="300"/>

 

例:スペースで区切られたリスト生成

次に続く例は、シーケンスにある値が、どのようにスペースで区切られたリストとして出力されるのかを示します。 次に続くリテラル結果要素:

<temperature readings="{10.32, 5.50, 8.31}"/>

出力ノード生成:

<temperature readings="10.32 5.5 8.31"/>

波カッコは、内側の式を再帰的に認識しません

例:波カッコは、ネストされる事ができない

例えば、:

<a href="#{id({@ref})/title}">

は、許容され ません。代わりに、シンプルに利用します:

<a href="#{id(@ref)/title}">

5.7 シーケンスコンストラクタ

[定義:  シーケンスコンストラクタは、スタイルシートにあるゼロ以上の氏族ノードのシーケンスであり、それは、ノードと原子化された値のシーケンスを返す為に評価される事が可能です。 結果シーケンス方法は、含んでいる命令に依存して利用されます。 ]

多くのXSLT 要素とそしてまた リテラル結果要素は、それらのコンテンツとしてシーケンスコンストラクタを受け取る為に定義されます。

ノードの4つの種類は、シーケンスコンストラクタの中で直面させられる場合があります。:

  • スタイルシート内に現れているテキストノードは、 (もし、それらがホワイトスペース除去のプロセスの中で削除されていない場合には、:4.2 スタイルシートからのホワイトスペース除去参照) 結果シーケンスにある新しい親のないテキストノードを創出する為にコピーされます。

  • リテラル結果要素は、リテラル結果要素として同じ拡張QNameを持っている新しい親のない要素ノードを創出する為に評価され、 結果シーケンスに追加されます。:11.1 リテラル結果要素参照

  • XSLT 命令は、それらの結果としてゼロか1つ以上のアイテムのシーケンスを創出します。 これらのアイテムは、結果シーケンスに追加されます。 たいていのXSLT命令においては、これらのアイテムは、ノードですが、 いくつかの命令 (xsl:sequencexsl:copy-of)は、原子化された値を創出する事も可能です。 いくつかの命令は、 xsl:element のように(その自身の属性、名前空間、子、他の子孫を持っている場合がある)新たに構築した親のないノードを返します。 他の命令は、 xsl:if のように、それら自身ネストしたシーケンスコンストラクタによって創出されるアイテムを与えます。 xsl:sequence 命令は、原子化された値、または、存在しているノードを返す場合があります。

  • 拡張命令 (参照先: 18.2 拡張命令)はまた、それらの結果としてアイテムのシーケンスを創出します。 このシーケンスにあるアイテムは、結果シーケンスに追加されます。

シーケンスコンストラクタの結果が、利用される場合には、いくつかの方法があります。

  • シーケンスは、XPath式による任意の方法で巧みに扱われる為に値として利用可能とするケースにおいては、変数、またはスタイルシート関数から返した変数に縛られる場合があります。 シーケンスは、この命令が、 as 属性を持っている時に、 xsl:variablexsl:param 、または、 xsl:with-param という要素の1つの中にシーケンスコンストラクタが現れる際に、きっと変数に縛られます。 シーケンスは、シーケンスコンストラクタが、 xsl:function 要素内に現れる際に、スタイルシート関数から返されます。

    注釈:

    これは、概して、結果ツリーにある親ノードにまだ結び付けられていないスタイルシート要素、 属性、他のノードにさらけ出す事になります。 親のないノードに適用される際のXPath式のセマンティクスは、妥当に定義されたものです。;しかしながら、このような式は、注意を持って利用されるべきです。 例えば、式 / は、もし、含んでいるツリーのルートが文書ノードではない文脈ノードである場合には、タイプエラーの原因になります。

    親のない属性ノードは、それらと結び付けた名前空間ノードがないので、格別の注意深さを要求します。 親のない属性ノードは、名前空間URIを解決させる為の前置詞を利用可能にしている情報が存在しないのでコンテンツ(例えば、QName、または、XPath式)をnamespace-sensitiveに含める事を許容されません。 親のない属性は、アプリケーションの中で利用する事が可能ですが、それらは注意深く操作される事を必要とします。 (例えば、それらが、属性セットの利用の為に代替手段を提供する等:10.2 名前付き属性セット参照)

  • シーケンスは、含んでいる要素の結果として返される場合があります。 これは、シーケンスコンストラクタを含んでいる命令が、 xsl:analyze-stringxsl:apply-importsxsl:apply-templatesxsl:call-templatexsl:choosexsl:fallbackxsl:for-eachxsl:for-each-groupxsl:ifxsl:matching-substringxsl:next-matchxsl:non-matching-substringxsl:otherwisexsl:perform-sortxsl:sequence 、または、 xsl:when である時に発生します。

  • シーケンスは、新しい要素、または、文書ノードのコンテンツを構築する為に利用される場合があります。 これは、シーケンスコンストラクタが、リテラル結果要素のコンテンツとして現れるとき、または、 命令の1つが、 xsl:copyxsl:elementxsl:documentxsl:result-document または、 xsl:message である時に発生します。

    それはまた、この命令が、 as 属性を持っていない場合にシーケンスコンストラクタが、 xsl:variablexsl:param 、 または、 xsl:with-param という要素の1つの中に含まれている場合に発生します。 詳細については、5.7.1 複雑なコンテンツを構築する参照。

  • シーケンスは、属性ノード、テキストノード、名前空間ノード、コメントノード、または、処理命令ノードのstring 値を構築する為に利用される場合があります。 これは、シーケンスコンストラクタが、 xsl:attributexsl:value-ofxsl:namespacexsl:comment 、または、 xsl:processing-instruction という要素の1つの中に含まれている場合に発生します。 詳細については、5.7.2 単純なコンテンツを構築する参照。

注釈:

用語 シーケンスコンストラクタ は、XSLT 1.0で利用したように テンプレート に置き換えます。 その変更は、明瞭にする為に(テンプレート規則名前付きテンプレートを伴う混同を回避する為に)部分的になされますが、セマンティクスの多くの公式定義にも反映します。 XSLT 1.0は、結果ツリーの為に書かれた命令のシーケンスとしてテンプレートを記述したのに対し、XSLT 2.0は、アイテムのシーケンスを返すために評価される事が可能である何かとして、含んでいる命令に依存するこれらのアイテムに何が起きるのかというシーケンスコンストラクタを記述します。

5.7.1 複雑なコンテンツを構築する

このセクションは、新たに構築した文書ノードの子、または、その子、属性と新たに構築した要素ノードの名前空間を構築する為に利用される場合があるシーケンスコンストラクタを評価する事によってどのようにシーケンスが含まれるのかを記述します。 アイテムのシーケンスは、このように xsl:copyxsl:elementxsl:documentxsl:result-document といった命令 または、リテラル結果要素の中に含んだシーケンスコンストラクタを評価する事によって含まれる場合があります。

要素のコンテンツを構築する際には、 xsl:elementinherit-namespaces 属性、または、 xsl:copy 命令、または、リテラル結果要素の xsl:inherit-namespaces プロパティは、 名前空間ノードが引き継がれるようにするかどうかを決めます。 この属性の効果は、次に続く規則で記述されます。

シーケンスは、次に続くように処理されます。(それらが列挙された命令の中にある規則を適用)

  1. 含んでいる命令は、単独の命令における規則の中に記述したように属性ノードと名前空間ノード、または、属性ノードか名前空間ノードを生成する場合があります。 例えば、 これらのノードは、 [xsl:]use-attribute-sets 属性を拡張する事によって、または、 リテラル 結果要素の属性を拡張する事によって創出される場合があります。 いくつかのこのようなノードは、シーケンスコンストラクタを評価する事によって創出したシーケンスが先頭に追加されます。

  2. シーケンスの中でいくつかの原子化された値は、文字列に投入されます。

    注釈:

    xs:QName 、または、 xs:NOTATION から xs:string への投入は、常に成功します、なぜならこれらの値は、この目的の為に前置詞をそのままにしておくからです。 しかしながら、前置詞が利用した保証がない事は、結果文字列が利用される場合の文脈の中で常に重要になります。

  3. 連続する(単に連なる)文字列間のセパレータ(区切り)として利用した単独のスペース(空白)(#x20)を伴って戻る中にある文字列ごとの内容を含むstring 値のある結果シーケンス内で(一定の規則性を持って)連続したいくつかの文字列のシーケンスは、単独のテキストノードに変換されます。

  4. 結果シーケンスにあるいくつかの文書ノードは、文書命令の中にあるその子それぞれを含んでいるシーケンスによって置き換えられます。

  5. 結果シーケンスにあるゼロの長さのテキストノードは、削除されます。

  6. 結果シーケンスにある隣接するテキストノードは、単独のテキストノードにマージされます。

  7. 妥当でない名前空間と属性ノードは、次に続くように見つけられます。

    [ERR XTDE0410] もし、結果シーケンスが、名前空間ノード、または、属性ノードを含む要素ノードのコンテンツを構築する為に利用した場合には、 それは、回復されない動的エラーであり、 それは、名前空間ノードでも、属性ノードでもいずれでもないノードによってシーケンスの中で優先されます。

    [ERR XTDE0420] もし、結果シーケンスが、名前空間ノード、または、属性ノードを含む文書ノードのコンテンツを構築する為に利用した場合には、 それは、回復されない動的エラーです。

    [ERR XTDE0430] もし、結果シーケンスが、同じ名前だが、異なるstring 値を持っている2つ以上の名前空間ノードを含む場合には、 それは、回復されない動的エラーです。 (それは、名前空間ノードが、異なる名前空間URIに同じ前置詞をマップするという事です)。

    [ERR XTDE0440] もし、結果シーケンスが、名前がなく、構築されている要素ノードがNull名前空間URIを持っている名前空間ノードを含む場合には、 それは、回復されない動的エラーです。 (それは、要素が、存在しない名前空間の中にある時、既定名前空間を定義する為にエラーとなります)。

  8. もし、結果シーケンスが、 同じ名前(または、名無し)で且つ、同じstring 値を持つ2つ以上の名前空間ノードを含む場合 (それは、同じ名前空間URIに同じ前置詞をマッピングしている2つの名前空間ノードという事です)には、重複するノードの内の1つが、全て破棄されます。

    注釈:

    名前空間ノードの命令が未定義という事から、重複が、そのまま残されるという事は重要ではありません。

  9. もし、結果シーケンスにある属性 A が、結果シーケンス内で最後に現れるその他の属性 B と同じ名前を持つ場合には、 属性 A は、結果シーケンスから破棄されます。

  10. 結果シーケンスにある各ノードは、名前空間、属性、または、新たに構築した要素、または、文書ノードの子として結び付けられます。 これはノードの深いコピーをさせる事を必然的に含む概念; 慣習では、しかしながら、ノードをコピーする事は、もし、存在するノードが結び付けられている親から独立して参照される事ができる場合など必要になる場合に限られるでしょう。 要素、または、処理命令ノードをコピーする際には、その基準URIプロパティは、これを覆して優先する xml:base 属性 (参照先: [XML Base])を持っていない限り(持っている場合を除いて)、その新しい親のそれと同じとなるように変更されます。 もし、 copied 要素が、 xml:base 属性を持つ場合には、その基準URIは、その属性の値であり、 (もし、それが関連するなら)新しい親ノードの基準URIに対して解決されます。

  11. もし、新たに構築したノードが、要素ノードである場合には、名前空間の取り決めは、5.7.3 名前空間 Fixupに記述したように、このノードに適用されます。

  12. もし、新たに構築したノードが、要素ノードで、かつ、もし、名前空間が引き継がれている場合には、 (名前空間取り決めプロセスの結果として創出したいくつかを含んでいる)新たに構築した要素のそれぞれの名前空間ノードは、 その要素、または、既に介在する要素が、 同じ名前 (または、名前がない)を伴う名前空間ノードか、または、子孫要素か、または、存在しない名前空間にある介在する要素で且つ、存在しない名前を持つ名前空間でない限り、 新たに構築した要素の子孫要素ごとにコピーされます。

例:複雑なコンテンツにおけるシーケンスコンストラクタ

次に続くスタイルシート断片を考察します:

<td>
	<xsl:attribute name="valign">top</xsl:attribute>
	<xsl:value-of select="@description"/>
</td>

この断片は、2つの命令で構成するシーケンスコンストラクタを含んでいるリテラル結果要素 td で構成します: xsl:attributexsl:value-of。 シーケンスコンストラクタは、親のない属性ノードと親のないテキストノードという2つのノードのシーケンスを創出する為に評価されます。
td 命令は、作成される為の td 要素に起因します; 新しい属性は、それゆえに、xsl:value-of 命令によって作成したテキストノードが、 td 要素の子になるまで(それが、破棄されるケースにおいてゼロの長さになるまで(ゼロの長さである場合を除いて))新しいtd 要素の属性になります。

 

例:要素内容にあるスペース区切り

次に続くスタイルシート断片を考察します:

<doc>
	<e><xsl:sequence select="1 to 5"/></e>
	<f>
		<xsl:for-each select="1 to 5">
			<xsl:value-of select="."/>
		</xsl:for-each>
	</f>
</doc>

これは、出力を創り出します (字下げした際):

<doc>
	<e>1 2 3 4 5</e>
	<f>12345</f>
</doc>

e 要素、5つの原子化された値のシーケンスを生成するシーケンスコンストラクタにおける2つのケース間の相違は、それゆえにスペースで区切られる事です。 f 要素においては、コンテンツは、5つのテキストノードのシーケンスであり、それは、スペース区切りなしで結合されます。

未変更の式 select の値を返す xsl:sequence 、そしてテキストノードを構築する xsl:value-of 間の差異を知っておく事は重要です。

5.7.2 単純なコンテンツを構築する

xsl:attributexsl:commentxsl:processing-instructionxsl:namespacexsl:value-of 要素は、子を持つ事が出来ないノードを生成します。
具体的に言うと、 xsl:attribute 命令は、属性ノードを生成し、 xsl:comment は、コメントノードを生成、 xsl:processing-instruction は、処理命令ノードを生成、 xsl:namespace は、名前空間ノードを生成、 xsl:value-of は、テキストノードを生成します。
新しいノードのstring値は、その命令の select 属性、または、その命令の内容を形作るシーケンスコンストラクタのいずれかを利用して構築されます。 select 属性は、シーケンスコンストラクタがXSLT命令のシーケンスという意味によって記述される為にそれを許容する間、XPath式という意味で記述される為にコンテンツを許容します。 select 属性、または、シーケンスコンストラクタは、結果シーケンスを生成する為に評価され、
そして、新しいノードのstring値は、以下の規則に一致するこの結果シーケンスから得ます。

これらの規則はまた、属性値テンプレート有効な値を算出する為に利用されます。 シーケンスが処理されているこのケースは、波カッコ間に囲まれ、そのセパレータは、単独のスペース(空白)文字であるXPath式を評価している結果です。

  1. シーケンス中のゼロの長さのテキストノードは、破棄されます。

  2. シーケンス中の隣り合うテキストノードは、単独のテキストノードにマージされます。

  3. シーケンスは、原子化されます。

  4. 原子化されたシーケンス中のそれぞれの値は、文字列に投入されます。

  5. 結果シーケンスにある文字列は、(単に連なる)連続する文字列間に(利用可能なゼロの長さの)セパレータを挿入して結合されます。 既定セパレータは、スペースです。 xsl:attributexsl:value-of のケースでは、 異なるセパレータは、その命令の separator 属性を利用して記述される事が可能です; セパレータを持たずに結合された文字列においては、それは、ゼロの長さになるように、これにおいて許容されます。 xsl:commentxsl:processing-instructionxsl:namespace 、と属性値テンプレートを拡張するケースでは、既定セパレータは、変更される事ができません。

  6. xsl:processing-instructionのケースでは、 結果文字列にあるいくつかの先行しているスペースは、削除されます。

  7. 結果文字列は、新しい属性、名前空間、コメント、処理命令、または、テキストノードのstring 値を成形します。

例:属性コンテンツにあるスペースセパレータ

次に続くスタイルシート断片を考察します:

<doc>
	<xsl:attribute name="e" select="1 to 5"/>
	<xsl:attribute name="f">
		<xsl:for-each select="1 to 5">
			<xsl:value-of select="."/>
		</xsl:for-each>
	</xsl:attribute>
</doc>

これは、出力を生成します:

<doc e="1 2 3 4 5" f="12345"/>

e 属性における2つの間の相違は、 シーケンスコンストラクタは、5つの原子化された値のシーケンスを生成し、それゆえにスペースで区切られる事です。
f 属性においては、そのコンテンツは、5つのテキストノードのシーケンスとして提供されるコンテンツであり、それは、スペース区切りなしで結合されます。

最初の xsl:attribute 命令上の separator="" 仕様は、 e="12345" とする為の属性値に起因するでしょう。
2つめの xsl:attribute 命令上の separator 属性は、そのセパレータが、隣り合う原子化された値が操作される方法でのみ影響を及ぼすので効果はないでしょう。:セパレータは決して隣り合うテキストノード間に挿入されません。

注釈:

もし、属性値テンプレートが、固定部分と可変部分のシーケンスを含む場合には、存在しない付加的なホワイトスペースが、固定部分の拡張と可変部分の拡張間に挿入されます。 例えば、 a="chapters{4 to 6}"a="chapters4 5 6" である属性の有効な値

5.7.3 名前空間取り決め

XSLTプロセッサに提供したツリー、または、XSLTプロセッサによって構築したツリーでは、[データモデル]で記述される名前空間ノードに関連する制約は、満たされなければいけません。例えば、

  • もし、要素ノードが、Nullではない名前空間URIを伴う拡張QNameを持つ場合には、 要素ノードは、string値が、その名前空間URIと同じである少なくとも1つの名前空間ノードを持っていなければいけません

  • もし、要素ノードが、Nullの名前空間URIを持つ拡張QNameの属性ノードを持つ場合には、 要素は、string 値が、名前がカラでない名前空間URIと名前と同じである少なくとも1つの名前空間ノード持っていなければいけません

  • それぞれの要素は、位置部分(local-part)が xml であり、string値が、 http://www.w3.org/XML/1998/namespace を持つ拡張QNameのある名前空間ノードを持っていなければいけません。 名前空間前置詞 xml は、いくつかの他の名前空間URIと結び付けられてはならず、また、 名前空間URI http://www.w3.org/XML/1998/namespace は、いくつかの他の前置詞と結び付けられてはいけません。

  • 名前空間ノードは、名前 xmlns を持っていてはいけません

[定義:  結果ツリーを構築する独立したXSLT命令における規則(参照先: 11 ノードとシーケンス生成)は、 ツリーに書かれる名前空間ノードにあるいくつかのシチュエーションを規定します。 これらの規則は、しかしながら、常に満たされる制約を規定する事を保証するに足るものではありません。 XSLTプロセッサは、それゆえにこれらの制約を満たすための付加的な名前空間ノードを追加しなければいけません。 このプロセスは、namespace fixup/名前空間の取り決めとして参照されます。 ]

名前空間の取り決めプロセスによってツリーに追加される現存する名前空間ノードは、implementation-dependentであり、 1つめは、上記のプロセスの終わりで提供され、制約は、すべて満たさなければならず、 2つめは、名前空間ノードは、名前空間ノードが必要とするこれらの制約を満たすか、または、スタイルシートから得たオリジナル名前空間前置詞を利用してシリアライズされる為にツリーを利用可能にするかのいずれかである場合を除いて、ツリーに追加されてはいけません

名前空間の取り決めは、同じ名前を持つ多数の名前空間ノードを持っている要素の中に生じてはいけません

名前空間の取り決めは、もし、衝突を解決する事が必要な場合には、QName値に含んだ名前空間前置詞を変更する場合があり、それは、要素、または、属性ノードの名前を保持します。 これは、追加するオプションまたは、前置詞を削除するオプションを含みます。 しかしながら、 名前空間の取り決めは、 xs:QName、または、xs:NOTATION のタイプ値に含んだ前置詞コンポーネントを変更してはならず、それは、要素、または、属性ノードの区分した値を形成します。

注釈:

名前空間の取り決めは、要素、または、属性のコンテンツ内に現れている xs:QName、または、 xs:NOTATION 値における名前空間宣言を創出する為には利用されません。

値が、妥当性検証の結果としてこのようなタイプを取得する場合、名前空間の取り決めが、妥当性検証の前に発生するので名前空間の取り決めは、作用に加わりません。: このシチュエーションでは、要素が有効になっている事を保証する事におけるユーザーの信頼性は、成功する為の妥当性検証を利用可能にする為に名前空間ノードを要求しています。

存在する要素が、それらの存在するタイプ注釈 ( validation="preserve" )を伴ってコピーされる場合には、存在する名前空間ノードを要求する規則もまたコピーされ、その為、いくつかのnamespace-sensitive値は、有効なままです。

存在する属性が、それらの存在するタイプ注釈を伴い、それに沿ってコピーされる場合には、 親のない属性ノードを要求するXDMデータモデルの規則は、区分した値をnamespace-sensitiveに含む事はできません; これが意味するところは、もし、それが、namespace-sensitive内容を含む場合には、 validation="preserve" を利用する属性をコピーする為にエラーであるという事です。

[ERR XTDE0485] もし、 名前空間の取り決めが、含む要素上で実行される場合には、その要素とその属性の区分した値の間は、名前空間前置詞の衝突を含んでいるタイプ xs:QName 、または、 xs:NOTATION の2つの値である場合には、それは、回復されない動的エラーであり、それは、異なる名前空間URIを参照する為に同じ前置詞を利用する2つの値という事です。

名前空間の取り決めは、リテラル結果要素を利用して構築される要素ごとに、または、xsl:elementxsl:copy 、または、 xsl:copy-of の1つずつ適用されます。 手法は、いくつかのソース文書にある要素における名前空間の取り決めを実行する事は、要求されません、 それは、初期入力シーケンスにある文書、 documentdocFOを利用して読み込んだ文書、 または、 collectionFO関数、 スタイルシートパラメータの値として提供した文書、または、 拡張関数、または、拡張命令によって返した文書においてというい事です。

注釈:

ソース文書 (入力文書、document によって返した文書、 docFO、または、 collectionFO関数、 拡張関数 または、拡張命令によって返した文書、または、スタイルシートパラメータとして提供した文書)は、 [データモデル]で記述した制約、 名前空間取り決めプロセスによって課した含んでいる制約を満たす事を要求されます。 これらの制約に遭遇しない疑似文書を提供する作用は、未定義とされています。

[XML1.0にある名前空間]に一致する文書から創出した情報セット(参照先: [XML情報セット])では、 もし、親要素が、カラでない名前空間前置詞を伴うスコープ内名前空間を持つ場合には、常に「true」になるでしょう、 その時、その子要素は、同じ名前空間前置詞を伴うスコープ内名前空間もまた持つでしょう、けれども異なる名前空間URIを伴う事も(可能性は低いですが)あるでしょう。 この制約は、[XML 1.1にある名前空間]で削除されます。 XSLT 2.0は、この制約を満たさない結果ツリーの作成をサポートします: 名前空間の取り決めプロセスは、その親が、このような名前空間ノードを持つ結果ツリーにあるノードなので、ただ単に要素に名前空間ノードを追加するわけではありません。 しかしながら、構築のプロセスは、新しい要素の子であり、5.7.1 複雑なコンテンツを構築するで記述したそれは、 これが、親要素を創出する命令上で [xsl:]inherit-namespaces="no" を利用して回避されない限り(回避される場合を除き)、その子によって受け継がれる為の親要素の名前空間に起因します。

注釈:

これは、シリアライゼーション上で影響を持ち、これは、[XSLT と XQuery シリアライゼーション]で定義しました。 それが意味するところは、最終結果ツリー創出を可能とする事は、XML 1.0文書として忠実にシリアライズされる事ができないという事です。 このような結果ツリーが、XML 1.0としてシリアライズされる際に、親要素において書かれた名前空間宣言は、 xmlns="" 構築を利用して定義されない事が可能である既定名前空間の場合を除き、子要素上に提示される名前空間ノードと一致するかのようにその子要素によって受け継がれるでしょう。 同じ結果ツリーが、XML 1.1としてシリアライズされる際には、 しかしながら、それは、この継承が行なわれるのを防ぐ為に、子要素(例えば、 xmlms:foo="")上に宣言しないいくつかの名前空間を可能にします。

5.8 URI 参照

[定義:  この仕様がない場合には、用語 URI 参照 は、他の状態に置かれない限り(他の状態に置かれる場合を除き)、[XML スキーマ Part 2]で定義したようにデータタイプ xs:anyURI の語彙的なスペースにある文字列を参照します。 ] 注記としては、これは、[RFC3986]にあるよりも幅広い定義: 特に、[RFC3987]で記述したように国際化リソース識別子(IRIs)に適応する為に設計され、そしてこのようにエスケープすることなく、非ASCII文字の利用を許容します。

URI参照は、3つの主要な役割を持つXSLTの中で利用されます:

名前空間URIのように
照合URIのように
このようなスタイルシートモジュールリソースにおける識別子のように; これらのリソースは、HTTPのようなプロトコルを利用して典型的に使用され得るものです。 このような例の識別子は、 xsl:importxsl:includexsl:result-documenthref 属性でURIが利用されます。

名前空間URIにおける規則は、[XML1.0における名前空間][XML 1.1における名前空間]で与えます。 それらの仕様は、名前空間URIとしての相対URIの利用を推奨しません。

照合URIにおける規則は、[関数と演算子]で与えます。

外部リソースを識別する為に利用したURI参照は、セクション 5.4 [XLink]で定義したロケーター属性( href )として同じ規則に従わなければいけません。 もし、URI参照が適切であれば、 (他で記述されない限り(他で記述される場合を除き)) 最初のエスケープの後、それが妥当なRFC3986 URI参照を作る為にエスケープされる必要のある全ての文字列は、[RFC3986]の規則に一致する含んでいる要素ノードの基準URIに対して解決されます。 (しかし、xsl:result-document の属性 href にある相対URIは、 基準出力URIに対して解決されます。)

XSLTスタイルシート文書内に出現する他のURI参照、例えば、外部入力のシステム識別子、または、 xml:base 属性の値は、 それらのそれぞれの仕様にある規則に続かなければいけません。

6. テンプレート規則 / Template Rules >>


ホーム前へ次へ