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

["Ray Denenberg, Library of Congress" <rden@loc.gov>]

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



----- Original Message ----- 
From: "Hammond, Tony" <t.hammond@nature.com>
To: "Ray Denenberg, Library of Congress" <rden@loc.gov>; "OASIS SWS TC" 
<search-ws@lists.oasis-open.org>
Sent: Tuesday, September 22, 2009 11:56 AM
Subject: Re: [search-ws] recordPacking: No Schema Change Required


> Hi Ray:
>
>> And then Ralph's question I think is, if you are not getting the response 
>> in
>> application/xml+sru then why does it matter?  Is the answer that you
>
> I guess the simple answer is "Gosh!"
>
> We seem to have gone to all this trouble to define an API for SRU which
> includes a get-out-of-jail-free parameter 'httpAccept' where we suddenly
> don't seem to care what comes back.
>
> At which point I wonder about the utility of SRU.
>
> The real jewel is CQL - and we're already anyway in danger of
> overcomplicating that.
>
> And while various extension formats could be standardized for SRU 
> responses
> I don't know how scalable an effort that would be. And would one want to
> even control that at a serialization level? (I guess, to be honest, I am
> more mindful of something like RDF which has a fixed data model and can be
> variously serialized.)
>
> I am a little surprised that suggesting a new enumeration type for an
> established parameter (and which has no schema implications) is suddenly a
> big deal in a draft revision that is adding in Facets, Accept and Result
> Count Precision parameters.
>
> For now though we will be going live with this non-standard addition. But
> then we're using 'httpAccept' which is also non-standard - at this time. 
> :)
>
> Cheers,
>
> Tony
>
>
> ********************************************************************************
> 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
> ********************************************************************************
>