W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 1999

Re: BIND forest question

From: Geoffrey M. Clemm <gclemm@tantalum.atria.com>
Date: Wed, 14 Apr 1999 17:37:55 -0400
Message-Id: <9904142137.AA06968@tantalum>
To: jdavis@coursenet.com
Cc: w3c-dist-auth@w3.org
   From: "Jim Davis" <jdavis@coursenet.com>

   Suppose you have two existing collections, C1, and C2, where C1 contains
   C2, and the 
   name bound to C1 is A/, and the name bound to C2 is A/B/, and that
   collection C2 contains R.html.

There is a third collection that contains a binding of "A" with C1.
Let's call this collection C3.  This also needs a mapping, so suppose
the server maps "/" to C3.  This means we have the following mappings:

  / is mapped to C3
  /A/ is mapped to C1
  /A/B/ is mapped to C2
  /A/B/R.html is mapped to R

In C3, "A" is bound to C1.
In C1, "B" is bound to C2.
In C2, "R.html" is bound to R.

So we have 4 mappings and 3 bindings.  The extra mapping (i.e. of "/")
is one that the server does through some magic like a configuration file.

   Then we have the following mapping from
   names to resources

   URL            resource
   A/               C1
   A/B/            C2
   A/B/R.html   R

Yup (plus the "/" mapping I introduced).

   Now suppose one binds the name X to C2

I assume this binding is in C3.

   A/               C1
   A/B/            C2
   A/B/R.html   R
   X/                C2

Yup.  These are some of the new *mappings*.

   Does this also create a binding for X/R.html to R?

No, but it does create a *mapping* from /X/R.html to R.

Which is why it is very important to distinguish a *binding* from a
*mapping*.  A single new binding (to a collection) creates a new
mapping for *each* member of that collection.  If you bind / to /foo,
you get *lots* of new mappings (an infinite number, in fact), but only
one new binding.  Since mappings are games that a server plays, this
is fine (unlike a new bindings, each of which requires a change of
state to a collection).

Received on Wednesday, 14 April 1999 17:38:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:19 UTC