[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [search-ws-comment] searchRetrieve Accept Parameters
Hi Tim: > 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 Presumably the place to include this is in the Explain record which is the counterpart of the OpenSearch Description? That said, and it does seem a good idea to me, I would still maintain that a simple parameter for selecting media type is a useful fallback for clients that do not (or are unable or unwilling) to tangle with HTTP headers. There's a lot to be said for self-describing URLs. Cheers, Tony On 12/8/09 12:32, "Tim Williams" <williamstw@gmail.com> wrote: > 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]