I'm ready to tackle Scan as well, but I want it as a new service, not
additional parameter in a SearchRetrieveRequest.
Ralph
> -----Original Message-----
> From: Theo van Veen [mailto:[log in to unmask]]
> Sent: Monday, December 16, 2002 10:40 AM
> To: [log in to unmask]
> Subject: scan
>
>
> As the resulset issue is solved now :-) we can step into scan.
>
> I would prefer it to be part of
> SearchRetrieveRequest/Response. As Matthew already pointed
> out it is for SRU desirable to have different types of
> requests under the same base-url but in this case I think
> that it should be part of SearchRetrieve also for SRW.
> The parameters we need are the number of index entries
> (maximumEntries) to be returned and a token for the next
> entries (nextEntry). The request contains either that token
> or a query. It would be convenient if we could add
> maximumEntries as part of a "normal" SearchRetrieveRequest
> to allow servers to return "unsollicited" scan results when
> there are no hits.
> This brings me to propose the operation parameter:
>
> none : default SearchRetrieve (backwards compatibility)
> retrieve : default SearchRetrieve
> scan : scan
> search : do a search and in case of no hits return the result
> of a scan
>
> I think it is important to define scan as soon as possible to
> prevent people argue that the functionality of SRU/W is too
> limited, resulting a a lower acceptation of SRU/W.
>
> Theo
>
>
|