[13] 文書順は、 DOM や XDM における節点の順序関係です。 文書順では、 XML による文字列表現において、当該節点を表す最初の文字の位置の前後が順序の前後となります。
[19] XML や W3C DOM の時代によく用いられていた用語ですが、 現在ではあまり用いられていません。似た意味の用語に木順があり、 こちらが一般的となっています。
[5] 「文書順」という用語は複数の仕様書がそれぞれ定義しています。 データ・モデルの違いが微妙に定義の違いとなっていますが、実質的な意味はほぼ同じです。
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)
[43] XDM での定義 >>42 は、実質的には XPath 1.0データ・モデルでの定義と同じですが、 XML 表現による定義を「非形式的」なものとして紹介した上で、 >>15 などのような満たすべき制約を述べて規定とする形に変わっています。
[23] XPath 1.0データ・モデルでは属性節点の他に名前空間節点があります。 どちらも XML の開始タグの属性に相当するとみなされ、 要素自体よりは後、子供よりは前になります。
[38] DOM 本体には名前空間節点が存在しないので、その部分の定義は省略されていますが、 DOM XPath で名前空間節点が導入されており、 XPath 1.0 同等の定義に拡張されています。
The namespace nodes are defined to occur before the attribute nodes.
名前空間節点は属性節点の前に出現すると定義します。 >>10 (XPath 1.0), >>36 (DOM XPath)
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。
compareDocumentPosition
メソッドの動作は「文書順」
の定義によらずに独自に定義されていますが、そちらでは多少明確に「安定」
でなければならないことが規定されています。[24] 正準XML は XPath 1.0データ・モデルに基づいていますが、 名前空間節点と属性節点の順序を規定しています。
[4] 正準XML においては、名前空間節点の文書順は局所名の辞書式順序になります。
ただし、既定名前空間の宣言 (修飾名が xmlns
)
は一番先になります。
属性節点の文書順は、最初に名前空間URI、2番目に局所名を使った辞書式順序になります。 ただし、null名前空間は一番最初になります。
[29] XPathデータ・モデルでも DOM でも、「一般実体を展開した後」とは言っていますが、 引数実体には触れられていません。 XPathデータ・モデルは引数実体の位置に依存する節点はありませんが、 DOMやXML情報集合には存在します。
[7]
XML情報集合では、処理指令情報項目
の子供
特性では内部部分集合が外部部分集合より前ということが特に規定されています。 >>30
引数実体については触れられていません。
[40] DOM には EntityReference
節点が存在することになっていますが、
>>1 の規定が「一般実体を展開した後」とされているため、展開されて消滅するであろう
EntityReference
節点の順序は厳密には不明瞭です。
[41] DOM で文書に挿入されていない節点であったり、 DocumentFragment
節点であったり、 XSLT 1.0 の結果木素片であったりと、
文書に所属していない節点が存在することがあります。
厳密には、これらに対する「XML 表現」が何であるのかがどこでも定義されていないので、
文書順の定義も明確ではありません。また、
このような部分木を超えた文書順の定義も明確にされていません。
[44] XDM における定義では、木同士に実装依存の順序があり、 そのなかで各節点の順序があるとされています。 >>42
[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
[39] DOM には文書順を比較する compareDocumentPosition
メソッドがあります。
[47] Web Applications 1.0 では文書順に似た「木順」という順序関係が定義されています。
[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>
[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>