- From: Larry Masinter <masinter@adobe.com>
- Date: Fri, 24 Jun 2011 14:56:37 -0700
- To: "julian.reschke@gmx.de" <julian.reschke@gmx.de>, "public-iri@w3.org" <public-iri@w3.org>
would it help if fragment only URIs were to imply an absolute URI of "thismessage:/" rather than the document base, and special-case the translation of "thismessage:/" ? Larry -- http://larry.masinter.net -----Original Message----- From: public-iri-request@w3.org [mailto:public-iri-request@w3.org] On Behalf Of Julian Reschke Sent: Friday, June 24, 2011 8:43 AM To: public-iri@w3.org Subject: same-document references Hi there, Boris and I took our conversation yesterday about same-document references offline, and I *think* we came to some common conclusions. Note, however, this write-up is entirely mine. The text we are discussing is in <http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.4.4>: -- snip -- 4.4. Same-Document Reference When a URI reference refers to a URI that is, aside from its fragment component (if any), identical to the base URI (Section 5.1), that reference is called a "same-document" reference. The most frequent examples of same-document references are relative references that are empty or include only the number sign ("#") separator followed by a fragment identifier. When a same-document reference is dereferenced for a retrieval action, the target of that reference is defined to be within the same entity (representation, document, or message) as the reference; therefore, a dereference should not result in a new retrieval action. Normalization of the base and target URIs prior to their comparison, as described in Sections 6.2.2 and 6.2.3, is allowed but rarely performed in practice. Normalization may increase the set of same-document references, which may be of benefit to some caching applications. As such, reference authors should not assume that a slightly different, though equivalent, reference URI will (or will not) be interpreted as a same-document reference by any given application. -- snip -- Observations: a) Some readers and implementations get this wrong People seem to have a hard time understanding how the text in 4.4 (and the referenced 5.1 about base URIs) applies to certain media types, such as HTML (<base> element) or SVG (xml:base attribute). It would probably be helpful if definitions of media types made it clear how to compute the base URI for any given reference in the document, and also how changes to the document after load affect that (for instance, when the DOM is modified). Boris brought up two examples where WebKit gets this wrong: i) the base URI is properly computed for references like a/@hrefor img/@src, but not for SVG fill styles. ii) it appears that when processing references from SVG content, Webkit *only* inspects the fragment identifier and completely ignores the rest of the reference. (I believe Boris has raised WebKit bug reports for those) So these are issues with the quality of implementations, but they might be caused by the media type definitions not being clear enough about what's supposed to happen. b) The second paragraph of 4.4 can be read as if it's not necessary to retrieve the referenced resource "When a same-document reference is dereferenced for a retrieval action, the target of that reference is defined to be within the same entity (representation, document, or message) as the reference; therefore, a dereference should not result in a new retrieval action." This is nice for cases where the URI of the entity actually is the same as the base URI. However, if the base URI was actually *changed*, a new retrieval operation *is* necessary; at least, this seems to be what HTML UAs do here (note that even if the retrieved entity is the same octet-for-octet, this will affect DOM changes (being discarded) and observable behavior in the UA (as in events being fired)). I'm not entirely sure whether section 4.4 tries to rule out this behavior, but if it does, that appears to be indeed a problem. May be this needs to be phrased as "may skip a new retrieval action", instead of "should not result in..."? Best regards, Julian
Received on Friday, 24 June 2011 21:57:18 UTC