Re: [search-ws] recordPacking: No Schema Change Required

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

Sorry, Ray, if that came over a little brusque yesterday but we've been up
to our ears in this stuff here for the last several weeks/months getting
ready to deploy live.

To answer your questions:

> 1. The feature you desire would be meaningful/useful only in the case where
> the response format is other than application/sru+xml. Right?

Yes.

> 2. There will be some cannonical mapping of application/xml+sru to other
> formats -- json, ATOM and so the 'unpack'  directive says that a particular
> variation (i.e. unpacked) of that mapping should be used?

Not so sure about this. It may be that this falls more into 'best pactice'
rather than 'canonical'. I could imagine an informative annex (or annexes)
say (or possibly a companion doc) which would show how SRU responses could
be carried over some well-known formats, e.g. ATOM, RSS, JSON.

I don't think you can regulate all the mappings that might come back from an
SRU server. With 'httpAccept' (and/or HTTP conneg in general) we have opened
up Pandora's box.

Are you going to perscribe for every mime type out there? E.g. a very
reasonable request (and one that we might have added but didn't - yet) would
be 'application/rdf+xml'.

This is all more geared towards OpenSearch type formats, and OpenSearch is
non-specific about return formats. And I think we should be too. Some
general direction should be enough - if one even wants to allow for the
possibility of SRU-compliant responses over foreign formats.

Cheers,

Tony


On 22/9/09 18:26, "Ray Denenberg, Library of Congress" <rden@loc.gov> wrote:

> You've jumped way ahead of me as I'm still trying to make sense out of this.
> You didn't answer the questions I had.  So tell me:
> 
> 1. The feature you desire would be meaningful/useful only in the case where
> the response format is other than application/sru+xml. Right?
> 
> 2. There will be some cannonical mapping of application/xml+sru to other
> formats -- json, ATOM and so the 'unpack'  directive says that a particular
> variation (i.e. unpacked) of that mapping should be used?
> 
> --Ray
> 
>


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