Re: Interoperability for DAV:ishidden?

> > 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