Apparently, listserv problems, and Tony asked me to forward this. 


From: Hammond, Tony [mailto:[log in to unmask]] 
Sent: Wednesday, February 19, 2014 12:34 PM
To: Denenberg, Ray
Subject: Fwd: SRU recordPacking and JSON


Hi Ray:


I don't know if I'm failing to post to the list. Can't see it listed there.
Would it be possible for you to forward if it doesn't show up?






Begin forwarded message:

From: "Hammond, Tony" <[log in to unmask]>
Date: 19 February 2014 16:50:59 GMT
To: "SRU (Search and Retrieve Via URL) Implementors" <[log in to unmask]>
Cc: Ray Denenberg <[log in to unmask]>
Subject: Re: SRU recordPacking and JSON

Hi Ray:


Thanks for summarizing. Have been scratching my head too to remember what
this was all about. But it's all in the archive. T:)


This message is perhaps appropriate - not least because the links
still work after 4 years - and because our service is still working (albeit
performance may be an issue):


The basic idea was that this parameter had been misnamed earlier and that it
could help us with a problem in which data was too deeply nested in a
structured instance because of the (standards-based) schema we were
attempting to follow.  We suggested that it could serve as a "hint" to the
server to unpack a deeply nested structure which would make more sense in
lightweight serializations such as RSS, JSON, etc.


The previous SRU 1.2 purpose of this parameter was targeted at
differentiating between XML and text representations, I believe - a
functionality which was superseded by SRU 2.0's support for generalized
content negotiation.





From: Ray Denenberg <[log in to unmask]>
Reply-To: "SRU (Search and Retrieve Via URL) Implementors"
<[log in to unmask]>
Date: Wednesday, 19 February 2014 15:17
To: "[log in to unmask]" <[log in to unmask]>
Subject: Re: SRU recordPacking and JSON


Hi John - I'll try to summarize the thinking behind this. As soon as I have
some time I'll go to the archive and re-read the discussion and then give a
fuller explanation.   


At the time that the packing parameter was discussed there were seven or
eight members on the committee. One member felt very strongly about the
issue and was able to convince the rest of the members.  (That was Tony
Hammond of, whose contribution to the standard was significant.)


Tony  argued for the case where records normally consist of structure and
payload (not the norm for bibliographic data,  more normal for
there will be cases where a server has content that it is willing and able
to provide but is either not willing or not able to supply the syntactic
infrastructure .or.   the server is willing to supply the data according to
the requested schema, but is also willing to supply it "unpacked" (Tony's
term), and that alternative would be cheaper and quicker.   So, the client
says,  I want the data supplied according to schema XYZ, however supply it
unpacked, if you can, or if you cannot supply it according to XYZ. (This of
course presumes that the client is able to extract the payload from the
unpacked data, or at least try to, and how that happens is not addressed.)


I completely agree that this is not adequately described in the standard.  I
think we can add an explanation to "Implementer Notes" (which we haven't
started yet, but will).





From: SRU (Search and Retrieve Via URL) Implementors
[mailto:[log in to unmask]] On Behalf Of John Harrison
Sent: Wednesday, February 19, 2014 4:16 AM
To: [log in to unmask]
Subject: Re: SRU recordPacking and JSON



On 18 Feb 2014, at 18:40, Ray Denenberg <[log in to unmask]> wrote:

The recordPacking parameter in 2.0 has completely different meaning than in
1.2.    (See 13.2 copied below.) In short, it tells the server whether or
not to take seriously the parameter recordSchema: if it is omitted or its
value is 'packed' then the server MUST supply records according to the
requested schema.  If it is supplied with the value 'unpacked' then the
server is free to choose an alternative schema.


Wow, this is confusing. I could understand repurposing an existing parameter
if the new purpose was accurately summarised by the existing parameter name,
but that doesn't seem to be the case here. I mean that the name
'recordPacking' does not intuitively suggest that the purpose is to say
whether the server MUST return in the requested schema (or presumably return
a diagnostic). Can someone explain the logic behind this choice?






John Harrison

University of Liverpool

e: [log in to unmask]


t: 0151 7943921




DISCLAIMER: This e-mail is confidential and should not be used by anyone who
not the original intended recipient. If you have received this e-mail in
please inform the sender and delete it from your mailbox or any other
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
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
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
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS