base URL change steps

Node インターフェイス baseURI 属性 (DOM)

[67] NodebaseURI 属性は、 文書の基底URLを返します。

仕様書

意味

[99] 要素の基底URL (the element's base URL) は、 要素節点文書基底URLです >>34

[98] かつては節点が異なる基底URLを持つことがあるとされていました。 例えば XML には xml:base 内容属性がありました。 しかし現在ではそうした機能は削除され、文書全体で1つの基底URL を持つことになっています。

取得器

[30] 取得器は、文脈オブジェクト節点文書文書基底URLURL直列化器を通して得た DOMString を返さなければなりません >>29

[33] base 要素によって文脈オブジェクト節点文書文書の基底URL が変更されると、本属性値も自動的に変化します。

設定器

[31] baseURI 属性読み取り専用です >>29設定器はありません。

[23] 変更したい時は、 base 要素によって文書の基底URL を設定する必要があります。

基底 URL の変更の影響

[97] DOM/HTML基底URLの定義の再編 (>>95) 途中のため本節の内容は仕様書上不整合になっています。技術的な内容は変化しないと思われます。

[75] 要素基底URLの変更に影響される (affected by a base URL change) 時、 基底URL変更手順を実行しなければなりません >>74

[78] 要素が基底 URL の変更に影響されるのは次の場面です。

[86] HTML Standard子孫要素も明示的に含まれるとしていますが、 DOM Standard はそうしていません (adopt は再帰的な手順でもありません)。また adopt要素を挿入した時に呼び出されますが、逆に要素を削除した時には >>78 のいずれも該当しません。また >>83文書に所属し、文書中にはない要素についてはカバーしていません。 とはいえ、現時点では >>77 のいずれもこれらの点の影響を受けません。

[77] 基底URL変更手順 (base URL change steps) >>76 には次のものがあります。

[87] つまりリンク先の表示に影響があり、また実際にリンクをたどる時にはその時点での基底URLに基づき解決されるわけですから、 自動的に基底URLの変更が反映されることになります。一方で、埋め込み系の URL (src 属性スタイル・シートを埋め込む link 要素など) は基底URLが変化してもそれに追随しません。ただし IDL属性src などは取得した時点での基底URLに対して解決されますから、実際に使われている URL とは違うことがあります。

歴史

基底 URI (XSLT データ・モデル)

[26] XSLTデータ・モデルにおいても基底 URI の概念があります。 なお、 XSLT 1.0XSLT 1.1データ・モデルの礎となっている XPath 1.0データ・モデルにはそれに相当する概念はありませんでした。

[35] XSLT 1.0 では、基底URI は各節点について規定されています。

XSLT 1.0XML基底以前に定義されたものなので、 xml:base 属性は反映されません。

[36] XSLT 1.1 では、基本的に XML基底に従って基底URI が算出されます。

節点と基底 URI

[24]

XSLT 1.0XSLT 1.1
文書節点文書実体URI(規定なし)
根節点(規定なし)文書実体URI
要素節点外部実体中なら外部実体URI、そうでなければ文書基底URIXML基底による
処理指令節点外部実体中なら外部実体URI、そうでなければ文書基底URIXML基底による
文節点, 注釈節点, 属性節点親節点基底URI
名前空間節点親節点基底URI実装依存
非解析対象実体システム識別子実体宣言を含む資源基底URI

XML基底特性 (XML情報集合)

[40] XML情報集合基底URI (base URI) 特性は、 その情報項目基底URIを値として保持します。 この特性は、

で定義されています。

特性値

文書情報項目の場合

[43]

  1. 文書実体基底URIです。 XML情報集合 2.1
  2. XML基底仕様に従います。 XML情報集合 1
  3. RFC 2396に従います。 XML基底 4

[44] XML基底の仕様書の内容には多少曖昧な点もありますが、 RFC 2396の規定と矛盾する規定を行う意図はなさそうなので、

  1. 転送プロトコルによってもたらされた基底URI
  2. 文書実体取出しに用いたURI (リダイレクトがある場合は、最終的なURI)
  3. 応用の文脈に依存したURI

の順で決定するものと思われます。

要素情報項目の場合

[45]

  1. 要素基底URIです。 XML情報集合 2.2
  2. XML基底仕様に従います。 XML情報集合 1
  3. xml:base属性の項を参照。

処理指令情報項目の場合

[46]

  1. 処理指令基底URIです。 XML情報集合 2.4
  2. XML基底仕様に従います。 XML情報集合 1
  3. xml:base属性の項を参照。

エスケープ

[47] xml:base属性URI参照として使うためには逃避 (エスケープ) が必要です (xml:base属性の項を参照してください。) が、特性値はそののものです。 XML情報集合 1

応用依存

[48] XML基底仕様で基底URI応用依存になる場合に関して、 XML情報集合仕様は基底URIの値を規定しません。 XML情報集合 1

[15] DTD処理するか否かによって結果が異なり得る特性では無値未知になることもありますが、 基底URIではそれは無いようです。 DTD処理しない場合に関してもXML基底仕様で基底URIが明確に定義されているためでしょうか。 (実際DTD処理していないからといって無値未知にされては役に立ちませんしw)

URL の定義

[37] XDM基底URI非ASCII文字を含むことがあるとしています。

SML の基底 URL

[49] SML-IF では基底URIに関する2種類の処理モデルが定義されています。 1つはXML基底に基づく xml:base 属性を使った標準的な方法で、 もう1つは互換性のための独自の方法です。SML-IF消費器はいずれかを実装しなければなりませんSML-IF生産器は前者の xml:base 属性の方法は実装しなければなりませんが、 後者の独自の方法の実装は義務付けられていません。 SML-IF

smlif:baseURI 機構

[51] SML-IF 独自の処理モデルである smlif:baseURI 機構 (mechanism) では、 要素情報項目基底URI を次のように決定します。 SML-IF

  1. 当該要素情報項目交換モデル中の文書の一部なら (先祖要素smlif:locator などなら)、文書基底URIです。文書基底 (document base) URI とは、次の RFC 3986 絶対URI です。
    1. docInfo/baseURI 要素が存在する場合、その値が相対参照なら交換モデル基底URI について解決したもの、相対参照でないなら値そのものです。
    2. そうでなく、交換モデル基底URI が値を持つ場合、その値です。
    3. そうでない場合、値を持ちません。
  2. そうでない場合、交換モデル基底URIです。交換モデル基底 (interchange model base) URI は、 /model/identity/baseURI 要素が存在する場合はその値、そうでない場合は値なしです。

[52] SML-IF では相対参照が必要な場合に本処理モデルに基づく、あるいは xml:base 属性による基底URL の明記が義務付けられており、相対参照解決においてより上位の基底URL (文書実体URL など) が用いられることはないとされています SML-IF。 ただし >>30 からわかるようにその規定が従われなかった場合に基底URI値なしになってしまうことがあります。また、SML-IF生成器も2つの処理モデルのいずれかのための基底URL を指定することしか義務付けられていないので、 SML-IF消費器側が異なる処理モデルを選択している場合にも基底URI値なしとなりえます。

関連

[53] 合成情報集合 (XML文書から生成してすぐの情報集合以外) では、基底URIxml:base属性情報項目に齟齬が生じていることもあります。 XML情報集合 1

[54] 外部実体の直下に処理指令がある場合、 その外部実体基底URI処理指令基底URIになりますが、 処理指令情報項目を含む情報集合直列化する時にその基底URIの情報は保存する方法がありません。 XML情報集合 2.4

[55] 非解析対象実体情報項目記法情報項目には、 宣言基底URIという特性が定義されています。

[56] DOMbaseURI特性基底URIではなく、 xml:base属性に基づき定義されています。

[57] XIncludeでは基底URIを保存するためにxml:base属性を追加して整合性を維持することがあります。

[58] 基底URIxml:base属性では、 基底URIの方を優先して相対参照解決に使うべきとされています。 XML情報集合 1

[59] RDF/XML構文を定義する事象モデルでは、 事象要素事象base-uriアクセス子があり、 共に基底URI特性から値を得ることとされています。

[60] XPath 1.0データ・モデルには、 基底URIに相当するものがありません。

XSLT 1データ・モデルにおける基底URI相当のものに関しては、 >>26 を参照してください。

DOM3 における baseURI 属性

[3] DOM水準3Node界面に追加された読取専用属性baseURIは、 その節点基底URIを表します。

XML DOMの場合の属性値

[2] DOM3 中核

  1. XML基底に従って計算し、得た絶対URIです。 (URIDOM URIの意味か?)
  2. 得られなかった場合は、 nullとします。

[3] 実体参照を保存している場合は良いのですが、 そうで無い場合は外部実体中の基底URI情報が失われてしまいます。

[14] DocumentType, Comment, Entity, Notation, EntityReference, DocumentFragment, XPathNamespace (DOM水準3 XPath <IW:DOM3:"XPath/xpath.html#XPathNamespace">) に関しては、相当する規定が参照されているXML基底仕様書に含まれていないので、 どんな値になるべきなのかがよくわかりません。

それ以外の種類の節点も、XML基底DOMの附属書の規定 (>>8-13) に矛盾か見られます。

[16] 部分木

Document節点から連なる主となるに属さない節点 (例えば、createElementNSしたばかりの節点)(そもそもそのようなものがない) XML仕様では基底URIが規定されていませんが、 DOMの仕様書でも規定されていません。

HTML DOM の場合の属性値

[4] Document機能 HTML (DOM水準2 HTML仕様が参照されています。) に対応している場合 DOM3 中核:

  1. base要素href属性があれば、その値を使って計算します。
  2. 無い場合は、Document.documentURIです。

[5] documentURIbaseURIとは違って読書両用です。 その定義には、設定時に字句的なチェックはしないので、 baseURInullになることもある DOM3 中核 とされています。 絶対URI以外が指定された場合はdocumentURIからbaseURIを定められないという意味でしょうか。 よく読むとdocumentURIの定義には、 属性名以外でその値がURIであるとは一言も述べられていません。 どうしろというのでしょうか。

関連

[6] 合成情報集合では基底URIxml:baseを計算して得られる値が一致するとは限りませんが、 DOMには基底URIに直接相当するものがなく、 常にxml:baseを計算するので、 情報の欠落なくDOMから得られた合成情報集合を直接処理することはできません。

[8] DOM情報集合の写像 DOM3 によれば、文書情報項目Documentでは基底URIbaseURIおよびdocumentURIが対応することになっています。

documentURI (文書の場所) に相当する情報が無い情報集合からDOMへの変換でdocumentURI基底URIを使うのはよいとしても、 逆に基底URIbaseURIから持ってくるのはおかしいです。 DOMbaseURIの定義はXML基底により、 XML基底の定義はRFC 2396に拠っているはずですから、 基底URI文書の所在は必ずしも一致しないはずです。

はずというのは、XML基底の仕様書もなんだかおかしいからです。

[9] DOM情報集合の写像 DOM3 によれば、要素情報項目Elementでは基底URIbaseURIが対応することになっています。

しかし、合成情報集合の場合基底URIを同的に計算されるbaseURIと一致させることができないはずです。 一致させるためには属性に関する特性属性の修正が必要ですが、そのような規定はありません。

[10] DOM情報集合の写像 DOM3 によれば、属性, 文字情報項目からAttr, Text, CDATASection節点への変換でbaseURInullになるとされています。 しかし、これはXML基底によって計算するとした本文の規定と矛盾します。

注釈, 文書型宣言情報項目Comment, DocumentType節点についても同様です。 ただし、baseURI属性の定義が参照するXML基底仕様でマーク宣言基底URIは明確に定義されていません。 (自然に解釈すればそれが含まれる要素または外部実体文書実体と同じでしょうが、ここで外部実体内の注釈宣言に関して処理指令と同じ問題 (>>7) が発生します。)

[11] DOM情報集合の写像 DOM3 によれば、処理指令情報項目ProcessingInstructionではあれば、親要素基底URIbaseURIに、 その処理指令節点baseURI (はあれば親要素baseURIと同じ) がその処理指令情報項目基底URIに対応することになっています。

親要素情報項目がない場合のbaseURIに関する規定がなぜか抜けています。

[12] DOM情報集合の写像 DOM3 によれば、未展開実体参照情報項目EntityReference (子供なし。) では宣言基底URIbaseURIが対応することになっています。

そもそもbaseURIの定義が参照するXML基底仕様では実体参照基底URIなど定義されていないのですが、 普通に解釈すれば実体参照そのものの基底URIはそれが含まれる要素基底URIになるはずです。

一方実体参照によって展開される内容の側からすれば、 EntityReference節点実体そのもの (の1つの実現値) に相当する節点と考えることもできますから、 その実体そのものの基底URIにアクセスできる方が便利です。 (ただし、ここで問題にしているのは未展開参照ですから、 その基底URIはわかっていません。)

DOMの附属書にある宣言基底URIは、 これらいずれとも必ずしも一致しません。宣言基底URI実体宣言の含まれる外部実体基底URIだからです。 本当にそんなもので良いのでしょうか。

XML情報集合では未展開実体参照情報項目システム識別子特性があるので、 その解決のために宣言基底URI特性も用意されたと考えられます。 systemId属性がないEntityReferenfceで一体何に使うのでしょうか。

[13] DOM情報集合の写像 DOM3 によれば、非解析対象実体, 記法情報項目Entity (非解析対象実体。), Notationでは宣言基底URIbaseURIが対応することになっています。

baseURI属性の定義が参照するXML基底仕様にはこれらの基底URIに関する規定がないので、 これでよいものかどうかはよくわかりませんが。。。

[7] 外部実体基底URI実体参照展開すると失われる問題 (>>3) について、DOM仕様書では、DOM構築時にxml:base属性を設定しないといけないかもね、 処理指令では無理だけど、と述べています。 DOM3 中核 1.3.4

それを受けてLS仕様ではpi-base-uri-not-preservedという警告 <IW:DOM3:"LS/load-save.html#LS-LSParser"> が定義されていますが、 要素に関しては何も (xml:base属性を修正しろなどの) 規定がありません。

00年代の baseURI 属性の実装

[15] Firefox 1.5では、DocumentType, Attr, Comment, TextでもbaseURIと同じ値が得られるようです。

[18] また、Firefox 1.5では、HTML文書であってもxml:base属性が適用されるようです (HTML 5案の規定と一致)。

Document節点baseURIDOM水準3中核仕様の規定通り base要素 (文書中どこにあっても。) による指定が反映されます。 しかし、後からhref属性を書き換えても (xml:base属性でも)節点baseURI (やURI属性) には反映されないようです。

[17] 同じくFirefox 1.5で、主要なに属さない節点の場合は、 属する節点と同じように、ただし必要ならownerDocument属性をたどることによってbaseURIを算出しているようです。

[71] Chrome では文書中にない要素だと空文字列になります。

[72] Firefox では DocumentTypeと同じ基底URLになるようですが、 Chrome では null になります。

[73] URL解決できない場合にあっては、 Firefox はそれを無視してもう一段階上位の基底URLを返すようです。 Chrome空文字列を返すようです。

HTML5

[94] HTML5 によって動的な基底URLの変化の要素への影響が明確化されました。

DOM4

[96] DOM Standard によって仕様書上の概念として基底URLの変更に影響される (>>75)、基底URL変更手順 (>>77) が定義され、 HTML Standard はこれを用いて定義する形に改められました。

節点の基底 URL

[65] 節点基底 URL (base URL) を持ちます >>64

[70] ただし DOM Standard は他の仕様書においてそれが定義されるとしており、 具体的にどの仕様書でそれが定義されているのかは明記されていません。

属性値

[68] baseURI 属性DOMString? です >>66

[69] 当該節点基底URLを返します >>66

再び DOM から HTML へ

[95] DOM Standard基底URLの変更に影響される (>>75)、基底URL変更手順 (>>77) の定義は削除され、より一般的な adopting steps に変更されました。基底URL の変化の処理は HTML Standard 側に統合されることになっています >>93

[39] [whatwg] Document's base URI should use the document's *current* address ( ( 版)) <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-July/032565.html>

[19] IRC logs: freenode / #whatwg / 20100913 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20100913#l-1054>

[88] IRC logs: freenode / #whatwg / 20140116 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20140116#l-704>

[90] IRC logs: freenode / #whatwg / 20140207 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20140207#l-546>

[91] Web Applications 1.0 r1821 Define what should happen when the base URL changes, keeping it as lightweight as possible. ( ( 版)) <http://html5.org/tools/web-apps-tracker?from=1820&to=1821>

xml:base 属性の廃止

[100] Remove the "element's base URL" indirection · whatwg/html@199c0c0 ( 版) <https://github.com/whatwg/html/commit/199c0c0569bc0e312bb70bffa8ef2f85231f4cd1>

[101] Fix #131: baseURI is not nullable · whatwg/dom@f69832f ( 版) <https://github.com/whatwg/dom/commit/f69832f96eea6d7fb8028aeac7e12a887db9f5e6>

[102] Fix #118: clarify documentURI/URL and baseURI return a serialized value · whatwg/dom@b4664d6 ( 版) <https://github.com/whatwg/dom/commit/b4664d65f494be62141c85a5efb9c367de8c70bc>

[32] Use USVString for URLs and origins in IDL ( (zcorpan著, )) <https://github.com/whatwg/dom/commit/1bb85a48e07d1000e00bd792d61247b9a5e2e4ae>