"Rather, OpenSearch descriptions provide a _different URL template_ for
every response IANA content type available"

Yes, of course, that's what I meant, I said it somewhat slopily, but in many 
of the examples we've looked at, it comes down to the same thing, that the 
different templates differ only in a single (hard-coded) parameter.

--Ray


----- Original Message ----- 
From: "Jonathan Rochkind" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Monday, May 17, 2010 6:11 PM
Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts


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