RE: [ACL] REPORT vs SEARCH

> 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