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

On Wed, Aug 12, 2009 at 3:36 AM, Hammond, Tony<t.ha...@nature.com> wrote:

Why?  The Web as a whole has gotten along fine this way:)

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.

You'd be overloading the HTTP method - generally a bad thing.

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.

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?

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).