Re: [search-ws] recordPacking (Reprise)

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

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