- From: David Woolley <david@djwhome.demon.co.uk>
- Date: Mon, 9 May 2005 20:26:30 +0100 (BST)
- To: www-style@w3.org
> If there had been a fragment part, I believe that it would have been Fragments are not part of URIs but only part of URI references. data URIs are URIs, not URI references. >From RFC 2396: 4. URI References The term "URI-reference" is used here to denote the common usage of a resource identifier. A URI reference may be absolute or relative, and may have additional information attached in the form of a fragment identifier. However, "the URI" that results from such a reference includes only the absolute URI after the fragment identifier (if any) is removed and after any relative URI is resolved to its absolute form. Although it is possible to limit the Furthermore, and I believe this means that fragments may be used with data URIs: 4.1. Fragment Identifier When a URI reference is used to perform a retrieval action on the identified resource, the optional fragment identifier, separated from the URI by a crosshatch ("#") character, consists of additional reference information to be interpreted by the user agent after the retrieval action has been successfully completed. As such, it is not part of a URI, but is often used in conjunction with a URI. and The semantics of a fragment identifier is a property of the data resulting from a retrieval action, regardless of the type of URI used in the reference. Therefore, the format and interpretation of fragment identifiers is dependent on the media type [[27]RFC2046] of the retrieval result. The character restrictions described in Section 2 Which means that a fragment on a data URI has the same meaning as the same fragment on an HTTP URI that fetches the same data. This is why # is not allowable, unencoded, within data URIs.
Received on Monday, 9 May 2005 19:26:37 UTC