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

Re: Why DASL need not be DAV-specific

From: Surendra Reddy <skreddy@us.oracle.com>
Date: Sun, 1 Mar 1998 09:45:25 -0800 (PST)
To: Jim Davis <jdavis@parc.xerox.com>
cc: www-webdav-dasl@w3.org
Message-ID: <Pine.GSO.3.96.980301083703.334A-100000@legacy>

On 28 Feb 1998, Jim Davis wrote:

> 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.))
Most of the implementations uses properties as named strings. Which can
be easily represented usisng XML. By defining an extensible attributes
sets, which is nothing but a 'set of named strings', we can map most of
the searching mechanisms, at least Z39.50, DMA or LDAP. Even proprietary
implementaions using SQL can be easily mapped.
> 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.

Definitely, it is not. Also, it is a worthwhile effort to do that rather
than restricting DASL scope to DAV. This makes DASL a more useful

> 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.
As far as the protocol is concerned, query syntax is a list of strings.
Mapping query syntax to different search domains is not really that
difficult. For example, if I want to search for 'Surendra' within
Oracle organization, my search scope is LDAP namespace which is
represented through an URI e.g.
http://volcano.us.oracle.com:8000?dc=us,dc=oracle,dc=com and search
criteria will be cn='Surendra'. This can be represented easily using
> 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?

Yes, DASL is a set of extensions to HTTP 1.1.

> 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 12:44:00 UTC

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