 |
 |
On 02/19/2014 11:49 PM, Ray Denenberg wrote: > > Apparently, listserv problems, and Tony asked me to forward this. > I take it my email sent 18 Feb wasn't received either. / Adam > > *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] > <mailto:[log in to unmask]>> > *Date:* 19 February 2014 16:50:59 GMT > *To:* "SRU (Search and Retrieve Via URL) Implementors" > <[log in to unmask] <mailto:[log in to unmask]>> > *Cc:* Ray Denenberg <[log in to unmask] <mailto:[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 > <http://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&q=list%3Aorg.oasis-open.lists.search-ws#query:recordPacking%20list%3Aorg.oasis-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] <mailto:[log in to unmask]>> > *Reply-To: *"SRU (Search and Retrieve Via URL) Implementors" > <[log in to unmask] <mailto:[log in to unmask]>> > *Date: *Wednesday, 19 February 2014 15:17 > *To: *"[log in to unmask] <mailto:[log in to unmask]>" > <[log in to unmask] <mailto:[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 > <http://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 <http://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] <mailto:[log in to unmask]> > *Subject:* Re: SRU recordPacking and JSON > > On 18 Feb 2014, at 18:40, Ray Denenberg <[log in to unmask] > <mailto:[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] <mailto:[log in to unmask]> > > w: cheshire3.org <http://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 > ******************************************************************************** >