Relative URLs, // and ;

[Tim Berners-Lee <[e-mail]>]

At 11:29 am 27-01-97 -0600, Daniel LaLiberte wrote:
>Did you get this reply?

No -- could be my mail lag.

Tim:
> > > Absolutely *disagree*.  The // is a device of the relative addressing
which
> > > originally I intended to be quite general.  The URN scheme should be
mapped
> > > onto
> > 
> > >   urn1://authority/nameissuedbyauthority
Dan L:

> > So you are saying that the path scheme should have used path:// also.

Well, no in fact -- see below.  It doesn't need it because it has only
one sort of path element.   URNs *do* need //.   Path doesn't.
 
> > > so that (a) relative parsing works and (b) people know that the
delimiters
> > > indicate hierarchy, and (c) people are used to it.
> > 
> > > A fundamental problem with hte URL draft as is it that it suggests
that URL
> > > schemes
> > > must start with FQDNs for relative parsing  to work. Wrong.  It is a
purely
> > > syntactic algorithm.
> > 
> > This is all interesting, but it seems contrary to what I thought was the
> > convention for a couple years, and passed on to other people myself. 
> > Are you just putting your foot down now  .. finally.

I've been out of the loop.  URIs are not supposed to be irrevocably linked
to DNS!
Unfortunately there have been many demands on my time.

> > I'm not clear on how // is a device of the relative addressing, but I
havent
> > read all you might have written on your original general plans.  Could
> > you explain this more, probably to the uri list since others are probably
> > also missing it.

The // is useful in allowing one to jump to scopes in a relative URL.
In the apollo domain file system,  "//" meant "start from LAN and "/" meant
"start from host".
In http:, "//" means start from DNS" and "/" means "start from server".
Hence I would write phone numbers as

	//41/22/767 6111	rather than [phone]
	/22/767 6111  rather than [phone]
	767 6111	works either way.

You can see that the phone numbers use the "+" in the same way.
Now Windows NT uses \\ and \ in the same way.  This is a really
common functionality.  It is *NOT* just for DNS.


Generalizing (*always* a good thing), we get

	///earth//us/ma/cambridge
allowing
	//uk/london
and
	boston
and
	/tx/austin
and
	///mars//canal31/crater 456

It's easy to write the algorithm for relative URIs in the general case of
any number of slashes.
(You can even write one which allows more structure with // occurring in
several places but
I won't go into that as its quite simple)


> > How is ';' involved in relative URLs?

Semicolons were introduced to allow elements to be specified by name rather
than
position, for spaces which were best seen as matrices rather than trees.
In this case it is only sensible for relative URls which start with ";" to
take a
set of attribute values which are different.  This implies
	1. attributes can only occur once (unless you have a syntax for removing a
	   particular occurrence) and
	2. a missed value is equivalent to an unspecified value
	(so you can remove an occurrence by setting its value to empty)
	3. attributes are unordered

So relative to
	//moremaps.com/us/ma/cambridge;scale=50000;roads=main
or the equivalent
	//moremaps.com/us/ma/cambridge;roads=main;scale=50000

URI	;scale=25000
gives	//moremaps.com/us/ma/cambridge;scale=25000;roads=main

and	;roads
gives	//moremaps.com/us/ma/cambridge;scale=50000

and	;roads=
gives	//moremaps.com/us/ma/cambridge;scale=50000;roads=

and	;rivers=all
gives	//moremaps.com/us/ma/cambridge;scale=50000;roads=main;rivers=all


> > Later you said that any hierarchy should use // and /.  But that should
> > be clarified to mean that any hierachy that should take advantage of
> > relative URL support should use // and /.

I'd say any hierarchy should use  /.  To use something else just because for
your current use you don't need relative addressing is silly as it confuses
people.
Yes, it is an arbitrary choice but its made for URIs.

I'd say any hierarchy within which you might want to refer to an intermediate
level needs // for the top.

This includes any hierarchy which is ever going to be extended
upwards (marswards), which is any future proof hierarchy.
For example, suppose we grandfather DNS within something bigger.
Then with old DNS land old URLs work but we can write it as
a part of a new bigger DNS

	///old dns//www.w3.org/

for example.

> > Domain names are hierarchical, but they are reversed and use '.' as
> > delimiter.  The path scheme fixes those inconsistencies.

And was a great improvement.  I wasn't certain of the protocol but the
naming scheme is clearly much improved.  But ironically, it is improved
because it doesn't make it clear where the authority/random string
boundary is (allowing it to change). So in fact path:/ does *not* need the //
because there is no "authority" or "server" which has a special place in
the scheme -- it is homogeneous. 

> > dan

Tim