OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

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