気の向くままに辿るIT/ICT
webzoit.netウェブサイトホームページ
XSLT

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

ウェブ造ホーム前へ次へ
サイト内検索
カスタム検索
XSLTの最終結果ツリーとは?

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

XSLT 2.0最終結果ツリーとは

 W3C勧告XSLTバージョンXSLT 2.0の「Final Result Trees / 最終結果ツリー」

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

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

<< 18. 拡張と縮退 / Extensibility and Fallback

XSLT 2.0最終結果ツリー目次


19 最終結果ツリー / Final Result Trees
 19.1 最終結果ツリー作成
 19.2 妥当性
  19.2.1 構築された要素と属性の妥当性 Validating Constructed Elements and Attributes
   19.2.1.1 [xsl:]validation 属性の利用の妥当性 Validation using the [xsl:]validation Attribute
   19.2.1.2 [xsl:]type 属性の利用の妥当性 Validation using the [xsl:]type 属性
   19.2.1.3 処理の妥当性 The Validation Process
  19.2.2 文書ノードの妥当性 Validating Document Nodes

19 最終結果ツリー

変換の出力は、1つ以上の最終結果ツリーのセットです。

最終結果ツリーは、 2.4 変換を実行するで説明したように、最終結果ツリーはまた、 もし、 存在しない暗黙の内に xsl:result-document 命令が評価される場合、または、もし、 初期テンプレートを評価した結果がカラではないシーケンスである場合には、 xsl:result-document 命令を評価する事によって明示的に作成される事が可能です。

アプリケーションに搬送される最終結果ツリーにおける方法は、 implementation-definedです。

最終結果ツリーのシリアライゼーションは、 20 シリアライゼーションでより多く記述されます。

19.1 最終結果ツリーを作成する

<!-- カテゴリ: 命令 -->
<xsl:result-document
  format? = { qname }
  href? = { uri-reference }
  validation? = "strict" | "lax" | "preserve" | "strip"
  type? = qname
  method? = { "xml" | "html" | "xhtml" | "text" | qname-but-not-ncname }
  byte-order-mark? = { "yes" | "no" }
  cdata-section-elements? = { qnames }
  doctype-public? = { string }
  doctype-system? = { string }
  encoding? = { string }
  escape-uri-attributes? = { "yes" | "no" }
  include-content-type? = { "yes" | "no" }
  indent? = { "yes" | "no" }
  media-type? = { string }
  normalization-form? = { "NFC" | "NFD" | "NFKC"
| "NFKD" | "fully-normalized" | "none" | nmtoken }
  omit-xml-declaration? = { "yes" | "no" }
  standalone? = { "yes" | "no" | "omit" }
  undeclare-prefixes? = { "yes" | "no" }
  use-character-maps? = qnames
  output-version? = { nmtoken }>
  <!-- Content: sequence-constructor -->
</xsl:result-document>

xsl:result-document 命令は、最終結果ツリーを作成する為に利用されます。 xsl:result-document 要素の内容は、ツリーの文脈ノードの子における シーケンスコンストラクタです。 文書ノードが作成され、そして、シーケンスコンストラクタを評価する事によって含んだシーケンスは、 5.7.1 複雑なコンテンツを構築するで記述したように文書の内容を構築する為に利用されます。 この文書ノードをルートとしたツリーは、最終結果ツリーを形成します。

xsl:result-document 命令は、結果ツリーのURIを定義し、シリアライズしているこのツリーにおいて利用される為に付加的に出力フォーマットを記述する場合があります。

format 属性の有効な値は、 もし、記述した場合には、語彙的なQNameにしなければいけません。 そのQNameは、 xsl:result-document 要素におけるスコープ内にある名前空間宣言を利用して拡張されます。 拡張QNameは、スタイルシートにある 名前付き出力定義の拡張したQNameとマッチしなければいけません。 これは、もし、その結果ツリーがシリアライズされる場合には、最終結果ツリーの シリアライゼーションを操作するであろう xsl:output 宣言を識別します (参照先: 20 シリアライゼーション)。 もし、 format 属性が省略される場合には、 名無し出力定義が、結果ツリーのシリアライゼーションを操作する為に利用されます。

[ERR XTDE1460] もし、 format 属性の有効な値が、妥当な語彙的なQNameでない場合、 または、もし、それが、スタイルシートにある出力定義拡張QNameとマッチしない場合には、それは、回復されない動的エラーです。 もし、プロセッサが静的なエラーを回避する事が可能である場合(例えば、 format 属性が、存在しない波カッコを含む場合)には、 プロセッサは、静的エラーのようにこれを付加的にシグナル出力する場合があります

注釈:

単に名無し出力定義を選ぶ方法は、 format 属性を省略する事です。

属性 methodbyte-order-markcdata-section-elementsdoctype-publicdoctype-systemencodingescape-uri-attributesindentmedia-typenormalization-formomit-xml-declarationstandaloneundeclare-prefixesuse-character-mapsoutput-version は、 選択した出力定義の中で定義した属性に優先して利用される場合があります。

use-character-maps の例外を伴う場合には、 これらの属性は、属性値テンプレートとして定義した全てであり、その為、それらの値は、動的に設定される場合があります。 xsl:result-document 命令上に存在するこれらの属性のいくつかにおいては、 優先する属性の有効な値、または、出力定義から得た値と一致するように不足を補います。 これは、 xsl:output 宣言の一方がその他に優先する場合と同じ方法で作業します:

  • cdata-section-elements のケースでは、シリアライゼーションパラメータの値は、この命令の中で名付けた要素の拡張した名前と選択した出力定義の中で名付けた要素の結合です;

  • use-character-maps のケースでは、この命令の中で参照した文字列マップを補足し、そして、選択した出力定義の中で定義したそれらを超えて優先して取得します;

  • 他の全てのケースでは、この命令上に実際に存在する属性の有効な値は、選択した出力定義の中で定義した値を超えて優先して取得します。

注釈:

属性 methodcdata-section-elements use-character-maps のケースでは、 属性の有効な値は、1つ以上の語彙的なQNameを含みます。 このようなQNameにある前置詞は、 xsl:result-document 要素におけるスコープ内名前空間を利用して拡張されます。 cdata-section-elementsのケースでは、前置詞なし要素名は、既定名前空間を利用して拡張されます。

xsl:result-document 命令上の output-version 属性は、 xsl:output 上の version 属性に優先します ( version は、標準属性として異なる意味を持つ事を可能とするので改名されています: 参照 3.5 標準属性)。 他の全てのケースでは、もし、それらが同じ名前を持つ場合には、属性は一致します。

いくつかのシリアライゼーションパラメータがあり、それは、いくつかの出力メソッドに適用しますが、他には適用しません。 例えば、 indent 属性は、 text 出力メソッドにおける存在しない効果を持ちます。 もし、値が出力メソッドに適用できない属性において提供される場合には、その値は、シリアライズする為に通過されません。 プロセッサは、このような属性の値を有効にする場合がありますが、そのようにする事を要求されるわけではありません。

href 属性は、オプションです。 既定値は、ゼロの長さの文字列です。 属性の有効な値は、URI 参照にしなければならず、 それは、絶対URI、または、相対URIである場合があります。 利用される絶対URIの形式における制限をimplementation-definedにする場合がありますが、 手法は、いくつかの制限を強制する事を要求されるわけではありません。 いくつかの適法な相対URIが許容されなければいけません。 注記としては、ゼロの長さの文字列は、適法な相対URIです。

最終結果ツリーのルートにおける文書ノードの基準URIは、 href 属性の有効な値を基準とします。 もし、有効な値が相対URIである場合には、 基準出力URIにおける関連を解決されます。 もし、手法が最終結果ツリーにアクセスするAPIを提供する場合には、 この基準URIという意味で識別される為の最終結果ツリーを許容しなければいけません

注釈:

最終結果ツリーの基準URIは、もしある場合に、ディスク上でそのシリアライズした表現のURIと同じものにする必要性はありません。 例えば、サーバ(、または、ブラウザクライアント)は、メモリにだけ、または、内部ディスクキャッシュだけに最終結果ツリーを格納するかもしれません。 それらのURIにおける要求を満たすプロセッサと同様、もし、全て揃っている場合にディスク上に実際に書かれる場合には関係ありません。

注釈:

それは、しばしば、相対URIの形式で同じ変換中に生成したその他の最終結果ツリーへのリンクを含む最終結果ツリーの1つというケースになります。 最終結果ツリーを伴うURIを結びつけるメカニズムは、ツリーがシリアライズされる場合に保存する為にこのようなリンクの元のままの状態を許容する選択がなされています。

最終結果ツリーへのアクセスを提供するいくつかの APIにある主な性能と同様に、新しい文書ノードの基準URIは、 もし、シリアライズされない最終結果ツリーが更に変換する為に入力として提供される場合には、相対URIです。

付加的な属性 typevalidation は、新しい文書の内容を有効にする為、また、最終結果ツリーが 搬送するであろう要素と属性のタイプ注釈を決める為の xsl:result-document 命令上で 利用される場合があります。 許容した値とそれらのセマンティクスは、19.2.2 文書ノードを有効にする(妥当とする)で記述されます。

プロセッサは、シリアライズされる為に最終結果ツリーを許容する場合があります。 シリアライゼーションは、20 シリアライゼーションで記述されます。 しかしながら、ある手法(例えば、書き込み可能なファイル群へのアクセスのない環境で実行しているプロセッサ)は、 最終結果ツリーのシリアライゼーションをサポートする事を要求されません。 最終結果ツリーのシリアライゼーションをサポートしない手法は、 format 属性とそのシリアライゼーション属性を無視する場合があります。 このような手法は、それを識別する為のURIを利用して(シリアライズしていない)結果ツリーへのアクセスといういくつかの意味を伴ってアプリケーションに提供されなければいけません

手法は、この仕様のスコープ外で最終結果ツリーが処理される方法を決める為の付加的なメカニズムを提供する場合があります。 このようなメカニズムは、 xsl:result-documentxsl:output 要素か、そのいずれか、 または、付加的な要素を利用する場合のあるそれら(の要素)、 または、implementation-defined 名前空間にある属性におけるXSLT定義済み属性を利用させる場合があります

例:多種多様な結果文書

次に続く例は、入力としてXHTML文書を受け取り、そして、次に続く分割した文書に含まれる <h1> 要素ごとにテキストをそのように分解します。 新しい文書 toc.html は、インデックスとして動作する為に構築されます。:

<xsl:stylesheet
	version="2.0"
	xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
	xmlns:xhtml="http://www.w3.org/1999/xhtml">
	
<xsl:output name="toc-format" method="xhtml" indent="yes"
	doctype-system=
		"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
	doctype-public=
		"-//W3C//DTD XHTML 1.0 Strict//EN"/>
			
<xsl:output name="section-format" method="xhtml" indent="no"
	doctype-system=
		"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"
	doctype-public=
		"-//W3C//DTD XHTML 1.0 Transitional//EN"/>
	 
<xsl:template match="/">
	<xsl:result-document href="toc.html"
		format="toc-format" validation="strict">
		<html xmlns="http://www.w3.org/1999/xhtml">
		<head>
		<title>Table of Contents</title>
		</head>
		<body>
		<h1>Table of Contents</h1>
		<xsl:for-each select="/*/xhtml:body/(*[1] | xhtml:h1)">
			<p><a href="section{position()}.html">
				<xsl:value-of select="."/></a></p>
		</xsl:for-each>
		</body>
		</html>
	</xsl:result-document>
	<xsl:for-each-group select="/*/xhtml:body/*"
			group-starting-with="xhtml:h1">
		<xsl:result-document href="section{position()}.html" 
			 format="section-format" validation="strip">	 
			<html xmlns="http://www.w3.org/1999/xhtml">
			<head>
			<title><xsl:value-of select="."/></title>
			</head>
			<body>
			<xsl:copy-of select="current-group()"/>
			</body>
			</html>
		</xsl:result-document>
	</xsl:for-each-group>
</xsl:template>
</xsl:stylesheet>

プロセッサが評価される命令におけるシーケンスを最適化する際に、一様に完全な品質を持った操作 (fully interoperable even:[interoperable]、interoperability/インターオペラビリティ、いかなる環境でも操作できる・動作可能)である結果を 保証する為に設計される xsl:result-document 命令の利用においては制限があります。 非公式には、 xsl:result-document 命令にあるその制限は、一時的なツリー、または、シーケンスではなく、最終結果ツリーに書き込み中に限って利用される事が可能です。 この制限は、公式には、次に続くように定義されます。

[定義:  スタイルシートにおける各命令は、 最終出力状態、または、 一時的な出力状態という2つの可能な出力状態の内の1つで評価されます ]

[定義:  2つの内の最初の出力状態は、最終出力状態と呼ばれます。 この状態は、命令が、最終結果ツリーに書き込んでいる際に適用します。 ]

[定義:  2つの内の2つめの出力状態は、一時的な(temporary・テンポラリ)出力状態と呼ばれます。 この状態は、命令が、 一時的なツリー、または、いくつかの他の最終ではない目標に書き込んでいる際に適用します。 ]

初期テンプレートにある命令は、最終出力状態の中で評価されます。 命令は、xsl:variablexsl:paramxsl:with-paramxsl:attributexsl:commentxsl:processing-instructionxsl:namespacexsl:value-ofxsl:functionxsl:keyxsl:sort を除き、その呼び出し命令として同じ出力状態の中で評価され、 そして、 xsl:message は、常に 一時的な出力状態にある それらが含んだシーケンスコンストラクタにある命令を評価します。

[ERR XTDE1480] 一時的な出力状態にある xsl:result-document 命令を評価する事、 それは、回復されない動的エラーです。

[ERR XTDE1490] 2つ以上の同じURIを伴う最終結果ツリーを生成する為に変換する事、 それは、回復されない動的エラーです。

注釈:

注記:これが意味するところは、 href 属性を省略する xsl:result-document 命令を1つ以上評価する事、 または、もし、初期の最終結果ツリーが暗黙のうちに作成される場合に、 href 属性を省略する いくつかの xsl:result-document 命令を評価する事は、エラーです。

厳密に言うと、 xsl:result-document 命令を評価した結果は、カラのシーケンスです。 これが意味するところは、それが構成されるシーケンスコンストラクタの結果にいくつかのノードを提供しません。

[ERR XTRE1495] 同じ物理的なリソースを識別するURIを伴う2つ以上の最終結果ツリーを生成する為に変換する事は、 回復可能な動的エラーです。 付加的な回復動作は、implementation-dependentであり、 その為、エラーを回避する事をプロセッサに可能とさせる場合があります。

[ERR XTRE1500] スタイルシートにおいて、両方のケースにあるリソースにアクセスする為に利用される同じURIか否かという 単独の変換中に外部リソースに書き込む事、同じリソースから読み込む事は、回復可能な動的エラーです。 付加的な回復動作は、implementation-dependentです: 手法は、エラー条件を回避する事を要求されません。 注記としては、もし、そのエラーが回避されない場合には、結果ツリーが書き込まれる前後にその状態を示すリソースから読み込まれる文書かどうかは未定義です。

19.2 妥当性検証

それは、それらが構築されるものとして個々の要素と属性に適用されるタイプ注釈を操作する事を可能とします。 これは、 xsl:elementxsl:attributexsl:copyxsl:copy-ofxsl:documenttypevalidation 属性を利用して行われ、 そしてまた、 xsl:result-document 命令、 または、リテラル結果要素xsl:typexsl:validation 属性を利用して行われます。

[xsl:]type 属性は、スキーマで定義した単純な、または、複雑なタイプの記述に対して要素、または、属性の妥当性検証を要求する為に利用されます。 [xsl:]validation 属性は、グローバル要素または、有効と(妥当と)なっている要素または属性の名前とマッチする名前である属性宣言に対して妥当性検証を要求する為に利用されます。

[xsl:]type[xsl:]validation 属性は、相互に排他です。 双方ともにオプションですが、もし、一方が存在する場合には、他方は、省略されなければいけません。 もし、両方の属性が省略される場合には、その効果は、含んでいる xsl:stylesheet 要素の default-validation 属性で記述した値を伴う validation 属性を記述している時と同じです; もし、これが記述されない場合には、その効果は、 validation="strip" を記述している時と同じです。

[ERR XTSE1505] もし、 [xsl:]type[xsl:]validation 属性の両方が、 xsl:elementxsl:attributexsl:copyxsl:copy-ofxsl:document 、 または、 xsl:result-document 命令、 または、リテラル結果要素上に存在している場合には、 それは、静的エラーです。

妥当性検証における詳細規則は、有効となっているノードの種類への依存を多様に(変更)します。 要素と属性ノードにおける規則は、文書ノードについて19.2.2 文書ノードを有効にする(妥当とする)で与える限りは、19.2.1 構築した要素と属性を有効にする(妥当とする)で与えます。

19.2.1 構築した要素と属性を有効にする(妥当とする)
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-idis-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 、または、 notKnownvalidity プロパティである場合、 単にもし、妥当性検証の結果が invalidvalidity プロパティである場合に lax 妥当性検証が失敗する場合を除き、 値 strict と同じ効果を持ちます。 それは、 lax 妥当性検証は、結果が、 notKnown である場合は、タイプエラーの起因ではない(タイプエラーにはならない)という事です。

    慣例では、これが意味するところは、その有効となっている要素、または、属性は、もし、 top-level 宣言が、利用可能であれば、その宣言と一致しなければいけません。 もし、存在しないそのような宣言が利用可能である場合には、その要素、または、属性は妥当ではありませんが、その属性と子は、有効とされ、再び lax 妥当性検証を伴います。 妥当性検証結果が、 notKnownvalidity プロパティであるいくつかのノードは、要素のケースでは、 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:elementxsl:attributexsl:copyxsl:copy-ofvalidation 属性、 または、 xsl:result-document 命令、 または、リテラル結果要素の xsl:validation 属性が、有効な値 strict を持ち、 そしてまた、スキーマ妥当性検証評価が、要素、または、属性の妥当性が、妥当ではない、または、未知であると結論付ける場合には、タイプエラーが出現します。 他のタイプエラーを伴う時、もし、エラーが静的に回避される事が可能であれば、静的にシグナル出力される場合があります

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

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

注釈:

その存在しないメカニズムは、スキーマにあるローカル宣言に対して要素、または、属性を有効にする為に提供されます。 このような妥当性検証は、たいてい、存在する top-level 要素宣言において含んでいる要素に妥当性検証を適用する事によって達成される事が可能です。

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

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

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

注釈:

他のタイプエラーのように、このエラーは、もし、静的に回避される事が可能な場合には、静的にシグナル出力される場合があります。 例えば、命令

<xsl:attribute name="dob" type="xs:date">1999-02-29</xsl:attribute>

は、 シグナル出力されている静的エラーの中に生じる場合があります。 もし、そのエラーが、静的にシグナル出力されない場合には、命令が評価される際にシグナル出力されるでしょう。

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 PropertiesDM)で記述したマッピングによって 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:attributexsl:copyxsl:copy-of に作用します。

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

19.2.2 文書ノードを有効にする(妥当とする)

それは、文書ノードに妥当性検証を適用する事を可能とします。 これは、命令 xsl:documentxsl:result-documentxsl:copy 、または、 xsl:copy-of の1つによって新しい文書ノードが構築される場合に生じ、 そしてまた、この命令は、 type 属性、または、値 strict 、または、 lax を伴う validation 属性を持ちます。

文書レベル妥当性検証は、可変結合要素が、存在しない select 属性と存在しない as 属性を持つ場合に暗黙のうちに作成される文書ノードに適用されるわけではありません (参照先: 9.4 文書ノードを暗黙のうちに作成する)。 これは、xsl:document における validation="preserve" を利用する事で評価する事と等価です: このようなツリーにあるノードは、それらのタイプ注釈をそのままにして残します。 とてもよく似た事は、妥当性検証は、 xsl:message を利用して作成した文書ノードに適用されるわけではありません。

validation="preserve"validation="strip" は、妥当性検証要求をしません。 最初のケースでは、新しい文書ノードをルートとしたツリーにある全ての要素と属性ノードは、それらのタイプ注釈がそのまま残されます。 2つめののケースでは、ツリーにある要素は、属性が xs:untypedAtomic に設定されるそれらのタイプ注釈を持つ場合に、 xs:untyped に設定されるそれらのタイプ注釈を持ちます。

妥当性検証が文書ノードにおいて要求される際 ( validationstrict 、または、 lax に設定される際、または、 type 属性が存在する際)には、 次に続く処理が行われます:

  • [ERR XTTE1550] 文書ノードの子が確実に1つの要素ノードで構成される、 存在しないテキストノード、ゼロ以上のコメント、そして、いくつかの命令の中にある処理命令ノードである場合を除き、 タイプエラーが出現します。

  • 単独の要素ノード子は、19.2.1 構築した要素と属性を妥当性検証するで記述したように、 提供した validationtype 属性の値を利用して妥当性検証されます。

    注釈:

    文書ノードをコピーする際、xsl:document xsl:result-document 、また、 xsl:copyxsl:copy-of における type 属性は、 このように、文書ノードの子要素のみである要素ノードの要求タイプを参照します。 つまり、文書ノードそれ自身のタイプを参照するわけではありません。

  • 妥当性検証規則 『Validation Root Valid (ID/IDREF)』は、文書ノードの単独の子要素ノードに適用されます。 これが意味するところは、その妥当性検証は、もし、文書ツリーに一意ではない ID 値がある場合や未解決となっている IDREF 値がある場合には、失敗するでしょうという事です。

  • アイデンティティ(同一性)制約は、[XML スキーマ Part 1]のセクション 3.11で定義したように、チェックされます。 (これは、 xs:uniquexs:keyxs:keyref を利用して定義した制約を参照します。)

  • 存在しないチェックがあり、それは、ツリーが、タイプ xs:ENTITY 、または、 xs:ENTITIES のノードの値とマッチする名前である解析しない実体を含みます。
    (=ツリーが、タイプ xs:ENTITY 、または、 xs:ENTITIES のノードの値とマッチする名前である解析しない実体を含んではいけないというチェックは存在しません。)
    なぜなら、これは、結果ツリーにある解析しない実体を作成する為の XSLT 2.0 にある存在しない利便性があるからです。 それは、シリアライゼーション中に妥当なDOCTYPEを参照する事によって結果文書に解析しない実体宣言を追加する事を可能とします。

  • 存在しないチェックがあり、それは、文書が、タイプ xs:NOTATIONのノードの値とマッチする名前である注釈を含みます。
    (=文書が、タイプ xs:NOTATIONのノードの値とマッチする名前である注釈を含んではいけないというチェックは存在しません)
    なぜなら、これは、注釈が XDM データモデルの一部ではないからです。 それは、シリアライゼーション中に妥当なDOCTYPEを参照する事によって結果文書に注釈を追加する事を可能とします。

  • 文書ノードの他の全ての子(コメントと処理命令)は、変更されずにコピーされます。

[ERR XTTE1555] もし、妥当な文書ノード、文書レベル制約が満たされない場合には、タイプエラーです。 これらの制約は、同一性制約 ( xs:uniquexs:keyxs:keyref )と ID/IDREF 制約を含みます。

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


ウェブ造ホーム前へ次へ