Message-Id: <m0qsZI2-0005tXC@jolt.mpx.com.au>
From: avatar@jolt.mpx.com.au (Andrew Pam)
Subject: Re: No "TOP" of the docuverse [Was: URC usage scenarios ]
To: rtor@ansa.co.uk (Owen Rees)
Date: Thu, 6 Oct 1994 02:34:01 +1000 (EST)
In-Reply-To: <9410050951.AA24239@plato.ansa.co.uk> from "Owen Rees" at Oct 5, 94 10:51:22 am
> jolt!avatar@jolt.mpx.com.au writes:
> > Of course you can, as long as you also supply the necessary context. In this
> > proposal, a host which the URL is expressed relative to. The URLs are then
> > still globally unique since they can only be compared after having been
> > transformed into their canonical form - ie relative to the current host.
>
> In this case, the (or rather a) URN for the resource is the global name for
> the host plus the name relative to that host. This assumes that hosts have
> global names, which is just a smaller version of the initial problem, but not
> an essentially different problem.
Of course, you're absolutely right. Please disregard my previous answer.
I don't know what I was thinking. After refreshing my memory on this stuff,
I can try again:
First of all, the Xanadu system has never had a distinction between URLs
and URNs; Xanadu has always been conceived as a distributed filesystem in
which every document has a unique address or identifier, but the actual
storage and retrieval is the responsibility of the back end (preferably at
the OS level). Any document can - and should - be physically located at
any number of servers with complete locational transparency.
It is anticipated that in most cases a document would be located within the
docuverse (a Xanadu term coined by Ted in the 1960s, BTW) by a user by
searching (perhaps even fuzzy searching) attributes of the document familiar
and memorable to humans such as the publisher (or author) and title.
This is probably analogous to the concept of URC -> URN resolution,
and alleviates the "bar napkin" problem.
However, for informational purposes, the Xanadu addressing scheme (as much
more eloquently explained in "Literary Machines" or the technical video)
operates as a tree structure not unlike DNS, but with a hierarchy of four
trees. Each document is composed of document fragments, any of which may
in fact be transclusions (virtual copies) of parts of other documents, but
this is not directly relevant here. The second tree identifies each
document uniquely within the context of a publisher, the third tree
identifies each publisher uniquely within the context of a host and the
fourth tree uniquely identifies each host. Thus the structure is:
host.id.0.publisher.id.0.document.id.0.fragment.id
where the zeroes separate the parts, since there may of course be a variable
number of levels to each tree exactly as in DNS.
I was trying to address a requirement that it would be desireable to allow
any organisation to do their own naming internally and still be able to connect
to other organisations at a later date knowing that all their identifiers
would be guaranteed unique without any need to maintain any centralised
information. Thus my proposal to make all host identifiers relative to the
current host at all times. If an identifier did need to be transmitted
external to the system (by print publication or whatever means) it could be
expressed relative to the highest known node on the tree, which would be
well known to all hosts underneath it. I can't really call this node the
"root", since it could legally become the child of another node at a later
date, tree expansion being explicitly allowed in this fashion in order to
provide the required functionality.
I hope that this message has provided somewhat more useful food for thought.
Share and enjoy,
*** AVATAR ***
-- Andrew Pam avatar@aus.xanadu.com Manager, Serious Cybernetics avatar@jolt.mpx.com.au Coordinator, Xanadu Australia <http://www.aus.xanadu.com/> P.O. Box 409, Canterbury VIC 3126 Australia gopher gopher.aus.xanadu.com