W3C home > Mailing lists > Public > uri@w3.org > January 2002

Re: Base URIs vs. Document URIs.

From: Al Gilman <asgilman@iamdigex.net>
Date: Fri, 11 Jan 2002 11:13:18 -0500
Message-Id: <200201111613.LAA4363922@smtp1.mail.iamworld.net>
To: <uri@w3.org>
Cc: Jim Ley <jim@jibbering.com>
At 10:21 AM 2002-01-11 , Paul Grosso wrote:
>At 00:16 2002 01 11 -0800, Jason Diamond wrote:
>>If I were to define a function that resolved a URI reference, would it look
>>something like the following?
>>
>>String resolveURI(String uriReference, String baseURI, String documentURI)
>>
>>I wouldn't have expected the third parameter, documentURI, to be necessary
>>but Appendix C.1 of RFC2396 makes me think otherwise. The ninth example
>>(where the URI reference is "#s") is resolved to "(current document)#s".
>>This is unlike every other example where they are all resolved against the
>>defined base URI of "<http://a/b/c/d;p?q>http://a/b/c/d;p?q".
>
>Right, and it has to be that way (despite the fact that some popular
>browsers don't do this correctly) or you can't have both xml:base and
>intra document links in the same document work.
>
>>The document URI, if I'm not mistaken, is the URI of the document
>>entity--this can never change. The base URI, on the other hand, can be
>>changed by xml:base or HTML's BASE element, correct?
>
>Correct.
>
>>Is there any way to resolve something like "#s" against the base URI and not
>>the document URI?
>
>I'd suggest that you shouldn't be calling resolveURI at all in the case
>that the relative URI reference is merely a fragment identifier.  There
>is nothing to resolve.
>

It is a reference which can be satisfied in the immediate context of the
current [local, at hand] representationInstance of the resource.  The rule is
that it must.  Look no further.

Is there any established guidance as to a protocol saying to refresh [or
not to
refresh] in the case of a resource representation which has modified itself
post-recovery via document.write?

Al

>paul
>  
Received on Friday, 11 January 2002 11:13:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:30 GMT