search-ws message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [search-ws] Accept parameter
- From: "Hammond, Tony" <t.hammond@nature.com>
- To: "Ray Denenberg, Library of Congress" <rden@loc.gov>,OASIS SWS TC <search-ws@lists.oasis-open.org>
- Date: Sat, 12 Jun 2010 12:40:10 +0100
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
********************************************************************************
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]