[67] Node
の baseURI
属性は、
文書の基底URLを返します。
[30] 取得器は、文脈オブジェクトの節点文書の文書基底URLをURL直列化器を通して得た
DOMString
を返さなければなりません >>29。
[33] base
要素によって文脈オブジェクトの節点文書の文書の基底URL
が変更されると、本属性値も自動的に変化します。
[75] 要素が基底URLの変更に影響される時、 基底URL変更手順を実行しなければなりません >>74。
[26] XSLT のデータ・モデルにおいても基底 URI の概念があります。 なお、 XSLT 1.0 や XSLT 1.1 のデータ・モデルの礎となっている XPath 1.0 のデータ・モデルにはそれに相当する概念はありませんでした。
[35] XSLT 1.0 では、基底URI は各節点について規定されています。
[36] XSLT 1.1 では、基本的に XML基底に従って基底URI が算出されます。
XSLT 1.0 | XSLT 1.1 | |
文書節点 | 文書実体のURI | (規定なし) |
根節点 | (規定なし) | 文書実体のURI |
要素節点 | 外部実体中なら外部実体のURI、そうでなければ文書の基底URI | XML基底による |
処理指令節点 | 外部実体中なら外部実体のURI、そうでなければ文書の基底URI | XML基底による |
文節点, 注釈節点, 属性節点 | 親節点の基底URI | |
名前空間節点 | 親節点の基底URI | 実装依存 |
非解析対象実体のシステム識別子 | 実体宣言を含む資源の基底URI |
XML基底
特性 (XML情報集合)[40] XML情報集合の基底URI
特性は、
その情報項目の基底URIを値として保持します。
この特性は、
で定義されています。
[44] XML基底の仕様書の内容には多少曖昧な点もありますが、 RFC 2396の規定と矛盾する規定を行う意図はなさそうなので、
の順で決定するものと思われます。
[47] xml:base
属性の値をURI参照として使うためには逃避が必要です
(xml:base
属性の項を参照してください。)
が、特性値はその前のものです。
XML情報集合 1
[48] XML基底仕様で基底URIが応用依存になる場合に関して、
XML情報集合仕様は基底URI
の値を規定しません。
XML情報集合 1
[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
機構では、
要素情報項目の基底URI
を次のように決定します。 SML-IF
[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
特性から値を得ることとされています。
baseURI
属性[3] DOM水準3でNode
界面に追加された読取専用属性baseURI
は、
その節点の基底URIを表します。
Node
baseURI
<IW:DOM3:"Core/core.html#Node3-baseURI">Document
documentURI
<IW:DOM3:"Core/core.html#Document3-documentURI">[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の仕様書でも規定されていません。
[4]
Document
が機能 HTML
(DOM水準2 HTML仕様が参照されています。)
に対応している場合 DOM3 中核:
[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と文書の所在は必ずしも一致しないはずです。
[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だからです。
本当にそんなもので良いのでしょうか。
システム識別子
特性があるので、
その解決のために宣言基底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
属性を修正しろなどの)
規定がありません。
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 は空文字列を返すようです。
[96] DOM Standard によって仕様書上の概念として基底URLの変更に影響される (>>75)、基底URL変更手順 (>>77) が定義され、 HTML Standard はこれを用いて定義する形に改められました。
[70] ただし DOM Standard は他の仕様書においてそれが定義されるとしており、 具体的にどの仕様書でそれが定義されているのかは明記されていません。
[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>
base
要素によって文書の基底URL を設定する必要があります。