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

["LeVan,Ralph" <levan@oclc.org>]

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