atom feed20 messages in org.oasis-open.lists.search-ws-commentRe: [search-ws-comment] searchRetriev...
FromSent OnAttachments
Tim WilliamsAug 11, 2009 5:02 am 
LeVan,RalphAug 11, 2009 6:24 am 
Tim WilliamsAug 11, 2009 7:56 am 
LeVan,RalphAug 11, 2009 8:00 am 
Tim WilliamsAug 11, 2009 10:02 am 
Hammond, TonyAug 12, 2009 12:36 am 
Tim WilliamsAug 12, 2009 4:32 am 
Hammond, TonyAug 12, 2009 7:40 am 
Tim WilliamsAug 12, 2009 8:09 am 
Matthew DoveyAug 12, 2009 8:28 am 
Matthew DoveyAug 12, 2009 8:30 am 
Tim WilliamsAug 12, 2009 9:12 am 
Hammond, TonyAug 14, 2009 5:54 am 
Hammond, TonyAug 14, 2009 6:16 am 
Ray Denenberg, Library of CongressAug 14, 2009 7:04 am 
LeVan,RalphAug 14, 2009 7:42 am 
LeVan,RalphAug 14, 2009 7:51 am 
Ray Denenberg, Library of CongressAug 14, 2009 11:44 am 
Hammond, TonyAug 20, 2009 6:27 am 
Ray Denenberg, Library of CongressSep 14, 2009 11:59 am 
Subject:Re: [search-ws-comment] searchRetrieve Accept Parameters
From:Tim Williams (will@gmail.com)
Date:Aug 12, 2009 4:32:06 am
List:org.oasis-open.lists.search-ws-comment

On Wed, Aug 12, 2009 at 3:36 AM, Hammond, Tony<t.ha@nature.com> wrote:

Hi Tim:

discussion somewhere that explains the rationale/need for supplying custom http-style parameters (sec 4.9) that duplicate the HTTP Headers

I think that relying on content negotiation alone would place the bar to entry at an unacceptably high level.

Why? The Web as a whole has gotten along fine this way:)

I would also note that many applications do not support HTTP semantics. Markup is one such application where anchored link elements (<a>) are mapped to simple GET requests. Not much scope there for adding in HTTP header directives. Nor for making alternate HTTP method calls.

I would think it a fair assumption that applications that want to use a spec that is layered on HTTP, must support HTTP semantics. In your example of an "a" element, the browser adds the HTTP Accept header for the user with quality indicators - and its much better positioned to do so since it actually knows what media types it supports. Programmatic clients obviously have more freedom. In either case, there needs to be a way to indicate which media type can be expected from the target URL and that should be done with a "type" attribute, like OpenSearch.

(Always wondered what would be the effect of allowing e.g. a 'method="DELETE"' attribute.;)

You'd be overloading the HTTP method - generally a bad thing.

Seems to me that OpenSearch does not preclude content negotiation which is purely an HTTP application-level operation. It merely specifies the binding of an endpoint (or endpoint template rather) to a media type (which is a required attribute). As you say content negotiation could work on an OpenSearch description to select the right link type.

I'm not sure I understand your point here. The "type" attribute in OpenSearch is (as I understand it) meant to allow the client to select an appropriate representation - its still up to the client to have Accept headers that support that representation.

SRU needs the ability to specify a media-typed endpoint in order to embrace OpenSearch.

I think I'm starting to see the dilemma. OpenSearch has a descriptor with a Url element that allows it to express "this link is a 'text/html' representation" via its "type" element, whereas, SRU only has a URL - leaving less expressive flexibility. But the equivalent to OpenSearch's 'type' element isn't an 'Accept' header. The former is simply a factual declaration of the media type on the other end of a URL, whereas the later is an indication from the client of desired/preferred content types. Would you envision the httpMethod parameter being expanded to indicate multiple media types with 'quality' and 'level' precedence parameters?

To allow also for an "in URL" means of selecting the media type means that links to specific representations can be included directly in document markup, RDF graphs, etc. is a win all round. And this is in addition to allowing for HTTP content negotiation - which is anyway a tricky thing to master at best,

Links can already be included to specific representations. It seems the crux of the issue is that SRU is limited to a URL and, therefore, trying to stuff all things within the URL. Why not have a non-normative section stating how the URL might be used in several standard markup languages to indicate the representation of a given URL? It seems that the current spec is going down the path of a complete protocol (SOAP-style) that happens to ride over HTTP, vs. just embracing HTTP. IMHO, this is going to lead to problems (e.g. resolving conflicts between request parameters).

--tim

Tony

On 11/8/09 18:03, "Tim Williams" <will@gmail.com> wrote:

Thanks Ralph, Applications that use the opensearch description document shouldn't care about the URL beyond templated parameters they need to replace - parameters like "r=rss" should only be useful to the server trying to dispatch to the correct handler.  Content negotiation is initiated by the client selecting the Url whose "type" attribute is one the client understands, such as Firefox choosing the Url with type="text/html".

I don't know where ya'll are in the comment process, if the group has settled on this, I'll just drop it.  However, I think this is a *really* bad approach that should be fleshed out more - mainly to let HTTP take care of conneg.  Since OpenSearch was the basis for adding these in, has that group provided feedback on this?

--tim

On Tue, Aug 11, 2009 at 11:01 AM, LeVan,Ralph<lev@oclc.org> wrote:

There is nothing about URL templates that stop content negotiation.  But, the applications that are using OpenSearch description documents do not typically do that.  They rely on the URL to do the right thing for them.

Take a look at some of those description documents.  You'll see plenty of examples of parameters that look like "&r=rss".  That's embedded content negotiation.

Ralph

-----Original Message----- From: Tim Williams [mailto:will@gmail.com] Sent: Tuesday, August 11, 2009 10:57 AM To: LeVan,Ralph Cc: sear@lists.oasis-open.org Subject: Re: [search-ws-comment] searchRetrieve Accept Parameters

Really?  URLTemplates don't preclude you from regular HTTP content negotiation - it's ultimately just a URL.  I've implemented opensearch and relied on regular HTTP conneg, is there something I'm missing here?

--tim

On Tue, Aug 11, 2009 at 9:25 AM, LeVan,Ralph<lev@oclc.org> wrote:

The need comes from the OpenSearch community.  They communicate with servers using URL templates and have no way of specifying the format of the response, other than through parameters in the URL.  So, they, and hence we, must embed content negotiation in our URLs.

Ralph

-----Original Message----- From: Tim Williams [mailto:will@gmail.com] Sent: Tuesday, August 11, 2009 8:03 AM To: sear@lists.oasis-open.org Subject: [search-ws-comment] searchRetrieve Accept Parameters

I'm reading the sru-2-0-draft dated July 22, 2009.  Is there discussion somewhere that explains the rationale/need for supplying custom http-style parameters (sec 4.9) that duplicate the HTTP Headers themselves?

Thanks, --tim

-- This publicly archived list offers a means to provide input to the OASIS Search Web Services TC.

In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting.

Subscribe: sear@lists.oasis-open.org Unsubscribe: sear@lists.oasis-open.org List help: sear@lists.oasis-open.org List archive: http://lists.oasis-open.org/archives/search-ws-comment/ Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: http://www.oasis-open.org/maillists/guidelines.php Committee: http://www.oasis- open.org/committees/tc_home.php?wg_abbrev=search-ws Join OASIS: http://www.oasis-open.org/join/

-- This publicly archived list offers a means to provide input to the OASIS Search Web Services TC.

In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting.

Subscribe: sear@lists.oasis-open.org Unsubscribe: sear@lists.oasis-open.org List help: sear@lists.oasis-open.org List archive: http://lists.oasis-open.org/archives/search-ws-comment/ Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: http://www.oasis-open.org/maillists/guidelines.php Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=search-ws Join OASIS: http://www.oasis-open.org/join/

******************************************************************************** DISCLAIMER: This e-mail is confidential and should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Neither Macmillan Publishers Limited nor any of its agents accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Macmillan Publishers Limited or one of its agents. Please note that neither Macmillan Publishers Limited nor any of its agents accept any responsibility for viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any). No contracts may be concluded on behalf of Macmillan Publishers Limited or its agents by means of e-mail communication. Macmillan Publishers Limited Registered in England and Wales with registered number 785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS ********************************************************************************

-- This publicly archived list offers a means to provide input to the OASIS Search Web Services TC.

In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting.

Subscribe: sear@lists.oasis-open.org Unsubscribe: sear@lists.oasis-open.org List help: sear@lists.oasis-open.org List archive: http://lists.oasis-open.org/archives/search-ws-comment/ Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: http://www.oasis-open.org/maillists/guidelines.php Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=search-ws Join OASIS: http://www.oasis-open.org/join/