On Wed, Aug 08, 2001 at 05:22:44PM +0200, Raphael Quinet <quinet@xxxxxxxxxx> wrote:
> and then interpret it locally. As far as I know, there is nothing
> that prevents the URI from having one or several "#" in the fragment
Except rfc2396, which specifically disallows this ;)
> The other characters that Marc proposed (spaces or 8-bit characters)
> are not valid in URIs and their behavior is undefined (they should be
> url-encoded)
That's the whole point, that they are not valid in URI's and as such it's
not possible to find a URL that would clash with our definition. Using
"#" means that common URI's to find documents (including "#fragment")
might suddenly clash with gimp, since the gimp interprets "#" as the image
component.
Here is how I see it:
- "#" precludes using fragments to subselect ressources, since only one
"#fragment" is allowed in an URI.
- "#" is the natural thing to choose sub-objects
- other characters thta are not valid in a uri make this unamigious
- other characters are unnatural
Another option would be ot use something like this:
...#gimp(name)
...#gimp(subimage=name)
...#subimage(name)
...#entry(name)
...#image(name)
or soemthing alike, which would make our fragment identifers coexistent with
other fragement identifiers.
(and soemwhat off-topic: the uri definition with respect to characters
is a single bug: it requires character sets that are strict (bytewise!)
supersets of ascii and, worse, gives no possible way to interpret it. so I
say that using "#" twice, even if forbidden would not be a problema t all
;)
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
