- From: Eric Sedlar <eric.sedlar@oracle.com>
- Date: Thu, 5 Sep 2002 11:12:28 -0700
- To: "Julian Reschke" <julian.reschke@gmx.de>, <w3c-dist-auth@w3.org>
> > One property that keeps coming up (also in the Microsoft proposal) is the > > resource-ID property, to uniquely identify a resource (generally a GUID). > > I'm constantly getting requests from internal groups for this, > > and I know a > > lot of the JSR-170 people are interested in this for content management > > apps. > > As Geoff pointed out, this will be available as part of the BIND spec. It > could be used on systems even when they don't specifically support the BIND > method. > > > Of course another related requirement is the ability to fetch resources by > > ID. This could be done either by fully utilizing the DAV: namespace, e.g. > > DAV:<resourceID> as the URL or by waiting for DASL. > > First of all, the "unique resource ID" just is a URI. Which URI scheme is > used is up to the server. So it's completely free to assign an HTTP URI, and > this obviously could then be used to fetch the ressource. If the resourceId > isn't an HTTP URI, WebDAV doesn't give you any direct mean to retrieve it. > > Re: locating a WebDAV ressource by resourceid -- this won't work with the > current DASL spec (at least not with the DAV:basicsearch grammar), as I > expect the property to have DAV:href content -- something in which you can't > search using DASL. Therefore, a REPORT (locate-by-resourceid) may be > appropriate... > What is needed is an interoperable way, given a resource ID, to operate on a resource with that ID on the server. If the mapping between resource-ID and implementation is server-defined, we can't do that. Requiring the DAV: namespace to respond to these requests is probably the easiest thing to do, since this will work with other methods, like LOCK and so forth. REPORT doesn't handle that case. --Eric
Received on Thursday, 5 September 2002 14:22:03 UTC