RE: bind draft issues

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver
> Sent: Friday, March 07, 2003 8:59 PM
> To: WebDAV
> Subject: Re: bind draft issues
>
>
>
> [snip]
> > Probably a good guess of Geoff's intentions. Why not give a guess
> > what an "URL property" exactly is? That would be most welcome.
>
> I think I gave that the other day:
>
>     Perhaps "URL properties" isn't the right term, but what is?
>     In the face of bindings, "URL properties" are those properties
>     which are (potentially) effected by operations on bindings, where
>     "resource properties" are not effected by such operations.
>
> In other words, they are the class of properties whose values
> (potentially) differ based on the URL specified in the PROPFIND
> (when more than one binding exists to a resource).  "URL properties"
> isn't intended to imply that the property is stored with the
> URL or anything else like that: it is merely descriptive of
> behavior.
>
> As we discussed earlier, some implementations treat DAV:displayname
> as just such a property.

I'll comment based on my understanding of the URL-to-resource relationship
in HTTP and WebDAV.

The URL is an identifier for the resource, which allows the client to
interact with the resource (in HTTP mainly by retrieving and manipulating
representations of these resources). WebDAV has added collections and
properties, but these do not really change the underlying model.

When I submit a request to an HTTP server, it uses the request URL to locate
an internal resource object. HTTP allows multiple URLs for the same
resource. Once the object was located, the name (the request URL) becomes
irrelevant -- the results of the interaction should be independant of the
way the server located the resource.

Using my favorite analogy (the Unix filesystem :-): path name and file name
of a file are stored separately of the inode (which holds metadata and has a
reference to content). Once a filesystem has located the internal file
object, one only interacts with the resource and the filename becomes
irrelevant. In particular, I can interact with an open file even though all
bindings (hard links) pointing to it are already gone.

Stefan has raised two issues:

- properties that use relative URIs -- these may vary depending on the
request URL, but the resource that is identified by the relativeURI will be
the same,

- variant handling -- based on the model described above I think this is a
really really bad idea (anyone else?).

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Friday, 7 March 2003 15:15:20 UTC