Re: URI Scheme that needs help.

I consider this kind of relative reference to be difficult and quite  
possibly harmful in protocols.  It's fine to use in a user-interface  
as a shortcut, but there had better be a good reason why the URL  
isn't canonicalized so as not to contain ".." before appearing over  
the wire.   Even relative references that don't use ".." -- e.g.   
absolute paths -- may be difficult.

If the scope is limited to use within one stored document and that  
document's base URL (e.g. a Web page), relative references work well  
enough and solve the problem of moving around hierarchies of  
documents without changing all the references within.  Part of the  
reason that works is that the whole document is used entire, so some  
kind of relative reference consistency is possible.  I don't see  
that's the case for this kind of URI yet, or what use case relative  
references would solve for this type of URI.

Some of the problems found:
  - Possible to lose the "base URL" or disagree about what it is or  
have several possible referents (see http://w3future.com/weblog/ 
2005/08/ for an example in Atom)
  - URI matching use cases difficult or broken
  - poor implementation track record outside of HTML use

Lisa


On Jan 11, 2007, at 2:41 AM, Claus Färber wrote:

>
> Frank Ellermann schrieb:
>> The concept of a workgroup context wrt to relative URLs is of course
>> odd, but your description makes it clear.  Or I think it does.
>
> The hierarchy structure is not compliant with RFC 3986.
>
> For example, "smb://foo" + "../bar" must resolve to "smb://foo/../ 
> bar", not "smb://bar" ("//bar" would be allowed).
> "smb://" also does not fit into the generic SMB syntax, "smb:" is  
> not an alternative as it is a relative URL to the current document.
>
> Collisions between DNS and NETBIOS names should be avoided, too.
>
> Claus
>
>
>
>

Received on Thursday, 11 January 2007 22:32:57 UTC