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" <>
To: "Ray Denenberg, Library of Congress" <>; "OASIS SWS TC"
<>
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
> ********************************************************************************
>
