recordPacking (Reprise)

["Hammond, Tony" <t.hammond@nature.com>]

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   
********************************************************************************