[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [search-ws-comment] searchRetrieve Accept Parameters
On Wed, Aug 12, 2009 at 3:36 AM, Hammond, Tony<t.hammond@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" <williamstw@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<levan@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:williamstw@gmail.com] >>>> Sent: Tuesday, August 11, 2009 10:57 AM >>>> To: LeVan,Ralph >>>> Cc: search-ws-comment@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<levan@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:williamstw@gmail.com] >>>>>> Sent: Tuesday, August 11, 2009 8:03 AM >>>>>> To: search-ws-comment@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: search-ws-comment-subscribe@lists.oasis-open.org >>>>>> Unsubscribe: search-ws-comment-unsubscribe@lists.oasis-open.org >>>>>> List help: search-ws-comment-help@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: search-ws-comment-subscribe@lists.oasis-open.org >> Unsubscribe: search-ws-comment-unsubscribe@lists.oasis-open.org >> List help: search-ws-comment-help@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 > ******************************************************************************** > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]