Scan: another approach

["Ray Denenberg, Library of Congress" <rden@loc.gov>]

Let's start over (indulge me).

The cannonical scan example is:

 http://myserver.com/sru?operation=scan&version=1.2&scanClause=dc.title =
frog           &responsePosition=1&maximumTerms=25

Take away operation and version (which we're going to discard, hopefully)
and you get:

 http://myserver.com/sru?scanClause=dc.title =
frog&responsePosition=1&maximumTerms=25

Now, we've talked about introducing multiple query types, which seems to be
a well-received suggestion,  and scan as one of them, perhaps not quite as
well recieved, but let's try the idea out anyway.

-  Suppose we call scanClause a query type (we can come up with a better
name later).
-  Change responsePosition to startRecord in the above.
- Change maximumTerms to maximumRecords in the above.

You get:

 http://myserver.com/sru?scanClause=dc.title =
frog&startRecord=1&maximumRecords=25

Then you essentially have a searchRetrieve request.  For this query type,
the rule is that all records are returned via the termFormat syntax.

 The multiple operation and multiple database issues go away.

Anything wrong with this approach.?

--Ray