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

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

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