Re: [search-ws] sru:recordPacking = unpacked ?

["Hammond, Tony" <t.hammond@nature.com>]

Hi Ralph:

Thanks for the response.

Let me just respond to a common thread that seems to be running through your
comments:

> This still makes no sense.  OpenSearch applications don't see
> SearchRetrieve responses, so they don't care how we carry our data.  The

> The reason it should not is that there are no OpenSearch applications
> that can use a SearchRetrieve response.

> All I've seen in your explanation is a single use case:
> OpenSearch applications trying to access SRU data.  That use case is
> satisfied by your SRU server returning RSS/Atom to the OpenSearch
> application.  I just don't see any need for an alternative form of
> SearchRetrieve response.

Why on earth shouldn't an OpenSearch application make use of an SRU
response? The fact that none have to date only means that none have had a
chance to. SRU just hasn't been showing its face. To date.

SRU is a standards-based protocol, OpenSearch more a methodology or set of
conventions. Why isn't it entirely reasonable to expect OpenSearch to
embrace SRU responses as well as other kinds of metadata?

Let me give an analogy. Many RSS feeds go about their business of
syndicating links with titles (and maybe descriptions) - and not much else.
Some RSS feeds provide rich metadata in addition to these links. That
metadata may not be immediately utilized by common or garden feed readers
but it is accessible to clients that may want to make use of it. The fact
that Bloglines or Google Reader, for example, don't use this data doesn't
mean that some other client shouldn't get the benefit of it.

Same with SRU in OpenSearch responses. I wanted to provide that so its
available for inspection *client-side* as an SRU response or else a more
general OpenSearch. I want the client to have control - not be beholden to
the server.

There are some practical advantages too. As I indicated before an SRU
response allows me to indicate the schema controlling the metadata elements
returned. It allows me to send back diagnostics. And I could do that without
SRU but why would I want to when it's already defined in SRU? OpenSearch
doesn't really care what we return back. So let's also send a full SRU
response together with whatever else we might want to send.

Why not? I would. Wouldn't you?

Cheers,

Tony


On 20/8/09 14:28, "LeVan,Ralph" <levan@oclc.org> wrote:

>> -----Original Message-----
>> From: Hammond, Tony [mailto:t.hammond@nature.com]
>> 
>> And no, I disagree that I would be the "only one". Anyone familiar
> with a)
>> SRU, and b) the record schema being used would be able to make that
>> transform.
> 
> But why would they want to if you're willing to do it for them?
> 
> 
>> What I am simply proposing is that a server-side "unpacking" transform
> could
>> be provided as a convenience service. I just want to serve up the dish
> on
>> the plate, rather than leaving it in the can which is not very
> friendly.
> 
> You can do that in the current framework.  Define a schema, an
> experimental mime-type to go with it and then httpAccept that mime-type.
> Viola, you're done!
> 
> 
>> I am operating on the basis that an SRU response can be mapped to
> other host
>> formats, e.g. RSS, ATOM, etc. (And this is already indicated by the
> Atom
>> extension model that has been provided.) I don't see any reason why
> SRU must
>> remain frozen in one XML format only, other than allowing for XSD
> validation
>> of the *complete* SRU response. If only XSD validation of the record
> data is
>> required then other carrier formats can equally host the SRU record
> data and
>> have an XSD validator run over that.
> 
> This capability is complete with the httpAccept feature.
> 
> 
>> Given the above (hosting of SRU response), then I can present the SRU
> record
>> data within an OpenSearch document. The only problem is that to
> enhance the
>> ease of use and general utility of OpenSearch applications the record
> data
>> would ideally be unpacked and made immediately available.
> 
> This still makes no sense.  OpenSearch applications don't see
> SearchRetrieve responses, so they don't care how we carry our data.  The
> server has the responsibility of rendering the SearchRetrieve response
> into something that an OpenSearch application can use.  That something
> is almost universally either RSS or Atom.
> 
> 
>> **I see no reason why a search service should not return an SRU
> response
>> within a well known format (XML or otherwise), which is discoverable
> though
>> OpenSearch conventions, and that the data which is marshalled by the
> schema
>> be unmarshalled and allowed to percolate to the top for ease of use
> (or
>> "unpacked" as I have called it).**
> 
> The reason it should not is that there are no OpenSearch applications
> that can use a SearchRetrieve response.
> 
> 
>> And I can do both - have data at the toplevel (OpenSearch style) and
> packed
>> away in an SRU record schema.
> 
> Yes, you can do both.  You can use the httpAccept parameter to accept
> requests for RSS/Atom responses or you can return SearchRetrieve
> responses, all at the control of the client.  If you think there is some
> other response schema that you should support, add it to the list of
> things you can httpAccept.
> 
> 
>> You see. It does make sense. :)
> 
> I'm quite prepared to believe that I'm just not understand what you
> really want.  All I've seen in your explanation is a single use case:
> OpenSearch applications trying to access SRU data.  That use case is
> satisfied by your SRU server returning RSS/Atom to the OpenSearch
> application.  I just don't see any need for an alternative form of
> SearchRetrieve response.
> 
> Ralph
> 


********************************************************************************   
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and 
attachments (if any). No contracts may be concluded on behalf of Macmillan 
Publishers Limited or its agents by means of e-mail communication. Macmillan 
Publishers Limited Registered in England and Wales with registered number 785998 
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS   
********************************************************************************