Re: Why DASL need not be DAV-specific

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
protocol. 

 
> 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
XML. 
		
> 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