W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2000

Re: WebDAV Bindings - Issue Yaron.Insulting2616, definition of resource

From: <ccjason@us.ibm.com>
Date: Tue, 18 Jan 2000 14:05:19 -0500
To: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
cc: w3c-dist-auth@w3.org
Message-ID: <8525686A.0068EAF0.00@D51MTA03.pok.ibm.com>

I agreed or didn't understand various parts of your note until I got to the
following.  I think
it explains what you're trying to get at when you speak of the server
knowing if something
is the same resource or not.

  A better example is a collection consisting of "Fred", "Frederick",
  and "Douglass".  Those could be three different resources (for example,
  individuals within a team of coders) or three different aliases for
  the same resource.  The only person who really knows the answer is the
  person defining the namespace -- it just isn't something that a server
  can figure out by analyzing the implementation, because what
  one resource from another is the semantics given to them when each URI is
  used within some external reference.  The server can't even rely on the
  implementation giving some indication of the difference, since the
  implementation is allowed to change over time, whereas the semantics of
  a resource does not (legitimately) change over time.

You are trying to emphasize the definition of a resource as being in
the eyes of the author.
And that you want the server somehow be able to know and track the author's
concept of "the resource"... and distinguish it from the current
of the resource.   And because bindings remove the tight one-to-one
of the conceptual resource from its implementation, you feel the advent of
bindings is a good place to have the server start maintaining that
and support both concepts fully.

It sounds like you'd like to be able to insert another level of indirection
in our model.  A "a-resource" is the author's conceptual resource.  A
is a server's concept of a resource and represents an implementation.

   URI:  leadprogrammer.html     john.html       fred.html


   aresource: lead_programmer_personal_page   aresource: john  aresource:


   sresource: John.html   sresource: John.pl   sresource: Fred.html


 states of sresources: John.html.001  John.html.002  John.pl.001

The "binding" from URI to aresource is pretty static.  The URI basically
continue to point to the same concept until the end of time.... ideally.
over time the author might
change the implementation to use a different sresource for a given
resource.  And over time the implementation of the sresource might evolve
as it is debugged.

So what we've done in WebDAV is compressed the URI and conceptual resource
layers together since ideally they should remain as a one:one mapping for
eternity.  That means if we have a situation like...

 leadprog.html  john.html  fred.html
    |               |          |
  lead_prog       john       fred
     \             /           |
      \          /             |
        John.html            Fred.html

In webdav we'd create a situation like the following.

 leadprog.html  john.html  fred.html
     \             /           |
      \          /             |
        John.html            Fred.html

And you are thinking of the resource as an implementation of the resource
rather than the resource.
Actually I was thinking both.  I was emphasizing the server's concept
as something that the author could still leverage to maintain his
concept.  I didn't feel it was important for the server to maintain
the author's concept of a resource, but I felt that if the author
wanted the server to, it could.  That's what I meant when I spoke
about a proxy object.

What I was saying about a proxy object is that
the author could actually create a server resource to represent his
concept of a resource and distinguish it from its implementation.  That
would not implement anything.  It's only job would be to redirect
to the server object that currently implements the authors concept.
The server could manage both the conceptual resource and the implementation
resource as WebDAV resources.

The fly in the ointment is that ideally we'd like the proxy object
to have a ***strong*** link/binding (whatever you want to call it) to its
implemenation object.  The only type
of strong links that we provide right now are bindings.  And they are only
kept by collections.   So this proxy object would basically need to be a
collection.  Presumably that collection would only be allowed one child
and it would always internally redirect to it.  Of course it can't always
redirect ALL requests.  Presumably there are operations that we might want
to do on the proxy itself.  (Maybe there aren't.)

Anyway, the basic ground work is there to do this if the author wants to.
It isn't explicitly supported in the protocol though.  It could be at a
later date though.  As I said, the ground work is there.

BTW... you mentioned that BIND acts on the wrong object.  I think most of
us recognize this, but I just wanted to remind you to get back to us with
your commments and insight on that.

Received on Tuesday, 18 January 2000 14:06:24 UTC

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