W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2002

RE: Interoperability for DAV:ishidden?

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 5 Sep 2002 10:17:26 +0200
To: "Eric Sedlar" <eric.sedlar@oracle.com>, <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCMEJPFEAA.julian.reschke@gmx.de>

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> Sent: Thursday, September 05, 2002 4:08 AM
> To: w3c-dist-auth@w3.org
> Subject: 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

> 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


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 5 September 2002 04:17:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:26 UTC