- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 7 Mar 2003 21:15:00 +0100
- To: "Brian Korver" <briank@xythos.com>, "WebDAV" <w3c-dist-auth@w3.org>
> 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