W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > January to March 2002

RE: next steps / open issues in DASL framework

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 12 Mar 2002 16:30:59 +0100
To: "Elias Sinderson" <elias@cse.ucsc.edu>, <www-webdav-dasl@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCIEDIEDAA.julian.reschke@gmx.de>
> <Elias>
>     I'm in agreement with Jim on this one. Currently with mod_dav you
> can turn on DAV support for a subset of the namespace, and the same will
> almost certainly be true with some DASL implementations. (If not by the
> same 'DAV On' or 'DASL On' mechanism, then via 'limit' style directives,
> access controls, etc.) It makes sense for the root of a DAV
> server/namespace to be a default location for a searcharbiter or a
> redirect to the location of the searcharbiter for the server/namespace,
> but I don't think it can be enforced. Maybe this should be a 'SHOULD
> provide' requirement of the spec? At the least, the spec. should say
> something about it.
>     The suggestion to define a property on collections that are
> searchable seems like a possible way to allow searcharbiter discovery.

If a collection is smart enough to "know" the search arbiters in scope,
shouldn't it also be smart enough to act as search arbiter itself (just
forwarding the queries to actual software modules)?

> This would address arbiter discovery and redirection issues, but raises
> a couple others. Specifically, should the property be live or dead? The
> use cases involving moving a resource from one namespace to another that
> is searched by a different arbiter or from a DASL aware namespace to a
> non-DASL aware namespace (and vice-versa) would indicate that the
> property should be live. On the other hand, if a dead property were used
> it would allow one to specify different searcharbiters for different
> resources.

Just because it's live doesn't mean it can't be changed/modified... Seems
that this topic needs more discussion...
Received on Tuesday, 12 March 2002 10:31:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:42 UTC