Please see comments inline below..
My feeling is that we need to narrow the options down some more rather
than just sending an enumeration of every combination.
I can live with the email as drafted if necessary.
Thanks Ray.
Ray Denenberg, Library of Congress wrote:
...
> There are variations to this proposal, for example both formats could be
> mandatory. Or an implementation would have to support at least one but not
> both (on the theory that if a client supports one and server the other, then
> they probably weren't meant to interoperate).
>
> So the possibilities are:
> 1. ATOM mandatory, SRU optional.
>
Suggest replacing above with:
"1. ATOM mandatory, SRU optional and marked as deprecated. This indicates that a future version of SRU will likely drop support for it."
> 2. Support for both formats mandatory.
> 3. Support for the SRU format mandatory, ATOM optional.
> 4. Must support at least one of the two, SRUor ATOM. (The explain record
> would indicate what formats are supported.)
> 5. No mandatory response format. (Explain.)
>
Above is really quite unworkable for interop. Suggest dropping it if
possible.
> 6. Server must support both SRU and ATOM, and client at least one.
>
Above is really redundant with (2). Also this spec should not make any
demands on the client other than it should be designed to work the SRU
interface.
> 7. Client must support both SRU and ATOM, and server at least one.
> (Explain.)
>
IMHO, above does not make sense to include. Also this spec should not
make any demands on the client other than it should be designed to work
the SRU interface.
> Note that there is a new request parameter proposed, 'responseFormat', so
> the client can indicate which format it wants.
>
> In any case, a "flavor" of ATOM would be specified in the standard which
> would call out (namespaced) elements similar to those in the current SRU
> schema -- globally: <version>, <numberOfRecords>; and per record:
> <recordSchema>, <recordPacking>, <recordPosition>. So the full
> functionality of the SRU response schema can be provided.
>
> The TC solicits ideas from SRU implementors on this issue.
>
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
