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

仕様書

意味

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

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

取得器

[30] 取得器は、文脈オブジェクトの節点文書の文書基底URLをURL直列化器を通して得た 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.0 や XSLT 1.1 のデータ・モデルの礎となっている XPath 1.0 のデータ・モデルにはそれに相当する概念はありませんでした。

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

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

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

  • [25] XSLT 1
    • 3.2 Base URI IW:XSLT1:"#base-uri"
    • 3.3 Unparsed Entities IW:XSLT1:"#unparsed-entities"
    • Errata in REC-xslt-19991116 http://www.w3.org/1999/11/REC-xslt-19991116-errata/#E5

節点と基底 URI

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

  • [61] 文書実体・外部実体の基底URIではなくて文書実体・外部実体のURIなのがちょっと・・・。
  • [62] それでいてそうでなければ文書の基底URIとは何事か。 文書実体や文書節点ではなく、文書の基底URIなのか?
  • [63] そもそも文書節点という語も、ここ1箇所でしか出てこない (根節点の誤りか)。

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

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

で定義されています。

  • [41] XML情報集合
    • Base URIs http://www.w3.org/TR/xml-infoset/#intro.baseURIs
    • 2.1. The Document Information Item http://www.w3.org/TR/xml-infoset/#infoitem.document
    • 2.2. Element Information Items http://www.w3.org/TR/xml-infoset/#infoitem.element
    • 2.4. Processing Instruction Information Items http://www.w3.org/TR/xml-infoset/#infoitem.pi
  • [42] XML基底 http://www.w3.org/TR/xmlbase/

特性値

文書情報項目の場合

[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文字を含むことがあるとしています。

  • [38] XQuery 1.0 and XPath 2.0 Data Model (XDM) (Second Edition) ( 版) http://www.w3.org/TR/2010/REC-xpath-datamodel-20101214/#const-infoset-document

SML の基底 URL

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

  • [50] Service Modeling Language Interchange Format Version 1.1 ( 版) http://www.w3.org/TR/2009/REC-sml-if-20090512/#Base_URI

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文書から生成してすぐの情報集合以外) では、基底URIとxml:base属性情報項目に齟齬が生じていることもあります。 XML情報集合 1

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

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

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

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

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

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

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

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

DOM3 における baseURI 属性

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

  • [1] [DOM 3]
    • 中核 1.3.4 Base URIs IW:DOM3:"Core/core.html#baseURIs-Considerations"
    • 中核 Node baseURI IW:DOM3:"Core/core.html#Node3-baseURI"
    • 中核 Document documentURI IW:DOM3:"Core/core.html#Document3-documentURI"
    • 中核 Appendix C: Infoset Mapping IW:DOM3:"Core/infoset-mapping.html"

XML DOMの場合の属性値

[2] DOM3 中核

  1. XML基底に従って計算し、得た絶対URIです。 (URIはDOM 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] documentURIはbaseURIとは違って読書両用です。 その定義には、設定時に字句的なチェックはしないので、 baseURIがnullになることもある DOM3 中核 とされています。 絶対URI以外が指定された場合はdocumentURIからbaseURIを定められないという意味でしょうか。 よく読むとdocumentURIの定義には、 属性名以外でその値がURIであるとは一言も述べられていません。 どうしろというのでしょうか。

関連

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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節点のbaseURIはDOM水準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 はこれを用いて定義する形に改められました。

  • [64] DOM Standard ( 版) http://dom.spec.whatwg.org/#concept-node-base-url
  • [66] DOM Standard ( 版) http://dom.spec.whatwg.org/#dom-node-baseuri
  • [74] DOM Standard ( 版) http://dom.spec.whatwg.org/#affected-by-a-base-url-change
  • [76] DOM Standard ( 版) http://dom.spec.whatwg.org/#base-url-change-steps
  • [81] DOM Standard ( 版) http://dom.spec.whatwg.org/#concept-node-adopt
  • [80] HTML Standard ( 版) http://www.whatwg.org/specs/web-apps/current-work/#dynamic-changes-to-base-urls

節点の基底 URL

[65] 節点は基底 URLbase 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。

  • [89] Bug 23810 – When adopting, "If node is an element, it is affected by a base..." ( ( 版)) https://www.w3.org/Bugs/Public/show_bug.cgi?id=23810
  • [92] Also run base URL change steps for nested elements. https://www.w3.org/B... · 8b87826 · whatwg/dom ( ( 版)) https://github.com/whatwg/dom/commit/8b87826a4a153f386152b44c691b9413eed93ed5
  • [93] Make the adopt hook more generic. https://www.w3.org/Bugs/Public/show_bu... · e50fd71 · whatwg/dom ( ( 版)) https://github.com/whatwg/dom/commit/e50fd7138f1bf288c4fa0b92f1673359a3affadb

[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 属性の廃止

  • [20] 20976 – Define base URLs in DOM ( 版) https://www.w3.org/Bugs/Public/show_bug.cgi?id=20976
  • [21] Design base URL change notification system · Issue #61 · whatwg/dom ( 版) https://github.com/whatwg/dom/issues/61
  • [22] Changes in the base are not reflected often enough · Issue #54 · whatwg/url ( 版) https://github.com/whatwg/url/issues/54
  • [27] Tie base URLs to documents. Obsoletes xml:base. Fixes https://www.w3.… · whatwg/dom@8ca4959 ( 版) https://github.com/whatwg/dom/commit/8ca4959505f531663bc91f064a19762e8b90b810
  • [28] Remove xml:base dependency · whatwg/html@56f4346 ( 版) https://github.com/whatwg/html/commit/56f4346ec71b2dc138038ce6512b626d6c563e00

[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