OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: OASIS/SRU: ATOM/SRU Response Schema


 I've drafted the message below (with subject as in this message) to post to
the SRU listserv.  Please review and comment as soon as you can.

I will precede this message with an introductory message, draft of which
I'll post to this list for review, separately.

--Ray

-----------------------------------
This is one of a number of topics initiated by the OASIS Search Web Services
Technical Committee, for discussion within the SRU list.

The TC is considering the response format for the searchRetrieve operation.
There is strong support (from at least one member) for making ATOM the
default format - that is, ATOM support would be mandatory and the existing
SRU response format optional.

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.
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.)
6. Server must support both SRU and ATOM, and client at least one.
7. Client must support both SRU and ATOM, and server at least one.
(Explain.)

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.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]