[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [search-ws] recordPacking (Reprise)
I'm still confused. With your approach, if a client sends a request to you
asking for json, unpacked, and sends the same request to a different server,
say, Ralph's server, are both servers supposed to interpret it the same?
--Ray
----- Original Message -----
From: "Hammond, Tony" <t.hammond@nature.com>
To: "Ray Denenberg, Library of Congress" <rden@loc.gov>; "OASIS SWS TC"
<search-ws@lists.oasis-open.org>
Sent: Monday, March 29, 2010 11:01 AM
Subject: Re: [search-ws] recordPacking (Reprise)
> Hi Ray:
>
>> parameters. This is the solution I thought we arrived at.
>
> Well it's a solution that was proposed with which I was never in
> agreement.
>
> Frankly I am less than enamoured of this approach as I perceive the
> semantics to be more of a disposition rather than a new organization. That
> is, I see it more as a processing hint (or a behaviour) than as a proper
> schema change. I am not really interested in recording multiple variations
> per media type each with their own URI/short name bindings.
>
> This really does seem to be getting way complex for such an obvious need.
>
> Tony
>
>
> On 29/3/10 15:19, "Ray Denenberg, Library of Congress" <rden@loc.gov>
> wrote:
>
>> 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
>>>
>>
>
>
> ********************************************************************************
> 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]