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

RE: Why DASL need not be DAV-specific

From: Saveen Reddy (Exchange) <saveenr@Exchange.Microsoft.com>
Date: Sun, 1 Mar 1998 10:46:29 -0800
Message-ID: <2FBF98FC7852CF11912A00000000000107E78387@DINO>
To: "'Jim Davis'" <jdavis@parc.xerox.com>, www-webdav-dasl@w3.org

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

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
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
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
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
SQL server, properties are (I think) named by strings.  For a DMA
properties are GUIDS (which have a well defined string representation.)
For LDAP, properties are either strings, or (more rarely) object ids.
latter can be represented by strings, too.  (This presumes there's an
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

The only place I feel a little unsure is in how to specify the query
 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
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
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


[*] It will certainly be useful for the client to be able to do
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

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