- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Fri, 17 May 2002 10:01:13 +0200
- To: <LMM@acm.org>
- Cc: <uri@w3.org>
Am Freitag den, 17. Mai 2002, um 07:44, schrieb Larry Masinter: > > The example of resolving a relative URL could be improved. It uses a > base > of http://a/b/c/d;p?q > > Not wanting to read the RFC end to end, it took me a bit of > searching to > find that the ;p part is a "parameter" and the ?q part is a "query". > But I > have no idea what their relevance is to this example. It they are > to be > ignored when attaching the relative parts, it would be nice to say so. I read it like this: - query parts in base uris are to be ignored - parameters belong to a path segment and are ignored iff the path segment is ignored > The basic expansion has one very confusing and not explained aspect. > The > relative path g is said to expand to http://a/b/c/g instead of > http://a/b/c/d/g. The other expansions are obvious once the "remove d" > rule > is applied. Would a base of http://a/b/c/d/ plus g expand to > http://a/b/c/d/g? Yes. > The examples should have enough annotation to > mostly stand on their own and to reinforce the concepts. I found them to be very helpful in their current form. The only thing I would state differently is the handling of too many ../ in the resolved uri. The RFC currently states that base http://host/a/b ref ../../c resolves to http://host/../c and continues that removing the /.. at the beginning is allowed. My observation is that removing /.. is the norm nowadays and therefore the example should be the other way with a note that keeping /.. is allowed. //Stefan
Received on Friday, 17 May 2002 04:01:43 UTC