Print

---

Ray Denenberg, Library of Congress wrote:
> Ralph will probably be able to articulate this better than I can, but the
> accept parameter is driven by the requirement to be able to use OpenSearch
> (for example) to query an SRU server. The description document isn't going
> to provide templates that allow you to do this via content negotiation, they
> provide a parameter instead, to allow the client to tell the server that it
> wants, for example, an rss response.
>   
No, they don't.  I am having this same debate with Tony Hammond.

OpenSearch descriptions do NOT provide a parameter to allow the client 
to tell the server what response it wants. They also don't easily 
provide for content negotiation, it is true. 

Rather, OpenSearch descriptions provide a _different URL template_ for 
every response IANA content type available.  Here is the example from 
the OpenSearch documentation:

 <Url type="application/rss+xml" 
      xmlns:example="http://example.com/opensearchextensions/1.0/"
      template="http://example.com?q={searchTerms}&amp;c={example:color?}"/>

Please note that application/rss+xml is an attribute of the URL template 
itself, it is NOT a parameter in the template.

If SRU added an accept parameter to try and make OpenSearch happy, this 
is a big mistake, because it in fact _conflicts_ with OpenSearch desc -- 
to make it available as an actual parameter in the OpenSearch URL template.

If on the other hand, you just want to hard-code it in though, that 
could make some sense.

 <Url type="application/rss+xml" 
      xmlns:example="http://example.com/opensearchextensions/1.0/"
      template="http://my-sru-server.com?q={searchTerms}&amp;accept=application%2Frss"/>

That might make sense, if that's the use case.  But actually trying to 
provide a parameter for the _client_ to fill out in an OpenSearch desc 
in fact _conflicts_ with OpenSearch, for better or for worse the 
respones type is _hard coded_ into the template.

Jonathan



> (I suggest, though, that you move further discussion of this to the SRU
> list.)
>
> --Ray
>
> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
> Robert Sanderson
> Sent: Monday, May 17, 2010 3:44 PM
> To: [log in to unmask]
> Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
>
> In today's RESTful world, what's the requirement for the httpAccept
> parameter?  Isn't straight content negotiation sufficient rather than
> pulling the headers into the URI?
> What happens if the accept header and the httpAccept parameter say different
> things?
>
>
> Rob
>
> On Mon, May 17, 2010 at 1:37 PM, LeVan,Ralph <[log in to unmask]> wrote:
>   
>> I'd code it.  (I have already coded to it.)  For me, the httpAccept 
>> parameter and support for content negotiation on responses is a 
>> wonderful addition to the standard.  It lets us be OpenSearch 
>> compliant finally.
>>
>> The virtue of coding to the draft is that there's a chance we can fix 
>> any problems you encounter.  While we consider the draft stable, that 
>> doesn't mean everything has been tested in the real world.  I'm 
>> particularly nervous about the facets support I championed.  I asked 
>> for it to support users of my SRW server framework who wanted to 
>> create an interface to SOLR.  Those users disappeared and the 
>> usability of the SRU interface is untested.
>>
>> Ralph
>>
>>     
>>> -----Original Message-----
>>> From: Code for Libraries [mailto:[log in to unmask]] On Behalf
>>>       
>> Of
>>     
>>> Jonathan Rochkind
>>> Sent: Monday, May 17, 2010 3:18 PM
>>> To: [log in to unmask]
>>> Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current
>>>       
>> drafts
>>     
>>> Wait, I'm so confused. Is SRU 2.0 actually a published standard, or
>>>       
>> are
>>     
>>> you just showing us a work in progress that nobody should be writing 
>>> code to yet?
>>>
>>> I'm confused because I thought it was just a draft work in progress,
>>>       
>> but
>>     
>>> then you talk about official vs unofficial copies... an unofficial
>>>       
>> copy
>>     
>>> of a draft work in progress that isn't a spec yet anyway?  Very
>>>       
>> confused.
>>     
>>> If I'm planning on writing software to SRU... do you recommend I use
>>>       
>> the
>>     
>>> (until now not publically available so I didn't have a choice) 
>>> "unofficial" SRU 2.0 thing, or is that still just a draft work in 
>>> progress nobody should be writing software to yet?
>>>
>>> Jonathan
>>>
>>> Ray Denenberg, Library of Congress wrote:
>>>       
>>>> For those of you who have recently asked about current OASIS drafts
>>>>         
>> of SRU
>>     
>>>> (2.0) and CQL ...
>>>>
>>>> The *official* versions reside at OASIS, but because of confusing
>>>>         
>> (and
>>     
>>>> sometimes inaccessible) links, as well as uncertainty about  status 
>>>> (because of imbedded dates),  we now maintain *unofficial copies* 
>>>> of
>>>>         
>> the
>>     
>>>> most current versions at:
>>>>
>>>> http://www.loc.gov/standards/sru/oasis/current/sru-2-0.doc
>>>> http://www.loc.gov/standards/sru/oasis/current/cql.doc
>>>>
>>>> We will continue to maintain copies of the most current version at
>>>>         
>> these
>>     
>>>> URLs.
>>>>
>>>> --Ray
>>>>
>>>>
>>>>         
>
>