[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: recordPacking (Reprise)
Hi: I need to raise again the question of recordPacking. We have implemented an instance which uses the recordPacking parameter with value "unpacked" to signal a different organization for how the record data properties get to be arranged over a fixed schema skeleton - see my examples A and B below (shown here in JSON format for reading convenience). Both of those responses are consistent with given values for the following request parameters: - httpAccept = media type - application/json - responseType = schema (for media type) - info:... The key difference in the two responses is not one of schema per se. Many of the OpenSearch response types (RSS, ATOM, JSON) have a much looser schema definition and define rather a generic framework structure. They do not pin properties down to appear at specific locations only. Hence, relocation of those properties does not imply a schema change and thus is not covered by calling for a different responseType. Both A and B below conform to media type and schema. What is different between them is more what I earlier called a "disposition of the data" in my proposed draft text for this parameter [1]. (Note also that as pointed out [2] there is no SRW schema change required.) This is a sufficiently important point for us that I would request that it be put back on the agenda. I believe the approach that we have adopted is fully consistent with the intent of the SRU spec. Our proposed parameter value ("unpacked") is consistent both in terminology and in semantics. It informs a client about processing of the records in a response. Note that the schema itself is already known from an httpAccept/responseType pairing. What has happened here is merely that some data properties range over a fixed structure. To try and push this down to some finer level of granularity of responseType - below that of schema level - would in mind be a huge mistake. It would confuse users and raise the bar further to SRU adoption. To attempt to hold out for the original meaning of recordPacking as being a parameter purely to allow for escaping XML also seems to me to be injudicious. That is a complete waste of a parameter. (And btw, if one really wanted to tunnel an XML document as a string could not a CDATA section nt also have been used?) It seems to me to be entirely reasonable to allow for this processing "hint". Nothing has changed in the response other than that some properties have wriggled around. And if a client is making the request then presumably it is satisfied that it knows how to process the response. We are dealing here with more fluid response types and more agile clients. We have definitely departed from the traditional web services model of battening down every last iota [3]. Cheers, Tony [1] http://www.oasis-open.org/apps/org/workgroup/search-ws/email/archives/200909 /msg00022.html [2] http://www.oasis-open.org/apps/org/workgroup/search-ws/email/archives/200909 /msg00035.html [3] "Toto, I have a feeling we're not in Kansas anymore." - Dorothy Gale (Judy Garland) in The Wizard of Oz (1939). == * Ex. A - recordPacking="xml" "entry": [ { "title": "Estimation of additive genotypic variance with the F3 of autogamous crops", "link": "http://dx.doi.org/10.1038/hdy.1989.77", "id": "http://dx.doi.org/10.1038/hdy.1989.77", "updated": "2010-03-18T11:22:41+00:00", "content": null, "sru:recordSchema": "info:srw/schema/11/pam-v2.1", "sru:recordPacking": "xml", "sru:recordData": { "pam:message": { "pam:article": { "xhtml:head": { "dc:identifier": "doi:10.1038/hdy.1989.77", ... } } } }, "sru:recordPosition": 1 } ] * Ex. A - recordPacking="unpacked" "entry": [ { "title": "Estimation of additive genotypic variance with the F3 of autogamous crops", "link": "http://dx.doi.org/10.1038/hdy.1989.77", "id": "http://dx.doi.org/10.1038/hdy.1989.77", "updated": "2010-03-18T11:22:41+00:00", "content": null, "dc:identifier": "doi:10.1038/hdy.1989.77", ... "sru:recordSchema": "info:srw/schema/11/pam-v2.1", "sru:recordPacking": "xml", "sru:recordData": { "pam:message": { "pam:article": { "xhtml:head": { } } } }, "sru:recordPosition": 1 } ] ******************************************************************************** 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 ********************************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]