[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 10:41 AM, Hammond, Tony<t.hammond@nature.com> wrote: > 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? Yeah, I haven't reviewed Explain in depth but it definitely appears to be the best place in the SRU family so far. > 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. Don't get me wrong, I'm supportive of urls that give some indication of the format - and most implementors will likely expose different formats via different URI patterns (its a little easier to dispatch on anyway), the question is only whether that should be a part of the spec or not - and I suggest not. btw, is there an updated Explain draft? All I can find is on the LOC site so far. Thanks, --tim > > 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]