[13] 文書順document orderは、 DOM や XDM における節点の順序関係です。 文書順では、 XML による文字列表現において、当該節点を表す最初の文字の位置の前後が順序の前後となります。

[19] XML や W3C DOM の時代によく用いられていた用語ですが、 現在ではあまり用いられていません。似た意味の用語に木順があり、 こちらが一般的となっています。

仕様書

[5] 「文書順」という用語は複数の仕様書がそれぞれ定義しています。 データ・モデルの違いが微妙に定義の違いとなっていますが、実質的な意味はほぼ同じです。

基本的な定義

DOM、XPath 1.0 データ・モデルにおける定義

[1]

There is an ordering, document order, defined on all the nodes in the document corresponding to the order in which the first character of the XML representation of each node occurs in the XML representation of the document after expansion of general entities.

文書順は、文書中のすべての節点に関して定義される順序であり、 文書のXML表現で一般実体を展開した後の各節点のXML表現の最初の文字の順序に対応します。 >>10 (XPath 1.0), >>9 (DOM)

XDM における定義

[43] XDM での定義 >>42 は、実質的には XPath 1.0データ・モデルでの定義と同じですが、 XML 表現による定義を「非形式的informal」なものとして紹介した上で、 >>15 などのような満たすべき制約を述べて規定とする形に変わっています。

後述のように木に対してではなく木の集合に対する定義になっているところは違います。

XML 情報集合における定義

[6] XML情報集合仕様書でも文書順を定義に使っていますが、 その「文書順」という用語の定義がありません。

属性の文書順

DOM、XPath 1.0 データ・モデルにおける定義

[23] XPath 1.0データ・モデルでは属性節点の他に名前空間節点があります。 どちらも XML の開始タグの属性に相当するとみなされ、 要素自体よりは後、子供よりは前になります。

[38] DOM 本体には名前空間節点が存在しないので、その部分の定義は省略されていますが、 DOM XPath で名前空間節点が導入されており、 XPath 1.0 同等の定義に拡張されています。

[18]

The namespace nodes are defined to occur before the attribute nodes.

名前空間節点は属性節点の前に出現すると定義します。 >>10 (XPath 1.0), >>36 (DOM XPath)

[22]

The relative order of namespace nodes is implementation-dependent. The relative order of attribute nodes is implementation-dependent.

名前空間節点の相対順序は実装依存です。 >>10 (XPath 1.0), >>36 (DOM XPath) 属性節点の相対順序は実装依存です。 >>10 (XPath 1.0), >>9 (DOM)

[28] この「実装依存」について、順序が同じ実装内では一貫していなければならない、 といった類の規定がありません。ランダムでもいいということでしょうか。

[46] XDM の定義では順序は安定でなければならないとされています >>42。

[50] compareDocumentPosition メソッドの動作は「文書順」 の定義によらずに独自に定義されていますが、そちらでは多少明確に「安定」 でなければならないことが規定されています。

正準 XML における定義

[24] 正準XML は XPath 1.0データ・モデルに基づいていますが、 名前空間節点と属性節点の順序を規定しています。

[4] 正準XML においては、名前空間節点の文書順は局所名の辞書式順序になります。 ただし、既定名前空間の宣言 (修飾名が xmlns) は一番先になります。

属性節点の文書順は、最初に名前空間URI、2番目に局所名を使った辞書式順序になります。 ただし、null名前空間は一番最初になります。

ここで、辞書式順序とは UCS の符号位置の順序になります。 C14N, 2.2

文書型宣言内の文書順

[29] XPathデータ・モデルでも DOM でも、「一般実体を展開した後」とは言っていますが、 引数実体には触れられていません。 XPathデータ・モデルは引数実体の位置に依存する節点はありませんが、 DOMやXML情報集合には存在します。

[7] XML情報集合では、処理指令情報項目の子供特性では内部部分集合が外部部分集合より前ということが特に規定されています。 >>30 引数実体については触れられていません。

[31] 実はこの箇所は「original document order」といっていて、用語としての「文書順」なのか 一般名詞として「元の文書の順序」と述べているに過ぎないのか不明瞭です。[51] compareDocumentPosition メソッドの動作は「文書順」 の定義によらずに独自に定義されていて、XML 表現によらずに DOM 構造上の位置によって決まることになっています。

実体参照の文書順

[40] DOM には EntityReference 節点が存在することになっていますが、 >>1 の規定が「一般実体を展開した後」とされているため、展開されて消滅するであろう EntityReference 節点の順序は厳密には不明瞭です。

[49] compareDocumentPosition メソッドの動作は「文書順」 の定義によらずに独自に定義されていて、この問題を回避しています。 その動作によれば、実体参照節点でない他の節点であった場合と同じような順序を持ちます。

文書外の節点の文書順

[41] DOM で文書に挿入されていない節点であったり、 DocumentFragment 節点であったり、 XSLT 1.0 の結果木素片であったりと、 文書に所属していない節点が存在することがあります。 厳密には、これらに対する「XML 表現」が何であるのかがどこでも定義されていないので、 文書順の定義も明確ではありません。また、 このような部分木を超えた文書順の定義も明確にされていません。

[44] XDM における定義では、木同士に実装依存の順序があり、 そのなかで各節点の順序があるとされています。 >>42

[50] compareDocumentPosition メソッドの動作は「文書順」 の定義によらずに独自に定義されていますが、そちらでは明示的に実装規定となっています。

文書を超えた文書順

[25] XSLT 1.0 は XPath 1.0データ・モデルに基づいていますが、 document() 関数によって異なる文書の節点が混在することがあるので、 文書を超えた文書順を定めています。

[26] 異なる文書の節点の順序は、それぞれの文書の順序によって決定します >>11。

[2] 文書の順序は実装依存です。ただし、その順序は当該実装の中では一貫していなければなりません。 >>11

[3] >>2 文書が同じであるとは、その (絶対) URI (素片識別子を取り除いたもの。) が同じであることです XSLT 1.0。どの程度同じなら同じかは触れられていません。 (URI の正規化をするのかしないのか。。。)

[27] >>2 この一貫性というのがどの程度維持されていなければならないかについて、 XSLT 1.0 は「同じ文書の集合については必ず同じ順序を使わなければならない」 としていますが、この規定はそれほど明確ではありません。 別のXSLTスタイル・シートを処理する時にも同じ文書の集合が対象だったら同じ順序でなければならないのでしょうか (これはきっとそうであることを意図しているのでしょう)。 同じXSLTスタイル・シートを処理するときに別のプロセスであっても同じ順序でなければならないのでしょうか。 対象となる文書が編集されたとしたら、その前と同じ順序を維持しなければならないのでしょうか (「実装依存」の方法が「ファイルの編集時刻に依存して順序を決定する」とするなら、そうであっても規定の範囲内にはなりますね)。

[45] XDM における定義では、木同士に実装依存の順序があり、 そのなかで各節点の順序があるとされています。 >>42

[48] compareDocumentPosition メソッドの動作は「文書順」 の定義によらずに独自に定義されていますが、そちらでは明示的に実装規定となっています。 更に、異なる DOM 実装の節点同士の比較についても言及があります。

系

関連

[14] 文書順の逆の逆文書順もあります。

[39] DOM には文書順を比較する compareDocumentPosition メソッドがあります。

[47] Web Applications 1.0 では文書順に似た「木順」という順序関係が定義されています。

[52] IE には文書順に似た「ソース順」に基づく sourceIndex 属性があります。

メモ

[8] IT戦記 - ノードの集合を「ドキュメント順」に高速に並べ替える。その1 (2007-09-04 22:12:32 +09:00 版) http://d.hatena.ne.jp/amachang/20070903/1188844070

[55] XQuery 3.0: An XML Query Language ( ( 版)) http://www.w3.org/TR/xquery-30/#id-document-order

[56] XML Path Language (XPath) 3.0 ( ( 版)) http://www.w3.org/TR/xpath-30/#id-document-order

[57] XQuery and XPath Data Model 3.0 ( ( 版)) http://www.w3.org/TR/xpath-datamodel-3/#document-order

[20] RFC 7950 - The YANG 1.1 Data Modeling Language () https://tools.ietf.org/html/rfc7950#section-6.4

The data tree has no concept of document order. An implementation

needs to choose some document order, but how it is done is an

implementation decision. This means that XPath expressions in YANG

modules SHOULD NOT rely on any specific document order.

[21] XQuery 3.1: An XML Query Language () https://www.w3.org/TR/2017/REC-xquery-31-20170321/#id-document-order

[33] XML Path Language (XPath) 3.1 () https://www.w3.org/TR/2017/REC-xpath-31-20170321/#id-document-order

[34] XQuery and XPath Data Model 3.1 () https://www.w3.org/TR/2017/REC-xpath-datamodel-31-20170321/#dt-document-order

[35] [css-display-3] Define “document order” since we use it in many place… (fantasai著, ) https://github.com/w3c/csswg-drafts/commit/c2d98a3c518b47ad73e653b707a7d8e8d7f8d3c3