[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [search-ws-comment] searchRetrieve Accept Parameters
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. 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. (Always wondered what would be the effect of allowing e.g. a 'method="DELETE"' attribute.;) 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. SRU needs the ability to specify a media-typed endpoint in order to embrace OpenSearch. 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, 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]