- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 5 Oct 2001 21:19:11 +0200
- To: "Jim Whitehead" <ejw@cse.ucsc.edu>, <ACL@webdav.org>, "WebDAV Working Group" <w3c-dist-auth@w3.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Friday, October 05, 2001 8:56 PM > To: ACL@webdav.org; WebDAV Working Group > Subject: RE: [ACL] REPORT vs SEARCH > > > Julian Reschke writes: > > Both REPORT and SEARCH define frameworks for pluggable query grammars / > > reports. I really can't see where the distinction between reports and > > searches you made is reflected in the specs. > > Many design considerations never make it into specifications. > > > However, the framework for REPORT is already there (almost in RFC > > form) > > For the case of DAV:basicsearch, this doesn't count for much. The > definition of the "SEARCH" method is not the difficult part of DASL. The > core complexity comes from specifying the search grammar, and correctly > specifying how to do an i18n ordering of search results. These > complexities > are these whether you use REPORT or SEARCH. > > >, and I think it's technically superior (regarding discovery > > of query grammars / reports). > > Huh? > > REPORT tells you what reports are available via DAV:supported-report-set. > > DASL tells you what search grammars are available via the DASL response > header. > > These are equivalent in expressive power. Not really. a) DASL defines an HTTP header, so it occupies a token in the HTTP namespace, while DAV:supported-report-set is only visible to clients issueing WebDAV requests (so we don't unnecessarily occupy a place in somebody else's namespace), b) The way OPTIONS is defined in DASL, you can't use the header information to *directly* identify which grammars available. The way it's defined for DAV:basicsearch *only* works because DAV: happens to be the prefix and the namespace name at the same time. Given a DASL header of <http://www.greenbytes.de/tech/webdav/simplepropertyseach> what is the name of the grammar (so how do you *generally* split the namespace from the grammar name?). > > So my proposal is to drop the DASL *framework* and re-use the one > > used in REPORT, and to update / modify DAV:basicsearch to > become a report. > > This isn't a shift of framework, it's a shift of marshalling mechanism, > REPORT vs. SEARCH, DAV:supported-report-set vs. OPTIONS and the > DASL header. Fine with me :-) > > If you disagree, I'd like to understand why we need the SEARCH framework > > when we already have REPORT. > > While I will freely admit that you *could* marshall DAV:basicsearch using > REPORT, here are my reasons for why I think you should have both > REPORT and > SEARCH: > > - Reports have very specialized and limited query specifications. Search > grammars are expected to be much more complex (DAV:basicsearch, XML query, > Z39.50, etc.) *The currently defined* reports: yes. But why should this restrict us in what new reports we define? And why do we need two frameworks if the one we have can do everything we need? > - Reports have a reasonable expectation of being specified in XML. Queries > submitted using SEARCH may not be. Can you back that up by anything which is either in ACL, deltaV or DASL? > - Error reporting mechanisms for REPORT may not be appropriate for SEARCH. > In particular, it may not be safe to assume that returning an XML > tag in the > body is OK for all search grammars, yet this is the current case > for REPORT. "If an error occurred that prevented execution of the query, the server MUST indicate the failure with the appropriate status code and SHOULD include a DAV:multistatus element to point out errors associated with scopes." OK, so why is this "should" rather than "must"? Do we really non-XML based query protocols? > - REPORT is currently limited to using the Depth mechanism for scoping. > While this is also the current case for DASL, I believe that DASL > will need > to provide a definition for how to perform a "server"-wide search. > Separating the two will free DASL to develop better scoping rules. Interesting, but this isn't really an argument in favor for SEARCH. > - Some queries grammars using DASL may not even require DAV > extensions to be > present. For example, XML query via DASL should reasonably work > against both > HTTP+DAV+DASL servers and plain HTTP+DASL servers. REPORT is > intimately tied > to the DAV object model (it requires properties). Where does it require properties? I see your point that SEARCH can be something separate from WebDAV. Is this a purely theoretical requirement, or did somebody specifically ask for it? While I link DAV:supported-report-set, grammar discovery could also be done through REPORT itself (it would be just another report, so it wouldn't have to rely on PROPFIND). > Basically, these all boil down to a separation of concerns argument. By > separating REPORT and SEARCH, you allow each to more precisely meet their > respective requirements. > > - Jim >
Received on Friday, 5 October 2001 15:18:31 UTC