[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 ********************************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]