[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [search-ws] recordPacking: No Schema Change Required
Tony - Let me see if my understanding is in the right direction, as I think I have the same confusion as Ralph, but maybe I'm beginning to see what you're getting at, though I'm not sure. The feature you desire would be meaningful/useful only in the case where the response format is other than application/sru+xml. Right? So the request would include, perhaps: httpAccept=application/json or httpAccept=application/atom+xml And then Ralph's question I think is, if you are not getting the response in application/xml+sru then why does it matter? Is the answer that you anticipate there will be some cannonical mapping of application/xml+sru to json (and there already is a draft of one to ATOM) and so the 'unpack' directive says that a particular variation of that mapping should be used? --Ray ----- Original Message ----- From: "Hammond, Tony" <t.hammond@nature.com> To: "LeVan,Ralph" <levan@oclc.org>; "OASIS SWS TC" <search-ws@lists.oasis-open.org> Sent: Tuesday, September 22, 2009 9:55 AM Subject: Re: [search-ws] recordPacking: No Schema Change Required > Um. > > Schema is just for SRU/XML. Only logical effect of this value on SRU/XML - > if ever used with SRU/XML - would be to trash the record data. No schema > change required. > > This parameter value is primarily intended for operation with extension > formats, or host formats. A draft extension to ATOM was published on the > TC > site earlier (July 16) [1,2]. We have taken that work and expanded on it > (July 23) to include support for RSS and JSON as a direct ATOM mapping > [3]. > > There is no whiff of XML schema here in any of these formats. And no > change > to any XML schema is required. > > Is there any reason not to allow for an SRU response to be hosted by an > extension format? That is all I am attempting, while making it easier for > OpenSearch applications to get at the data. > > One could say that these OpenSearch responses were SRU compliant. > > I'm feeling pretty dense too. This just seems to be so obvious. :) > > Cheers, > > Tony > > > [1] > http://www.oasis-open.org/committees/download.php/33410/atom-extension-for-s > ru.doc > [2] > http://www.oasis-open.org/committees/download.php/33408/atom-extension-for-s > ru.xml > [3] > http://www.crossref.org/CrossTech/2009/07/opensearch_formats_for_review.html > > > > On 22/9/09 14:31, "LeVan,Ralph" <levan@oclc.org> wrote: > >>> From: Hammond, Tony [mailto:t.hammond@nature.com] >>> >>> <xsd:element name="recordPacking" type="xsd:string" nillable="false"/> >>> >>> i.e. any string goes. There is no restriction to any type enumeration. >>> >>> So allowing for 'recordPacking=unpacked' is *not* a schema change. It >> would >>> only require a change in the text of the document. >> >> Yes, I'm sure the new parameter itself would require no changes. But I >> believe the intent of the parameter is to cause a different response, >> where elements that had previously been in the <recordData> element >> would now be in the <searchRetrieveResponse> element. That would be a >> schema change. >> >> If this new value for recordPacking causes no change in the response, >> then explain to me again what its point is, because I'm feeling really >> dense here. >> >> 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]