[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [search-ws] recordPacking (Reprise)
Tony, I thought that the development of the request parameter 'responseType'
had completely decoupled the issues you raise from that of recordPacking, so
that we could keep the recordPacking parameter with it's original meaning
and accomplish your objective with response type.
For your case, you could use application/json as the media type, and
'unpacked' as the responseType (not recordPacking) - where you coin a URI
and bind it to the string 'unpacked' in your explain file, and where that
URI (and hence the short string) implies the desired semantics (i.e. that
the metadata rises to the top, and that otherwise the response looks the
same as the SRU response except that it is serialized in JSON, etc.). And
your response would not include the recordPacking or responseSchema
parameters. This is the solution I thought we arrived at.
--Ray
----- Original Message -----
From: "Hammond, Tony" <t.hammond@nature.com>
To: "OASIS SWS TC" <search-ws@lists.oasis-open.org>
Sent: Thursday, March 18, 2010 8:14 AM
Subject: [search-ws] 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
> ********************************************************************************
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]