Re: [search-ws] OASIS/SRU: ATOM/SRU Response Schema

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

Ok I think it's best to just take out the whole list (leave the rest of the
message intact). --Ray

----- Original Message ----- 
From: "Farrukh Najmi" <farrukh@wellfleetsoftware.com>
To: "Ray Denenberg, Library of Congress" <rden@loc.gov>
Cc: <search-ws@lists.oasis-open.org>
Sent: Friday, November 09, 2007 3:34 PM
Subject: Re: [search-ws] OASIS/SRU: ATOM/SRU Response Schema


> 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
>
>