- From: Al Gilman <asgilman@iamdigex.net>
- Date: Fri, 11 Jan 2002 11:13:18 -0500
- 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 UTC