Re: [search-ws] recordPacking: No Schema Change Required

["Ray Denenberg, Library of Congress" <rden@loc.gov>]

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
>