【Data Model / データモデル】XSLT 2.0/XSL Transformations Version2.0/Extensible Stylesheet Language Transformations Version2.0

4.1 XMLバージョン

[データモデル]で定義したXDMデータモデルは、 ([XML 1.0]と[XML1.0における名前空間]とが一致する)XML 1.0文書か、 または、([XML 1.1]と[XML 1.1における名前空間]とが一致する)XML 1.1文書のいずれかの提示性能があり、2つの間の識別なく作成します。 原則では、それゆえに、XSLT 2.0は、これらのXMLバージョンのいずれかを伴って利用される事が可能です 。

XDMツリーの構築は、この仕様のスコープ外であり、その為、XSLT 2.0は、XML 1.0文書、または、XML 1.1文書、または、両方からのいずれかの入力を許容する為にXSLTプロセッサ上の公式な要求のない位置決めです。 この仕様は、シリアライゼーション性能(参照：20 シリアライゼーション)を定義します、けれども、一致する視点からそれは、付加的な特性です。 たとえ、利便性が、XML 1.0、または、 XML 1.1 (且つ、選択操作をする事)のいずれかとしてXDMツリーをシリアライズする為に記述されるとしても、 それらは、XSLTプロセッサにおいてシリアライゼーション目標としてこれらのXMLバージョンのいずれか、または両方をサポートする事における公式な要求は、繰り返しますが、ありません。

XDMツリーは、同一なので、 オリジナル文書が、XML 1.0だったのか、または、XML 1.1だったのかについては、XSLTプロセスのセマンティクスは、オリジナル文書によって利用したXMLのバージョンに依存しません。 これらは、なぜ、全ての入力文書と出力文書が、XMLの同じバージョンと一致しなければならない単独の変換の中で利用したのかという原理における理由はありません。

XSLT 2.0とXPath2.0にある統語的な構築のいくつかは、例えば、 Char^XML生成と NCName^Names生成は、XMLとXML名前空間仕様の参照によって定義されます。 XML 1.0とXML 1.1というのは、これらの製品のバージョンというバリエーションに過ぎません。 表記は、いずれかのバージョンをサポートする場合があります。； それは、1.0バージョンのサポートモードをも提供すべき、1.1バージョンを満たすXSLT 2.0プロセッサが推奨されます。 それは、このようにXSLTプロセッサが、XML名前空間 1.0を伴うXML 1.0、または、XML名前空間 1.1を伴うXML 1.1をサポートする、または、ユーザーオプションで両バージョンをサポートするかどうかは、implementation-definedです。

記述の時点では、XML 1.1 仕様を参照する[XML スキーマ Part 2]の発行されたバージョンはありません。 これが意味するところは、XML 1.0規則によって制約されたxs:NCNameとxs:IDのようなデータタイプという事であり、更にXML 1.1によって許可した値の範囲を満たす事を許容しないという事です。 このシチュエーションは、利用可能となる[XML スキーマ Part 2]の新しいバージョンまで解決されないでしょう。； それまでは、それは、手引きとして[XML スキーマ 1.0 と XML 1.1]を協議すべきXML 1.1をサポートする事を期待している手段が推奨されます。 XSLT 2.0プロセッサは、それらが利用可能となるものとして[XML スキーマ Part 2]の後継バージョンにある規則を満たすべきXML 1.1をサポートします。

4.2 スタイルシートからホワイトスペースを取り除く

ツリー表示するスタイルシートは、次に続くように事前処理されます：

1. 全てのコメントと処理命令は、削除されます。

2. いくつかのテキストノードは、現在互いに隣り合うものごとにマージされます。

3. いくつかのホワイトスペーステキストノードは、次に続くツリーから削除される条件の両方を満たします。：

   • テキストノードの親は、xsl:text要素ではない。

   • テキストノードは、defaultの値を伴うxml:space属性を持っている閉じた先祖要素となるまでpreserveという値を伴うxml:space属性を持つ先祖要素を持っていない。

4. いくつかのxml:space属性に関係なく、次に続く要素の1つである親がツリーから削除されるいくつかのホワイトスペーステキストノード

   xsl:analyze-string
xsl:apply-imports
xsl:apply-templates
xsl:attribute-set
xsl:call-template
xsl:character-map
xsl:choose
xsl:next-match
xsl:stylesheet
xsl:transform

5. following-sibling ノードがxsl:paramである、または、いくつかのxml:space属性に関係なく、ツリーから削除されるxsl:sort要素にあるいくつかのホワイトスペーステキストノード。

[ERR XTSE0260] XSLT 要素では、カラにする事を要求されないコメントではない、いくつかのコンテンツ、または、処理命令、 xml:space="preserve"属性を利用して保存した、含んでいるいくつかのホワイトスペーステキストノード がある場合には、静的エラーです。

4.3 ソースツリーからタイプ注釈を取り除く

[定義：  用語type annotationは、ノードの先祖dm:type-nameによって返した値を参照するこの仕様の中で利用されます。: 参照： セクション 5.14 タイプ名 Accessor^DM. ]

これらは、時々、スキーマに対して妥当なソース文書か、そうでないかで同じ結果を生成するスタイルシートを書く為に要求します。 これを達成する為に、要素ノードのケースでは、xs:untyped、そして属性ノードのケースでは、xs:untypedAtomicの表記を伴うそれらを置換するソースツリーにある要素と属性ノード上のいくつかのタイプ注釈を削除する為にオプションが提供されます。

このようにタイプ注釈から取り除く事は、xsl:stylesheet要素上でinput-type-annotations="strip"を記述することによって要求される事が可能です。 この属性は、(次の)3つの値を許容しています。: strip、preserve、unspecified。 既定値は、unspecifiedです。 input-type-annotations="strip"を記述するスタイルシート内に少なくとも1つスタイルシートモジュールがあれば、タイプ注釈の除去は、位置を取得します。

[ERR XTSE0265] もし、input-type-annotations="strip"を記述するスタイルシートにスタイルシートモジュールがあり、 更に、input-type-annotations="preserve"を記述するその他のスタイルシートモジュールがある場合には、それは、静的エラーです。

これを適用するソースツリーは、 xsl:strip-spaceとxsl:preserve-spaceによってそれらが同じ影響を受けます。： 参照：4.4 ソースツリーからホワイトスペースを取り除く。

タイプ注釈が取り除かれる際、次に続く変更点は、ソースツリーに作られます。：

• 要素ノードごとのタイプ注釈は、xs:untypedに変更されます

• 属性ノードごとのタイプ注釈は、xs:untypedAtomicに変更されます

• 要素と属性ノードごとのタイプ値は、xs:untypedAtomicのインスタンスのようにそのstring値と同じになるようにセットされます。

• 要素ノードごとのis-nilledプロパティは、falseにセットされます。

is-idとis-idrefsプロパティの値は、変更されません。

4.4 ソースツリーからホワイトスペースを取り除く

変換処理に入力として提供したソースツリーは、 関係のない、変換によって保持される必要のないホワイトスペーステキストノードを含む場合があります。 概念としては、XSLTプロセッサは、無用の削除されているホワイトスペーステキストノードからソースツリーをコピーします。 このプロセスは、ホワイトスペース除去として参照されます。

このセクションの目的においては、用語ソースツリーは、初期文脈ノードを含んでいる文書、更に 関数document、doc^FO、または、 collection^FOによって返したいくつかの文書を意味します。 それは、スタイルシートパラメータの値として通過させる文書、または、拡張関数から返した文書を含みません。

除去プロセスは、保存される為にある子ホワイトスペーステキストノードの要素名のセットを入力として受け取ります。 この要素名のセットにおける実装は、 xsl:strip-space 、更に、このセクションに後から記述されるxsl:preserve-space宣言を利用して確立されます。

ホワイトスペーステキストノードは、もし、次に続く適用のいずれかである場合には、保存されます。：

• テキストノードの親の要素名が、whitespace-preserving 要素名のセットの中にある。

• テキストノードの先祖要素が、preserveの値を伴うxml:space属性とdefaultという値を伴うxml:spaceを持つ閉じていない先祖要素を持つ。

他方で、ホワイトスペーステキストノードは、除去されます。

xml:space属性は、ツリーから削除されません。

<!-- カテゴリ： 宣言 -->
<xsl:strip-space
  elements = tokens />

<!-- カテゴリ：宣言 -->
<xsl:preserve-space
  elements = tokens />

whitespace-preserving 要素名のセットは、xsl:strip-spaceとxsl:preserve-space宣言によって記述されます。 whitespace-preserving 名のセットで含まれる要素名かどうかは、全てのxsl:strip-space、または、xsl:preserve-space宣言の間でのベストマッチによって決定されます。： もし、マッチするものがない、または、ベストマッチがxsl:preserve-space要素である場合に限り、それが含まれます。 xsl:strip-spaceと xsl:preserve-space各要素は、値がNameTests^XPのホワイトスペースで区切られたリストであるelements属性を持ちます。； ある要素名は、もし、それがNameTests^XPの1つとマッチする場合には、 xsl:strip-space、または、 xsl:preserve-space要素とマッチします。 もし、NameTest^XPが、XPathノードテストのような要素において「true」となるであろう場合に限り、 ある要素は、NameTest^XPとマッチします。 xsl:strip-spaceとxsl:preserve-space要素が、1つ以上マッチする際には、 ベストマッチしている要素は、ベストマッチしているNameTest^XPによって決められます。 これは、テンプレート規則を伴うように同じ方法で決められます。：

• まず、無視されるそれ以外のマッチではない、最も低い取り込み優先度を持ついくつかのマッチ

• 次に、無視されるその他の既定優先度のマッチではない、いくつかの最も低い既定優先度を持つマッチ

[ERR XTRE0270] もし、 この残りが1つ以上あり、全ての一致する宣言が等価になるまでマッチする場合には、 それは、回復可能な動的エラーです。 (それは、それらが全てxsl:strip-spaceである、または、それらが全てxsl:preserve-spaceであるという事です)。 付加的な回復動作は、宣言指定にある最後に生じる左側にあるマッチから選択される事です。

もし、ソース文書にある要素が、単純なタイプ、または、単純な内容を持つ複雑なタイプであるタイプ注釈を持つ場合には、 その子同士の間にあるいくつかのホワイトスペーステキストノードは、いくつかのxsl:strip-space宣言に関係なく、保存されます。 これは、妥当な要素を作るであろう単純な内容を伴う要素からホワイトスペーステキストノードを除去するからです。： 例えば、違反されるfacet値であるminLengthを原因とする事が可能でした。

タイプ注釈の除去は、ホワイトスペーステキストノードの除去前に起きます、その為、このシチュエーションは、もし、input-type-annotations="strip"が記述される場合には、生じないでしょう。

4.5 属性タイプとDTD妥当性

[データモデル]で記述したXDMデータモデルへの情報セットからのマッピングは、属性タイプを保持しません。 これが意味するところは、 例えば、NMTOKENSという属性タイプを持っているものとしてDTDに記述した属性は、 xs:NMTOKEN値のシーケンスではなく、単独のxs:untypedAtomic値で構成するであろうxs:NMTOKENSとその区分した値ではなく、 xs:untypedAtomicとしてXDMツリーで表記されるでしょう。

ID、IDREF、または、IDREFSというDTDに由来したタイプを持つ属性は、 is-id、または、is-idrefsプロパティを持っているものとしてXDM ツリーにマークされるでしょう。 それは、[関数と演算子]で記述した関数id^FOとidref^FOによって審査されたタイプ注釈ではなく、これらのプロパティです。

4.6 制限

XDMデータモデル(参照先： [データモデル])は、制限を定義する為にホスト言語(ここではXSLT)にそれを委ねます(任せます)。 このセクションは、XSLTに適用する制限を記述します。

いくつかの旧式のデータタイプにおける制限は、[XML スキーマ Part 2]で定義されます。 以下に列挙したその他の制限は、implementation-definedです。 注記としては、これは、それぞれの制限は、単純な定数にしなければならないという意味である必要性はないという事です。： それは、利用可能なリソースのような環境要因への依存を多様にします。

次に続く制限は、implementation-definedです：

1. xs:decimalタイプについては、十進桁の最大値(totalDigits facet値)。 これは、少なくとも18桁にしなければいけません。 (注記、しかしながら、xs:unsignedLongの範囲を満たす値におけるサポートは、20桁を要求します。)

2. xs:date、xs:time、xs:dateTime、xs:gYear、xs:gYearMonthのタイプにおいては、： 年号コンポーネントの値の範囲は、少なくとも[+0001]～[+9999]にしなければいけません； 2桁表示の最大値は、少なくとも3桁にしなければいけません(and the maximum number of fractional second digits、 which must be at least 3)。

3. xs:durationタイプについて：年、月、日、時、分、秒コンポーネントの最大絶対値。

4. xs:yearMonthDurationタイプについて：月の整数値として表現した最大絶対値。

5. xs:dayTimeDurationタイプについて：秒の十進値として表現した最大絶対値。

6. xs:string、xs:hexBinary、xs:base64Binary、xs:QName、xs:anyURI、xs:NOTATIONタイプとそれらから派生するタイプについて：値の最大長。

7. シーケンスについては、シーケンスにあるアイテムの最大値。

4.7 利用不可能な出力エスケープ

後方互換性根拠において、XSLT 2.0は、XSLT 1.0で紹介したdisable-output-escaping特性のサポートを継続します。 これは、付加的な特性と手法は、それをサポートする為に要求されないという事です。 新しい利便性は、XSLT 2.0の中で紹介される文字列マップ(参照先： 20.1 文字列マップ)に名前を付けるという事です。 それは、データモデルをゆがめることのないdisable-output-escapingにおける性能にとても近いものです。

もし、xsl:textとxsl:value-of(参照：20.2 出力エスケープを利用不可にする)のdisable-output-escaping属性をサポートするimplementationがある場合には、 プロセッサによって構築したツリーにおけるデータモデルは、このプロパティの値を表示するboolean値を伴い増大させます。 このboolean値は、しかしながら、シリアライザーを通過させている最終結果ツリー内に限り、設定させる事が可能です。

観念としては、そのような結果ツリー上にあるテキストノードにあるそれぞれの文字は、この文字、または、属性ノードに関連する特殊文字(例えば、&としての&出力)のエスケープにおける通常規則を表示する為にあるシリアライザーかどうかを示しているbooleanプロパティを持っています。