Re: [search-ws] Accept parameter

["Hammond, Tony" <t.hammond@nature.com>]

Title: Re: [search-ws] Accept parameter

Hi Ray:

Sure. My thoughts are that we absolutely need to retain this parameter in order to identify alternate representations and to facilitate representation management.

While it is true that one can use the HTTP machinery to effect content negotiation by sending an HTTP Accept header to an endpoint, in practice we need to use two items of information to specify the representation: a) a URI for a resource, and b) a media type to select a suitable representation of that resource. That means that there is no means to refer within an HTML document to a given representation by means of a simple hyperlink as there is no means to specify a media type within an HTML anchor. (The HTML anchor seems to assume a simple representation model.)

As far as I can tell the main reason for wanting to use content negotiation and serve multiple representations from the same endpoint is this directive in AWWW (3.5.1. URI persistence):

    “A URI owner SHOULD provide representations of the identified resource consistently and predictably.”
    http://www.w3.org/TR/webarch/#URI-persistence

This section goes on to say:

    “In addition, content negotiation also promotes consistency, as a site manager is not required to define new URIs when adding support for a new format specification.”

The referenced document

   Cool URIs don’t change
   http://www.w3.org/Provider/Style/URI
 
goes on to describe how URIs can be hardened by removing all particulars (e.g. filenmame extensions, etc) and how content negotiation can be used to that purpose. (Note that this is related to – but not identical to – the principle of URI opacity.)

There does not seem to be any ‘best’ way.  There are two alternate scenarios:

    A. Single endpoint, content negotiation

    B. Multiple endpoints

Abandoning the ‘httpAccept’ parameter means that we are severely limited in dealing with scenario B. Some link applications do support media type, e.g. HTML <link> elements have ‘type’ attributes, and OpenSearch description documents have <Url> elements also with ‘type’ attributes. By contrast, HTML <a> elements have no attribute for media type and so cannot make use of content negotiation to select a representation but must accept whatever default is provided. 

This leads to the following considerations:

    1. No ability to globally identify representations (i.e. by URI)

        – representations may only be selected by using a tuple, i.e. (endpoint URI, media-type)

        - HTML anchors cannot be used

    2. Increased barrier to SRU implementors who would need to implement HTTP content negotiation

Maintaining the ‘httpAccept’ parameter, on the other hand, means that both scenarios A and B can be preserved. It means that it is up to the SRU implementor to choose the best arrangement for their local circumstances, whether they are adept at handling content negotiation, or not.

Cheers,

Tony




On 10/6/10 22:57, "Ray Denenberg, Library of Congress" <rden@loc.gov> wrote:

> Reconsideration of the accept parameter is another topic for discussion Monday, given the discussion that occurred on the code4lib list.  I am not at all inclined to want to get rid of this parameter but we need to defend it. 
>  
> Tony, since you won't be able to make the call Monday perhaps you could post your thoughts on this before the call. 
>  
> --Ray

********************************************************************************   
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   
********************************************************************************