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