I know that there are also wishes to return Json as SRU response. It is however possible to create this possible by an intermediate service without effecting SRU and this might even be better. On the other hand it would increase acceptance of SRU if the requested record schema's would allow responses like RSS, Json etc. without the SRU-envelope. 
I'm not offended either by allowing record schema's to cause SRU servers to return non-SRU responses. I would however discourage the introduction of yet another parameter if there is already a parameter (recordSchema) that we can use for this purpose. 
Considering previous discussions (eg rejecting the ability to request multiple recordschemas for requesting metadata + recorddata in the recordschema parameter)  I would strongly advise to prevent complicated solutions that nobody will ever use. 


Van: SRU (Search and Retrieve Via URL) Implementors namens LeVan,Ralph
Verzonden: do 14-6-2007 15:51
Aan: [log in to unmask]
Onderwerp: Re: June 18-19 meeting topics.... RSS

> -----Original Message-----
> From: SRU (Search and Retrieve Via URL) Implementors
[mailto:[log in to unmask]]
> On Behalf Of Ray Denenberg, Library of Congress
> In particular, I've just now added some discussion on the topic of
> OpenSearch/rss. Please comment.
> agenda.html#opensearch

I'm not offended by an SRU request parameter that caused an SRU server
to return an RSS response.  The server still supplies an Explain request
and accepts SRU requests and normally returns SRU responses.  That makes
it a completely compliant SRU server.  If, under circumstances
controlled by the client, it returns non-SRU responses then that seems
perfectly okay to me.  I don't think such a suggestion would require
waiting for 2.0, if we used an experimental extension.

If that is too simple a solution, then sticking an RSS response into an
SRU response as ExtraData is okay by me.  It's not clear to me that RSS
readers would be able to use it.