OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [search-ws] recordPacking (Reprise)


"I don't want to have to sepcify any response format. I would want
to specify a media type alone and have the data retuned in the standard
schema for the media type "

What's the standard schema if you specify application/json?

--Ray

----- Original Message ----- 
From: "Hammond, Tony" <t.hammond@nature.com>
To: "LeVan,Ralph" <levan@oclc.org>; "Ray Denenberg, Library of Congress" 
<rden@loc.gov>; "OASIS SWS TC" <search-ws@lists.oasis-open.org>
Sent: Wednesday, March 31, 2010 4:50 AM
Subject: Re: [search-ws] recordPacking (Reprise)


> OK - maybe there's a way out of this impasse.
>
> The way we have been using the "unpacked" format is to float the 
> properties
> to the toplevel enclosing item which is where any OpenSearch type format
> would reasonably expect to find them. (I used the unpacked form to 
> maintain
> fidelity with the XML schema.)
>
> ***
> So why don't we just write this explicitly into the standard schemas as 
> the
> alternative location to find properties when an "unpacked" hint is sent?
> ***
>
> That is, why don;t we define the standard extension formats with two
> flavours: packed and unpacked. See rouch cut below. Though maybe we should
> follow Atom schema definition practice for all the extension formats (i.e.
> Using Relax NG):
>
> atomEntry =
>      element atom:entry {
>         atomCommonAttributes,
>         (atomAuthor*
>          & atomCategory*
>          & atomContent?
>          & atomContributor*
>          & atomId
>          & atomLink*
>          & atomPublished?
>          & atomRights?
>          & atomSource?
>          & atomSummary?
>          & atomTitle
>          & atomUpdated
>          & extensionElement*)
>      }
>
> This states that ordering is unimportant and that exteasnion elements are
> allowed.
>
> And btw, I don't want to have to sepcify any response format. I would want
> to specify a media type alone and have the data retuned in the standard
> schema for the media type modulated by any processing hint as to the 
> packing
> of the data. (For those who want to use a non-standard schema the
> responseFormat parameter could be sued to override the standard schema.)
>
> I still believe that recordPacking is the correct parameter to convey this
> notion.
>
> Cheers,
>
> Tony
>
>
> Atom Standard response - packed:
>
>  <entry>
>    <id/>
>    <title/>
>    <link/>
>    <updated/>
>    <sru:recordSchema/>
>    <sru:recordPacking/>
>    <sru:recordData>
>    DATA
>    </sru:recordData>
>    <sru:recordPosition/>
>  </entry>
>
> Atom Standard response - unpacked:
>
>  <entry>
>    <id/>
>    <title/>
>    <link/>
>    <updated/>
>    DATA
>    <sru:recordSchema/>
>    <sru:recordPacking/>
>    <sru:recordData/>
>    <sru:recordPosition/>
>  </entry>
>
>
>
>
> On 30/3/10 15:35, "LeVan,Ralph" <levan@oclc.org> wrote:
>
>>> -----Original Message-----
>>> From: Hammond, Tony [mailto:t.hammond@nature.com]
>>> Sent: Tuesday, March 30, 2010 7:49 AM
>>>
>>>> client says "recordPacking=unpacked", what is the server supposed to
>> do?
>>>
>>> This is up to the server - it's a processing hint. In our case this
>> happens:
>>
>> What if there are 2 different ways that the records could be mangled?
>> How does the user specify which they want?
>>
>> The technique you are using only works because you only have one way you
>> want to "unpack" the records.  It is not generalizable.  That's why we
>> suggested that you create different schemas that return different
>> elements in different orders.  I do much the same thing for "brief"
>> records.
>>
>> Ralph
>>
>
>
> ********************************************************************************
> 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]