Review solicited forapplication/cellml-1.0+xmlandapplication/cellml-1.1+xml

[Martin Duerst]

To say something in Larry's defense, language negotiation in HTTP
works reasonably well (Accept-Language). The list of languages
that the average person reads is reasonably small, and most
languages only take two (or sometimes three) letters to indicate,
so all the information can be put in a header line.

Quite a few sites use language negotiation, although there are
many more that could use it but don't. It's always good to have
a manual way to switch languages, but it's a hassle if the first
page on a site is used just to allow a user to select the language
if the browser tells the server what the preference is anyway.

Most browsers come preconfigured with the Accept-Language set
to the language of the browser (user interface) itself, and
allow further configurations (adding other languages).
Servers also got better, in Apache it was a pain to set up
default languages, but now it works much better.

For more information, please see the relevant topics at
http://www.w3.org/International/resource-index.html#lang.

There is also an IETF WG (LTRU) that works on extending the
syntax for language tags to e.g. include scripts where necessary.
Please check
http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-14.txt
(IESG approved, in RFC Editor queue) and
http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-12.txt

Regards,    Martin.


At 02:32 06/04/12, Larry Masinter wrote:
 >> > GET /models/SomeModel.xml HTTP/1.1
 >> > Host: www.example.org
 >> > Accept: application/cellml-1.0+xml; q=0.5, application/cellml-1.1+xml;
 >q=1
 >
 >HTTP content negotiation was one of those "nice in theory" protocol
 >additions that, in practice, didn't work out. The original theory of
 >content negotiation was worked out when the idea of the web was that
 >browsers would support a handful of media types (text, html, a couple
 >of image types), and so it might be reasonable to send an
 >'accept:' header listing all of the types supported. But in
 >practice as the web evolved, browsers would support hundreds of
 >types of all varieties, and even automatically locate readers for
 >content-types, so it wasn't practical to send an 'accept:' header
 >for all of the types.
 >
 >So content negotiation in practice doesn't use accept: headers
 >except in limited circumstances; for the most part, the sites send
 >some kind of 'active content' or content that autoselects for itself
 >what else to download; e.g., a HTML page which contains Javascript
 >code to detect the client's capabilities and figure out which other
 >URLs to load. The most common kind of content negotiation uses
 >the 'user agent' identification header, or some other 'x-...'
 >extension headers to detect browser versions, among other things,
 >to identify buggy implementations or proprietary extensions.
 >
 >I think we should deprecate HTTP content negotiation, if only to
 >make it clear to people reading the spec that it doesn't really
 >work that way in practice.
 >
 >Many people seem to use HTTP content negotiation as a motivation
 >for adding 'version' parameters to MIME types or registering
 >new MIME types, with the hopes that the MIME types or parameters
 >would be useful in HTTP content negotiation, and we should warn
 >them that it isn't really productive to do so. That's why it
 >might be useful advice to add to the guidelines for registering
 >MIME types, should those ever be updated.
 >
 >(I think this situation is mainly my fault, fwiw, so: I'm sorry).
 >
 >Larry