Comments on Requirements

Comments on requirements:

Introduction

Introduction needs to be revised to reflect the current state of DAV (INDEX
is gone, PROPFIND can be executed with a Depth header so that repeated
invocations are not needed to traverse a naamespace). 

What the introduction basically says (and this might be made explicit) is
that DAV gives clients tools retrieving enough data to perform a
client-side search (do all the filtering, constructing result records,
ordering results on the client side).  What DASL wants to do is provide
additional protocol elements in support of server-side search.

--------------

Search Criteria

We need more terminology really to discuss this.

Term
Comparison Operator
Attribute / Modifier

We want to be able to search based on properties or based on content or
based on both together.

The simplest search criterion is a single term, which states that the value
of a certain property has a certain relationship to a certain value.  "The
value of the Size property is less than 10K"  Or that the content has a
certain relationship to a certain expression.  "The content contains 'Bill
Smith'"

The requirements need to say something about what comparison operators we
care about.  I think that 3.1.2 takes too narrow a view.  It should list
all the operators we think are necessary for a simple search protocol.

In addition, we may have things to say about what sorts of expressions must
be supported as arguments to the comparison operators.  Is it enough to
compare to some constant, or do we have to support complex expressions?

In addition, we might want to support attributes modifying the comparison.
"Content contains 'index'", where I want to include only exact matches to
the expression, where I want a case-insensitive comparison, where I want to
include grammatical variants of 'index', where I want to include synonyms
of 'index', where I want to include expressions in any language that mean
'index' . . .

Once having settled what needs to be supported for individual terms, we can
go on to talk about booleans for constructing complex search criteria.

3.1.4 Whatever we say about variants, we need to say the same things about
versions.

3.1.5 - 3.1.7 I would contend that these sections apply equally well to
property-based searches as to content-based searches.

3.1.5 belongs in a more general discussion of modifiers to comparisons.
3.1.6 belongs in a more general discussion of what the arguments to
comparison operators can be like.
3.1.7 belongs in a more general discussion of what comparison operators
must be supported.

--------------

Sort Order

We may also want to require the protocol to let clients specify a sort
order -- by relevance ranking, by increasing / decreasing value of some
property, etc.

We might want clients to be able to specify how to compute relevance, or we
might want to leave this entirely to the server.

-------------

Results

We might also want to let clients specify the maximum number of records to
return, or the lowest relevance ranking to return.

-------------

Narrowing a Search

We might want to allow clients to request a search on a previous result
set.  This would require the server to keep state for a search session,
though, so maybe it's out of scope.

"More Like This" is another useful request that requires state to be saved.

-------------

Search Query Syntax

I'm not sure what is intended by 3.4.2.  "the extensible use of alternate
query syntax" seems confused.  Either you extend the DASL query syntax
somehow, or you use an alternate syntax.  Using an alternate syntax is not
extending the DASL syntax.

I can see designing the syntax so that the standard can be extended in the
future.  I'm not so sure I would like to see server vendors extending it in
proprietary ways, though that can't be prevented.  I don't want to see us
adding complicated discovery mechanisms for finding out what extensions
server vendors provide.

---------------

When we state requirements we need to be clear about when we mean the
protocol must be capable of expressing something vs. a compliant server
must be able to process a request of a certain sort.  We might think the
protocol must be able to express a request for the results to be ordered in
a certain way, but not think that all compliants servers must be able to
sort results.

3.4.1 makes it sound as if you think that DASL servers must be able to
satisfy any request that can be expressed in the DASL query syntax, but I
doubt if we will realistically be able to require this.

---------------

We might want to say something about other related standards work that we
want to interoperate with.

----------------

Broad issues that need to be decided:

Is distributed search in scope (that is, a search that requires responses
from multiple servers)?  I assume from 3.3.3 that your inclination is to
answer "No" to this question, which would be in line with WebDAV's policy.

To what extent is discovery of server search capabilities in scope?  In the
interest of keeping things simple, I would be inclined to say that the only
thing you can query a server about is what query syntaxes it supports.

------------

Some useful references:

The Harvest User Manual, especially the section on querying a broker:

http://harvest.transarc.com/afs/transarc.com/public/trg/Harvest/user-manual/
user-manual.html

The STARTS protocol proposal:

http://www-db.stanford.edu/~gravano/starts.html

The help pages for any of the popular Web search engines

User manuals for any of the commercially available document management systems

Received on Monday, 12 January 1998 16:09:53 UTC