 |
 |
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? Thanks, Tony 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 bit.ly links still work after 4 years - and because our service is still working (albeit performance may be an issue): http://markmail.org/search/?q=recordPacking <http://markmail.org/search/?q=recordPacking&q=list%3Aorg.oasis-open.lists.s earch-ws#query:recordPacking%20list%3Aorg.oasis-open.lists.search-ws+page:1+ mid:fee7niikmlpt62kt+state:results> &q=list%3Aorg.oasis-open.lists.search-ws#query:recordPacking%20list%3Aorg.oa sis-open.lists.search-ws+page:1+mid:fee7niikmlpt62kt+state:results 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. Tony 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 Nature.com, 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 Nature.com) 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). Ray 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? Best, John -- John Harrison University of Liverpool e: [log in to unmask] w: cheshire3.org t: 0151 7943921 **************************************************************************** **** 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 **************************************************************************** ****