"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" <[email protected]>
To: <[email protected]>
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:[email protected]] On Behalf Of
Robert Sanderson
Sent: Monday, May 17, 2010 3:44 PM
To: [email protected]
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 <[email protected]> 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:[email protected]] On Behalf
Of
Jonathan Rochkind
Sent: Monday, May 17, 2010 3:18 PM
To: [email protected]
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
