Hi,

Does the current draft include any support for asynchronous operation
of the protocol (either by status notifications and polling and/or
streaming), e.g some chunk of results coming back before others?
Sometime ago I read through an early draft published on the LOC site
and it mentioned support for federated search but it's hard to imagine
how could that be implemented without any async support.

On Tue, May 18, 2010 at 12:39 AM, Jonathan Rochkind <[log in to unmask]> wrote:
> Cool, we're on the same page.
>
> This means that the "asset" parameter not only does not need to be, but
> should NOT be, an actual parameterized value in the OpenSearch desc URL
> template, in contrast to Tony's current SRU-in-opensearch-extension draft
> spec.
>
> At least that's my argument. Seems pretty clear to me.
>
> Make sense:
>
> <Url type="application/rss+xml"
> template="http://my-sru-server.com?q={searchTerms}&amp;accept=application%2Frss"/>
>
> Does NOT make sense:
>
> <Url type="application/rss+xml"
> template="http://my-sru-server.com?q={searchTerms}&amp;accept={sru:accept}"/>
>
> [that parameter conflicts with the type in the Url template, does not make
> sense to be parameterized in the OpenSearch URL template.  Whether it's
> parameterized to your SRU server is of no concern of OpenSearch, but to the
> extent it's in the URL, it has to be FIXED in the OpenSearch URL template.
> Is my argument. ]
>
>
>
> Ray Denenberg, Library of Congress wrote:
>>
>> "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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>
>>
>



-- 

Cheers,
Jakub