Why DASL need not be DAV-specific

At 07:39 AM 2/28/98 PST, Surendra Reddy wrote:
>	We must not limit the scope of Search and Location 
>	only for WEBDAV exposed data . DASL must be orthogonal to
>	WEBDAV... most of the applications that
>	publish content to web through non-webdav mechansims cannot be
>	searched using DASL search protocol, which I see as
>	a serious limitation. 

You know, my first reaction to this was that it was impossible, then that
it was really hard, but now I think it might not be so bad after all.

I would expect that DASL will require few if any WebDAV specific features
of the server.  It does not need locking, and it won't be doing
PROPFIND[*].  It certainly won't be depending in any way on the actual
implementation of the underlying search engine on the server (which might
be an SQL server or a full text engine such as WAIS-SF or Verity).

DASL needs a way to name properties, e.g. in queries.  But given that we
use XML for the query syntax, we can accomodate any plausible property
naming scheme (For a WebDAV server, properties are named by URIs.  For an
SQL server, properties are (I think) named by strings.  For a DMA server,
properties are GUIDS (which have a well defined string representation.)
For LDAP, properties are either strings, or (more rarely) object ids.  The
latter can be represented by strings, too.  (This presumes there's an HTTP
interface to LDAP, of course.))

I don't think it will be too much harder to specify a syntax that will
allow for discovery (e.g. of operators and their syntax) the various query
engines.

The only place I feel a little unsure is in how to specify the query scope.
 Even here, I think a list of strings suffices.  For WebDAV, the most
plausible domain of scope is a collection (named by URI).  For SQL (that's
the FROM clause, right?) it's a string.  For DMA, I think it's a System
object (my knowledge of DMA is fading fast), but whatever it is, it's named
by a GUID.

In summary, it's probably not hard to define DASL such that is does not
depend on WebDAV, and it's desirable, too.  But let me make sure of one
thing, we do agree that DASL is a set of extensions to HTTP 1.1, don't we?

Jim

[*] It will certainly be useful for the client to be able to do discovery
by doing PROPFINDs, and DASL should specify the properties to use, but I
don't think DASL has to make support for such discovery *mandatory*, and
hence PROPFIND need not be mandatory.

Received on Saturday, 28 February 1998 20:55:06 UTC