[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [search-ws] recordPacking (Reprise)
So you would indicate media type json and record packing unpacked. And
the meaning of that is the standard SRU response, serilalized in json,with
the possibility for the record data to rattle around within the SRU response
skeleton.
How does the request indicate that the standard SRU response is desired?
Would the request also include the response-type parameter, and if so what
value?
--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:23 AM
Subject: Re: [search-ws] recordPacking (Reprise)
> Well I was talking about using standard schemas for disclosure. All I was
> asking for was to allow for the possibility of the record data to rattle
> around a fixed skeleton. So a client would certainly be able to read the
> response structure and may or may not glean any data depending on how that
> client understood the processing hint.
>
> We are anyway talking here about looser, more open schemas than are
> typically used by .xsd applications. The corresponding clients too would
> be
> nimbler. So we're not looking at any ultra strict lock which does rather
> play against adoption.
>
> Tony
>
>
>
>
> On 29/3/10 16:12, "Ray Denenberg, Library of Congress" <rden@loc.gov>
> wrote:
>
>> 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/20090>>>>
> 9
>>>>> /msg00022.html
>>>>>
>>>>> [2]
>>>>>
> http://www.oasis-open.org/apps/org/workgroup/search-ws/email/archives/20090>>>>
> 9
>>>>> /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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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]