【Final Result Trees / 最終結果ツリー】XSLT 2.0/XSL Transformations Version2.0/Extensible Stylesheet Language Transformations Version2.0

19.2.1.1 [xsl:]validation 属性を利用して有効にする(妥当とする)

[xsl:]validation 属性は、取得される為の動作の妥当性検証を定義します。 それは、関連する命令それ自身によって構築されるノードのタイプ注釈ばかりでなく、 先祖として構築したノードを持つ全ての要素と属性ノードのタイプ注釈をも決定します。 観念としては、子要素または、属性ノードにおいて要求した妥当性検証は、その親要素において要求した妥当性検証よりも前に適用されます。 例えば、もし、 validation="strict" と記述する子要素を構築する命令、 これは、要素宣言に対してチェックされる為に子要素に起因するでしょうが、もし、 validation="strip" を記述するその親要素を構築する命令がある場合には、 最終的な効果は、 xs:untyped として注釈を付記される子ノードとなるでしょう。

下記の段落では、用語 含んだノード は、先祖として新たに構築したノードを持つ要素と属性を意味します。

• 値 strip は、新しいノードと含んだノードごとに表示する xs:untypedAtomic は、 もし、それが要素である場合、または、それが属性である場合には、タイプ注釈 xs:untyped を持つでしょう。 含んだ要素、または、属性ノード上に存在するいくつかの先のタイプ注釈(例えば、ソース文書からコピーした要素上に存在するタイプ注釈)はまた、 妥当なものとしての xs:untyped 、または、 xs:untypedAtomic によって置き換えられます。 ノードの区分した値は、 xs:untypedAtomic のインスタンスとして、その文字列値と同じにする為に変換されます。 要素のケースでは、 nilled プロパティは、 false に設定されます。 is-id と is-idrefs プロパティの値は、未変更になります。 スキーマ妥当性検証は、実行されません。

• コピーされるノードを表す値 preserve は、それらのタイプ注釈は、そのままですが、 新たに構築される内容を持つノードは、要素のケースでは、 xs:anyType 、または、属性のケースでは、 xs:untypedAtomic として注釈を付記されるでしょう。 スキーマ妥当性検証は、実行されません。 詳細な効果は、命令に依存します：

  • xsl:element とリテラル結果要素のケースでは、 新しい要素は、 xs:anyType のタイプ注釈を持ち、 そしてまた、含んだノードのそのタイプ注釈は、未変更のまま残されるでしょう。

  • xsl:attribute のケースでは、 その効果は、 validation="strip" を記述している時と全く同じです： それは、その新しい属性は、タイプ注釈 xs:untypedAtomic を持つでしょうという事です。

  • xsl:copy-of のケースでは、コピーされる全てのノードは、それらのタイプ注釈が未変更のままでしょう。

  • xsl:copy のケースでは、その効果は、コピーされるノードの種類に依存します。

    1. コピーされているノードが属性の場合には、コピーした属性は、そのタイプ注釈のままでしょう。

    2. コピーされているノードが要素の場合には、コピーした要素は、 xs:anyType のタイプ注釈を持つでしょう (なぜなら、この命令は、要素の内容をコピーしないので、タイプが未変更だと仮定する事は誤りとなるからです)； しかし、いくつかの含んだノードは、 xsl:element を伴う時と同じ方法でそれらのタイプ注釈をそのまま持つでしょう。

• タイプ注釈を表す値 strict は、次に続くようにこの命令によって生成した要素または属性ノードにおける厳格なスキーマ妥当性評価を実行する事によって確立されます：

  • ある要素のケースでは、 top-level要素宣言は、ローカル名と(もしあれば)要素の名前とマッチする名前空間を持つものが識別され、 スキーマ妥当性検証評価は、[XML スキーマ Part 1]で定義した規則と一致するように実行されます。 ( 1.1.1.1 節で言及される「プロセッサによって条件として要求された宣言」としてのtop-level要素宣言を利用しているセクション 3.3.4 "要素宣言妥当性検証規則"、妥当性検証規則 "Schema-Validity評価(要素)"、1.1 と 2 節). 要素は、もし、スキーマ妥当性検証評価の結果が、値が valid である validity プロパティを持つ関連する要素ノードにおけるPSVIである場合には、妥当である事が考慮されます。
    
    もし、存在しない一致している要素宣言がある場合、または、もし、その要素が妥当性が考慮されずに変換が失敗する場合 [参照先：ERR XTTE1510]、[参照先：ERR XTTE1512]。
    
    効果においてこれが意味するところは、有効となっている要素は、スキーマにある top-level 宣言を利用して宣言されなければならず、 そしてまた、その宣言と一致していなければいけません。 妥当性検証のプロセスは、スキーマ定義によって要求した範囲における含んだ要素と属性に再帰的に適用します。

    注釈：

    もし、識別したタイプ定義は、単純なタイプだけれども[XML スキーマ Part 1]が、このケースが実行されるという事を明示的に定義していない場合は、エラーではありません。

  • 属性のケースでは、 top-level 属性宣言は、ローカル名と(もしあれば)属性の名前とマッチする名前空間を持つものが識別され、スキーマ妥当性検証評価は、 [XML スキーマ Part 1](セクション 3.2.4 "属性宣言妥当性検証規則"、妥当性検証規則 "スキーマ妥当性検証評価(属性)") で定義した規則と一致するように実行されます。 属性は、もし、スキーマ妥当性検証評価の結果が、値が valid である validity プロパティを持つ関連する属性ノードにおけるPSVIである場合には、妥当である事が考慮されます。 もし、属性が、妥当性を考慮されず、変換が失敗する場合[参照：ERR XTTE1510]。 効果の中では、これは、有効となっている属性は、スキーマにある top-level 宣言を利用して宣言されなければいけないということであり、 その宣言と一致しなければならないという事です。

  • 要素、または、属性の妥当性検証の為に利用したスキーマコンポーネントは、 [XML スキーマ Part 1](参照：セクション 4.3.2 スキーマ文書がウェブ上で位置決めされる方法 ) によって記述したいくつかの方法で位置決めされる場合があります。 統合的なスキーマ文書から構築したスキーマにあるコンポーネント(参照先： 3.14 スキーマコンポーネントを取り込む)は、 常に構築したノードの妥当性検証において利用可能となるでしょう； もし、付加的なスキーマコンポーネントが、必要とされる場合には、 それらは、例えば、暗黙の内に出現する要素と属性にある名前空間の知識から位置決めする、 または、有効となっているツリーにある要素の xsi:schemaLocation 属性を利用して位置決めする といった他の方法で位置決めされる場合があります。

  • もし、存在しない妥当性検証が、 lax 、または、 skip 妥当性検証を記述する場合に生じる事が可能なノードにおいて、 または、サブツリーにおいて実行される場合には、ノードは、要素のケースでは、 xs:anyType として、 属性のケースでは、 xs:untypedAtomic として注記を付記されます。

• 値 lax は、 strict 妥当性検証が失敗するのに対して、 もし、存在しない top-level 要素宣言と一致している場合、 または、 もし、妥当性検証評価の結果が、 invalid 、または、 notKnown の validity プロパティである場合、 単にもし、妥当性検証の結果が invalid の validity プロパティである場合に lax 妥当性検証が失敗する場合を除き、 値 strict と同じ効果を持ちます。 それは、 lax 妥当性検証は、結果が、 notKnown である場合は、タイプエラーの起因ではない(タイプエラーにはならない)という事です。

  慣例では、これが意味するところは、その有効となっている要素、または、属性は、もし、 top-level 宣言が、利用可能であれば、その宣言と一致しなければいけません。 もし、存在しないそのような宣言が利用可能である場合には、その要素、または、属性は妥当ではありませんが、その属性と子は、有効とされ、再び lax 妥当性検証を伴います。 妥当性検証結果が、 notKnown の validity プロパティであるいくつかのノードは、要素のケースでは、 xs:anyType として、 属性のケースでは、 xs:untypedAtomic として注記が付記されます。

  注釈：

  親要素で宣言が不足する場合、XMLスキーマ仕様は、オプションとして子と属性を再帰的にチェックする事を定義します。 この仕様においては、この再帰的チェックをする事が要求されます。

  注釈：

  もし、有効となっている要素が、 xsi:type 属性を持つ場合には、 xsi:type 属性の値は、妥当性検証を実行している場合にアカウントに取得されます。 しかしながら、 xsi:type 属性の存在は、妥当性検証される為の要素に起因するそれ自身を構成しないでしょう： もし、 top-level 要素宣言に対して妥当性検証から識別する要求される名前付きタイプに対して妥当性検証する場合には、 それは、セクション 19.2.1.2 [xsl:]type 属性を利用して妥当性検証するで記述したように、 妥当性検証を実行する命令上にあるXSLT [xsl:]type 属性を利用して要求されなければいけません。

[ERR XTTE1510] もし、 xsl:element 、 xsl:attribute 、 xsl:copy 、 xsl:copy-of の validation 属性、 または、 xsl:result-document 命令、 または、リテラル結果要素の xsl:validation 属性が、有効な値 strict を持ち、 そしてまた、スキーマ妥当性検証評価が、要素、または、属性の妥当性が、妥当ではない、または、未知であると結論付ける場合には、タイプエラーが出現します。 他のタイプエラーを伴う時、もし、エラーが静的に回避される事が可能であれば、静的にシグナル出力される場合があります。

[ERR XTTE1512] もし、 xsl:element 、 xsl:attribute 、 xsl:copy 、 xsl:copy-of の validation 属性、 または、 xsl:result-document 命令、または、リテラル結果要素の xsl:validation 属性が、 有効な値 strict を持ち、そしてまた、スキーマにある存在しない top-level 宣言と一致している場合には、タイプエラーが出現します。 他のタイプエラーを伴う時、もし、エラーが静的に回避される事が可能であれば、静的にシグナル出力される場合があります。

[ERR XTTE1515] もし、 xsl:element 、 xsl:attribute 、 xsl:copy 、 xsl:copy-of の validation 属性、 または、 xsl:result-document 命令、または、リテラル結果要素の xsl:validation 属性が、 有効な値 lax を持ち、そしてまた、スキーマ妥当性検証評価が、要素、または、属性が妥当ではないと結論付ける場合には、タイプエラーが出現します。 他のタイプエラーを伴う時、もし、エラーが静的に回避される事が可能であれば、静的にシグナル出力される場合があります。

19.2.1.2 [xsl:]type 属性を利用して妥当性検証する

[xsl:]type 属性は、 QName をその値として受け取ります。 これは、スタイルシートにおけるスコープ内スキーマコンポーネントの中で含んだ タイプ定義の名前にしなければいけません。 もし、その QName が、存在しない前置詞を持つ場合には、それは、もし、それが存在する場合には、有効な [xsl:]xpath-default-namespace 属性を利用して確立した既定名前空間を利用して拡張されます。； その他のものは、存在しない名前空間にある名前が存在しているものとして受け取ります。

もし、 [xsl:]type 属性が存在する場合には、 その新たに構築した要素、または、属性は、この属性によって識別したタイプ定義に対して有効(妥当)とされます。

• 要素のケースでは、 スキーマ妥当性検証評価は、「プロセッサが条件として要求したタイプ定義」としてこのタイプ定義を利用して [XML スキーマ Part 1](セクション 3.3.4 "要素宣言妥当性検証規則"、 妥当性検証規則 "スキーマ妥当性検証評価(要素)"、 1.2 と 2 節)で 定義した規則と一致するように実行されます。 その要素は、もし、そのスキーマ妥当性検証評価の結果が、値が valid である validity プロパティを持つ関連する要素ノードにあるPSVIである場合には、 妥当である事が考慮されます。

• 属性のケースでは、もし、(XMLスキーマの専門用語の中にある)属性の標準化された値が、 『妥当な文字・文字妥当性(String Valid)』([XML スキーマ Part 1]、 セクション 3.14.4) における規則と一致するタイプ定義に関連して局所的に妥当である場合には、属性が、妥当である事が考慮されます。 (標準化は現在、データタイプにおける whiteSpace ファセットの規則と一致する標準化したホワイトスペースのプロセスを参照します)。

• もし、要素、または、属性が妥当である事を考慮されない場合には、上で定義したように、その変換は、失敗します [参照先：ERR XTTE1540]。

[ERR XTSE1520] もし、 xsl:element 、 xsl:attribute 、 xsl:copy 、 xsl:copy-of 、 xsl:document の type 属性の値、 または、 xsl:result-document 命令、または、リテラル結果要素の xsl:type 属性の値が妥当な QName ではない場合、 または、もし、スコープ内名前空間宣言で定義していない前置詞を利用する場合、 または、もし、その QName が、スタイルシートにおけるスコープ内スキーマコンポーネントの中で含んだタイプ定義の名前ではない場合には、 それは、静的エラーです。

[ERR XTSE1530] もし、 xsl:attribute 命令の type 属性の値が、複雑なタイプ定義を参照する場合には、 それは、静的エラーです。

[ERR XTTE1540] もし、 [xsl:]type 属性が構築した要素、または、属性において定義され、 そのタイプに対するスキーマ妥当性検証評価の結果が、その要素、または、属性情報アイテムの validity プロパティが valid ではない場合には、 それは、タイプエラーです。

19.2.1.3 妥当性検証処理

スキーマに対する妥当性検証におけるチェック同様、 妥当性検証評価処理は、要素と属性ノードを結びつけるためのタイプ表記に起因します。 もし、要素、または、属性における既定値が、スキーマ内で定義される場合には、 妥当性検証プロセスは、どこかでこれらの既定値を含んでいる新しいノードを作成する必要があるでしょう。

要素、または、 属性ノードの妥当性検証は、単に要素、または、属性の内容におけるアカウント制約に採り入れます。 全体として文書に影響(作用)している妥当性検証規則は適用されません。 具体的に言うと、この意味は：

• 妥当性検証規則『Validation Root Valid (ID/IDREF)』は適用されません。 これが意味するところは、妥当性検証は、もし、有効となっている(妥当である)サブツリー内に一意でないID 値がある場合や未解決となっている IDREF 値がある場合は、失敗ではないでしょうという事です。

• 妥当性検証規則『Validation Rule: Identity-constraint Satisfied』は適用されません。

• 存在しないチェックがあり、それは、文書が、タイプ xs:ENTITY 、または、 xs:ENTITIES のノードの値とマッチする名前である解析しなかった実体を含みます。
  (＝(こういう状況はあるので)文書が、タイプ xs:ENTITY 、または、 xs:ENTITIES のノードの値とマッチする名前である解析しなかった実体を含んではいけないというチェックは存在しません。)
  (XSLT 2.0は、ツリー内にある解析していない実体を構築する為の存在しない利便性を提供します。)

• 存在しないチェックがあり、それは、文書が、タイプ xs:NOTATION のノードの値とマッチする名前である注釈を含みます。
  (＝(こういう状況はあるので)文書が、タイプ xs:NOTATION のノードの値とマッチする名前である注釈を含んではいけないというチェックは存在しません。)
  (XDMデータモデルは、ツリー内にある表現される為の注釈において存在しない規定を作ります。)

これらの注意条項を伴う場合、 strict、または、 lax 妥当性検証を利用して新たに構築した妥当な要素は、次に続くステップと同等です：

1. その要素は、既定となるパラメータ全てを伴うXML出力メソッドを利用して[XSLT と XQuery シリアライゼーション]で定義した規則と一致する原文に忠実なXML形式にシリアライズされます。 注記としては、このプロセスは、存在するいくつかのタイプ注釈を廃棄します。

2. 結果となるXML文書は、XML情報セットを生成する為に解析されます。(参照先： [XML情報セット]。)

3. 前段階で生成したその情報セットは、[XML スキーマ Part 1]にある規則と一致するように妥当性検証されます。 この段階の結果は、 Post-Schema Validation Infoset (PSVI) です。 もし、その妥当性検証プロセスが、(上で定義したように)成功しない場合には、タイプエラーが生じます。

4. 前段階で生成したそのPSVIは、[データモデル] (セクション 3.3.1 Mapping PSVI Additions to Node Properties^DM)で記述したマッピングによって XDM データモデルに戻すように変換されます。 このプロセスは、スキーマ妥当性検証中に確立したタイプを基準とする単純な、または、複雑なタイプ注釈を伴うノードを創出します。

strict 、または、 lax 妥当性検証を利用した妥当な属性は、この処理手順のバージョンの部分修正を要求します。 属性のコピーは、まず、その目的とこの要素ノードにおいて実行される名前空間の取り決め (参照先： 5.7.3 名前空間の取り決め)において作成される要素ノードに追加されます。 この要素の名前は、存在しない結果で構成されますが、それは、その形式の統合した要素宣言の名前と同じにしなければいけません。：

<xs:element name="E">
	<xs:complexType>
		<xs:sequence/>
		<xs:attribute ref="A"/>
	</xs:complexType>
</xs:element>

[ A ]が有効となっている属性の名前である場合。

この統合要素は、その時、妥当な要素において上で与えた処理手順を利用して妥当とされ、 そしてまた、もし、妥当であるとわかった場合には、そのタイプ注釈はそのままで妥当となった属性のコピーが作られますが、 含んでいる要素からそれを分離します(そして、このようにいくつかの名前空間ノードからも分離します)。

XDM データモデルは、 namespace-qualified name(名前空間適格名)を含む区分した値を持つ為の存在しない親を伴う属性ノードを許可しません、 それは、 xs:QName 、または、 xs:NOTATION から推論されるタイプである値という事です。 この制限は、これらのタイプが名前空間前置詞を解決する為に含んでいる要素の名前空間ノードを当てにする事から課されます。 それゆえに、そのようなタイプに対して親のない属性を妥当性検証する事はエラーです。 これは、命令 xsl:attribute 、 xsl:copy 、 xsl:copy-of に作用します。

[ERR XTTE1545] もし、 type 、または、 validation 属性が、新しい属性ノードを構築する命令において(明快に、または、暗黙の内に)定義される場合、 もし、この効果が、リストによって構築した、または、合成した旧式のタイプ xs:QName 、または、 xs:NOTATION から推論されるタイプに対して妥当とされる為の属性値に起因する事である場合には、 タイプエラーが出現します。