Re: Why DASL need not be DAV-specific

Saveen,

For any protocol to be widely accepted and implemented, protocol should be
extensible. This is possible
if and only if we at least look its design from different dimensions. If we
define our charter to define a search
mechanism only for DAV exposed properties, then the outcome of this group
would more or less aligned towards
only DAV. In fact to define search mechansim only for DAV, we do not need a
working group, we can achieve that
very well within WEBDAV working group. There are lots of groups(LDAP, IMAP,
ACAP etc)  working on Search and
unfortunately all these groups restricted their mechanisms only to those
protocols. Since web is an widely accepted vehicle
to "find and transport" any kind of data, IMO, we must make sure that our
search mechansim should not be restricted to
only specific resources exposed by DAV.

We need not come up with very generic solution. Form a design team and look
at various standards available today like Z39.50,
DMA, LDAP, IMAP, ACAP, SQL  etc. and see how we can map them to our search
mechansim. This at least gives us an opportunity
to look into various other protocols, come up with an extensible protocol
which meets DAV requirements and at the same time extensible
to map to search any other resources. If we restrict ourselves to define
somethig only for DAV, we are closing interoperability of DASL
with other protocols.

I really appreciate comments from everyone in this group.

best regards,

Surendra



-----Original Message-----
From: Saveen Reddy (Exchange) <saveenr@Exchange.Microsoft.com>
To: 'Jim Davis' <jdavis@parc.xerox.com>; www-webdav-dasl@w3.org
<www-webdav-dasl@w3.org>
Date: Sunday, March 01, 1998 10:40 AM
Subject: 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 Monday, 2 March 1998 12:57:07 UTC