RE: Why DASL need not be DAV-specific

I think we are in general agreement that DASL should be able to search
for things that meet certain requirements: naming of properties, naming
of scopes, etc .... those things that are URL-addressable and have
properties. The DAV resource model happens to be good fit
coincidentally. 

But nothing precludes searching for non-DAV resources. In that the DAV
resource model is general enough to encompass many other kinds of
resources, I don't see any built-in limitation. 

For example, should DASL be able to search an FTP server and come back
with "ftp://" URIs? As long as we have a way to address collections,
resources, and properties then searching across such a server should be
possible. However, I believe DASL should be primarily target the
searching scenarios DAV faces -- and these are general enough to be
useful (IMO) for searching other kinds of data. 

And definitely, DASL should be an extension (or "application" may be
more precise) of HTTP/1.1




-----Original Message-----
From: Jim Davis [mailto:jdavis@parc.xerox.com]
Sent: Saturday, February 28, 1998 5:46 PM
To: www-webdav-dasl@w3.org
Subject: 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 Sunday, 1 March 1998 13:44:27 UTC