RE: Why DASL need not be DAV-specific

Since I don't post all that often to this group, being mostly a lurker, I
thought I would introduce myself before making any comments. My name is
Yaron Y. Goland and I am one of the authors on the DAV protocol spec as well
as the one who originally, way back when, suggested forming this working
group. Unfortunately I missed the second DASL BOF (held at Xerox) due to
illness. But be sure you will see me at all future meetings.

The reason why this working group was formed was to solve search for DAV.
That is the limit of its mandate. The reason why we formed a separate
working group rather than just doing this work within the DAV working group
was largely for procedural reasons. The DAV working group has its hands full
looking at a slate of problems including: Distributed Authoring, Access
Controls, Variants, and Versioning.

Thus a consensus grew that if we added search we would just overload the
working group, forcing it to pay attention to too many issues
simultaneously.

As such the consensus was that the most reasonable course of action was to
form a separate working group, with a separate chair, mailing list, etc.
That way we could be sure the search issues got their due attention.

However to focus people on the new working group's purpose and to ensure
that they did not misunderstand its mandate we named it "DASL" for DAV
Searching and Locating. We felt that by putting the word DAV in the title
and stating explicitly in the charter that this working group was to provide
DAV search we would make it clear to everyone that this working group's
purpose was to provide search facilities for DAV. More to the point, to
provide search facilities which make optimal use of the DAV object model,
repository model, variant model, access control model, and versioning model.

Universal Search is a laudable goal but one that will require compromises we
are not willing to make. Implementers of DAV repositories require a search
mechanism that makes optimal use of their repositories. If some day someone
creates a universal search mechanism I'm sure everyone will happily look
into providing its interfaces on top of DAV's.  However the explicit goal of
this working group is to define the absolutely best search mechanism for
DAV.

			Yaron

> -----Original Message-----
> From:	Surendra Reddy [SMTP:skreddy@US.ORACLE.COM]
> Sent:	Monday, March 02, 1998 9:50 AM
> To:	Saveen Reddy (Exchange); 'Jim Davis'; www-webdav-dasl@w3.org
> Subject:	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 17:01:12 UTC