"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}&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}&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
>>>>>
>>>>>
>>>>>
>>
>>
