Fw: Fw: [search-ws] ResponseType parm and Accept header are equivalent (and some implications of that)

["Ray Denenberg, Library of Congress" <rden@loc.gov>]

forwarding message from Farrukh since his post to the list apparently 
bounced.

----- Original Message ----- 
From: "Farrukh Najmi" <farrukh@wellfleetsoftware.com>
To: "Ray Denenberg, Library of Congress" <rden@loc.gov>
Cc: <search-ws@lists.oasis-open.org>
Sent: Wednesday, February 25, 2009 5:59 PM
Subject: Re: Fw: [search-ws] ResponseType parm and Accept header are 
equivalent (and some implications of that)


> Dear Colleagues,
>
> I am an observer in the TC but thought you may find my input useful...
>
> I feel the http:accept option is the best of the choices listed.
>
> WADL is likely to be an important spec and REST specs may define their 
> interface in WADL
> quite commonly in future.
>
> Next, IMHO "accept" is acceptable as it matches the HTTP header it 
> mirrors.
>
> "responseType" is not good because it does not match the HTTP header it 
> mirrors.
>
> '$' is a particularly "not so good" choice as it has implication in many 
> processing environment in non-standard ways. Lets not add to that 
> practice.
>
> HTH.
>
> Ray Denenberg, Library of Congress wrote:
>> Please read the message below from Andy.    We had changed the name of 
>> the responseType parameter to 'accept' and then to '$accept', and now he 
>> suggests that we instead name it 'http:accept'.
>>
>> So the choices are: responseType, accept, $accept, and http:accept.
>>
>> He also suggests that we add similar parameters for Accept-Charset, 
>> Accept-Language, and Accept-Encoding.
>>
>> Opinion, please.
>>
>> --Ray
>>
>> ----- Original Message ----- From: "Houghton,Andrew" <houghtoa@oclc.org>
>> To: "Houghton,Andrew" <houghtoa@oclc.org>; "Young,Jeff (OR)" 
>> <jyoung@oclc.org>; "LeVan,Ralph" <levan@oclc.org>; "Ray Denenberg, 
>> Library of Congress" <rden@loc.gov>
>> Sent: Friday, February 20, 2009 11:44 AM
>> Subject: RE: [search-ws] ResponseType parm and Accept header are 
>> equivalent (and some implications of that)
>>
>>
>> Previously, I made the suggestion of using a '$' prefix to indicate 
>> information that normally would be obtained from HTTP headers.  I'm going 
>> to back off that suggestion and make another suggestion in light of my 
>> recent work with WADL for our LDA project.  When using WADL to describe 
>> Web based services it allows you specify the parameters used in URI 
>> queries.  However, the names of these parameters must conform to 
>> xsd:NMToken.  A '$' is not a character allowed by xsd:NMToken.  The WADL 
>> specification is quite restrictive for what is allowed as a query 
>> parameter name given IETF RFC 3986 "Uniform Resource Identifier (URI): 
>> Generic Syntax" which allows '$' in addition to many other characters. 
>> Given this discrepancy between RFC 3986 and WADL, I would like to propose 
>> another suggestion for your consideration. We will be using the following 
>> suggestion for our LDA project.  Since WADL restricts a query parameter 
>> name to xsd:NMToken and xsd:NMToken allows ':' one could steal an idea 
>> from the micro formats community, just prefix the HTTP specific query 
>> parameter names with http: so you have:
>>
>> http:Accept
>> http:Accept-Charset
>> http:Accept-Language
>> http:Accept-Encoding
>>
>>
>> Andy.
>>
>>> -----Original Message-----
>>> From: Houghton,Andrew
>>> Sent: Thursday, January 22, 2009 12:12 PM
>>> To: Young,Jeff (OR); LeVan,Ralph; 'Ray Denenberg, Library of Congress';
>>> 'search-ws@lists.oasis-open.org'
>>> Subject: RE: [search-ws] ResponseType parm and Accept header are
>>> equivalent (and some implications of that)
>>>
>>> Jeff got the intent of my message exactly correct.  I apologize about
>>> the wording of my message I should probably not been so terse and I
>>> didn't mean to offend or upset anybody.
>>>
>>> Andy.
>>>
>>> > -----Original Message-----
>>> > From: Young,Jeff (OR)
>>> > Sent: Thursday, January 22, 2009 12:08 PM
>>> > To: LeVan,Ralph; Houghton,Andrew; 'Ray Denenberg, Library of
>>> Congress';
>>> > 'search-ws@lists.oasis-open.org'
>>> > Subject: RE: [search-ws] ResponseType parm and Accept header are
>>> > equivalent (and some implications of that)
>>> >
>>> > I could be wrong, but I assume that Andy is suggesting that the '$'
>>> > indicates information that normally would be obtained from HTTP
>>> > headers. The labels, then should presumably match those headers. Even
>>> > though this is a novel idea, it is easily and usefully generalized
>>> > beyond SRU.
>>> >
>>> > Jeff
>>> >
>>> > > -----Original Message-----
>>> > > From: LeVan,Ralph
>>> > > Sent: Thursday, January 22, 2009 11:43 AM
>>> > > To: Houghton,Andrew; 'Ray Denenberg, Library of Congress'; 'search-
>>> > > ws@lists.oasis-open.org'
>>> > > Cc: Young,Jeff (OR)
>>> > > Subject: RE: [search-ws] ResponseType parm and Accept header are
>>> > > equivalent (and some implications of that)
>>> > >
>>> > > I would never have guessed that ‘$’ was a legal character in a URL.
>>> > I
>>> > > have no problem with that suggestion, but take some exception to
>>> the
>>> > > phrase “distinguishes them from SRU specific query parameters”.
>>> > These are
>>> > > definitely SRU specific parameters.  They are not parameters
>>> commonly
>>> > > accepted in other URLs.  Nor are they parameters specific to SRU
>>> > queries.
>>> > >
>>> > >
>>> > >
>>> > > But, $accept does help reflect the more global implication of the
>>> > parm.
>>> > >
>>> > >
>>> > >
>>> > > Ralph
>>> > >
>>> > >
>>> > >
>>> > > From: Houghton,Andrew
>>> > > Sent: Thursday, January 22, 2009 11:36 AM
>>> > > To: Ray Denenberg, Library of Congress; LeVan,Ralph; search-
>>> > > ws@lists.oasis-open.org
>>> > > Cc: Young,Jeff (OR)
>>> > > Subject: RE: [search-ws] ResponseType parm and Accept header are
>>> > > equivalent (and some implications of that)
>>> > >
>>> > >
>>> > >
>>> > > My only suggestion here would be consider prefixing these types of
>>> > content
>>> > > negotiation query parameter with something that distinguishes them
>>> > from
>>> > > SRU specific query parameters.  For example use $accept, $accept-
>>> > charset,
>>> > > $accept-language, $accept-encoding, etc.  There are also additional
>>> > > implications in regard to HTTP status codes and responses.  If
>>> > someone
>>> > > adds $accept=application/rss+xml to the SRU query parameters and
>>> the
>>> > SRU
>>> > > server only supports Atom, application/atom+xml, then the SRU
>>> server
>>> > > should respond with HTTP 406 Not Acceptable.
>>> > >
>>> > >
>>> > >
>>> > > Andy.
>>> > >
>>> > >
>>> > >
>>> > > From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
>>> > > Sent: Thursday, January 22, 2009 11:00 AM
>>> > > To: LeVan,Ralph; search-ws@lists.oasis-open.org
>>> > > Cc: Young,Jeff (OR); Houghton,Andrew
>>> > > Subject: Re: [search-ws] ResponseType parm and Accept header are
>>> > > equivalent (and some implications of that)
>>> > >
>>> > >
>>> > >
>>> > > I finally got around to this as well as the earlier message, sorry
>>> > for the
>>> > > delay.
>>> > >
>>> > >
>>> > >
>>> > >  I agree with Ralph (to the extent that I understand it).
>>> > >
>>> > >
>>> > >
>>> > > Thanks Ralph.
>>> > >
>>> > >
>>> > >
>>> > > --Ray
>>> > >
>>> > > ----- Original Message -----
>>> > >
>>> > > From: LeVan,Ralph <mailto:levan@oclc.org>
>>> > >
>>> > > To: search-ws@lists.oasis-open.org
>>> > >
>>> > > Cc: Young,Jeff (OR) <mailto:jyoung@oclc.org>  ; Houghton,Andrew
>>> > > <mailto:houghtoa@oclc.org>
>>> > >
>>> > > Sent: Monday, January 19, 2009 2:59 PM
>>> > >
>>> > > Subject: [search-ws] ResponseType parm and Accept header are
>>> > > equivalent (and some implications of that)
>>> > >
>>> > >
>>> > >
>>> > > I claim that our new responseType parameter is equivalent to an
>>> > HTTP
>>> > > Accept header.  The purpose of the parameter is to allow the client
>>> > to be
>>> > > able to specify the mime type of the response.  (As a provocative
>>> > aside, I
>>> > > further claim that current SRU servers could deliver non-SRU
>>> > responses to
>>> > > SRU requests today on the basis of Accept headers.  All we’re doing
>>> > in our
>>> > > standards work is agreeing on how to express that Accept header in
>>> > our
>>> > > URLs.)
>>> > >
>>> > >
>>> > >
>>> > > I propose that we change the name of the responseType parameter
>>> > to
>>> > > “accept”.  There is no reason for us to invent a new name for
>>> > something
>>> > > that has well-understood semantics.  (My co-workers suspect that
>>> > there are
>>> > > other HTTP headers that we may also want to represent in our URLs,
>>> > but
>>> > > we’ll leave them for the day when we have a real use case.)
>>> > >
>>> > >
>>> > >
>>> > > I’ve been discussing this topic with some of my co-workers and
>>> > there
>>> > > are some implications of this recognition that our parameter is an
>>> > > alternative to an Accept header.
>>> > >
>>> > >
>>> > >
>>> > > I believe our current documentation says that the mime-type of an
>>> > > SRU response is text/xml.  We need to change that to application/x-
>>> > sru+xml
>>> > > and need to start the process of registering our mime-type with
>>> IANA
>>> > so we
>>> > > can get rid of the x- part.
>>> > >
>>> > >
>>> > >
>>> > > If an SRU server supports multiple mime types and uses content
>>> > > negotiation to determine the mime-type of the response, then the
>>> > server
>>> > > should proved a URL in the Content-Location header of the response
>>> > > pointing directly to the response in that mime-type.  For instance,
>>> > if the
>>> > > client had sent the URL http://example.org/sru?query=dog with an
>>> > Accept
>>> > > header of “application/rss+xml”, then the server should return a
>>> > Content-
>>> > > Location value of
>>> > > http://example.org/sru?query=dog&accept=application/rss+xml.  This
>>> > > Content-Header is returned along with the content itself,
>>> presumably
>>> > in
>>> > > the application/rss+xml format.  It would also be acceptable to
>>> have
>>> > > returned a redirect to that URL instead, but that behavior is not
>>> > > encouraged as it is inefficient.
>>> > >
>>> > >
>>> > >
>>> > > Even in the absence of an Accept header, this behavior becomes
>>> > > important.  If there was no Accept header or an Accept header of
>>> “*”
>>> > and a
>>> > > URL of http://example.org/sru?query=dog,  our standard says that
>>> the
>>> > > response should be of the mime-type application/x-sru+xml.  That
>>> > means
>>> > > that there was, in fact, content negotiation going on and a
>>> Content-
>>> > > Location header of
>>> > http://example.org/sru?query=dog&accept=application/x-
>>> > > sru+xml should be returned with the response.
>>> > >
>>> > >
>>> > >
>>> > > I believe that this behavior needs to be documented as part of
>>> > the
>>> > > change to accept the accept parameter.
>>> > >
>>> > >
>>> > >
>>> > > Ralph
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>
>
> -- 
> Regards,
> Farrukh
>
> Web: http://www.wellfleetsoftware.com
>
>