[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]