Re: Charsets and language

Standard disclaimer: pardon my ignorance, I have not reviewed the
registration process RFC well enough to know some of the things I am
commenting on here.

>From a product perspective, Yes, the vocabulary of resource features should
include the notions of language and charset.

>From a process perspective, No, the media features registry is not the
right process for establishing appropriate values of these features; there
are senior authorities already controlling vocabulary for designating
language and charset and these should be followed.

This gets back to the issue of how much semantics there is in the registry.
 Ideally there would be in the registry mechanics a formal
define-by-reference capability so that a knowledge agent could parse the
registration record and comprehend that language and charset values are
used in this application as they are defined in designated authorities
external to the registry.

So, failing my review of the registry document, I see two ways to cover the
notions of language and charset.  One is a standards-track annex to the
appropriate RFC  which extends the predefined vocabulary of features.
This, being a standards-track action can use natural language to impart its
semantics.  The other is a define-by-reference mechanism in the registry
and a registration under this clause which binds usage for these notions to
the usage already controlled by existing authorities.  The latter should
probably be formal in the sense that it defines a syntax which connotes
normative reference.

Al


At 08:31 AM 4/26/99 +0100, Graham Klyne wrote:
>This post derives from an offline discussion...
>
>An intention to register a feature for "charset" capability/preference has
>been suggested to me.  Looking at the negotiation framework for HTTP
>(specifically, the "accept-charset" and "accept-language" headers) I am
>wondering if it would make sense to also register a "language" preference
>feature at the same time.
>
>This in turn raises the idea that "charset" is a media feature, but
>"language" is a user preference.  It is my understanding that constraining
>the conneg work to "media features" was not intended to avoid
>discussion/registration of user preferences;  rather, it was intended to
>avoid us getting drawn into issues of transmission options.  Thus, it seems
>to me that the focus of our effort has been "content features" as distinct
>from, say, "transmission options".
>
>The foregoing leads me to two questions:
>(a) are registrations of features that relate to user preferences in scope
>for our registration scheme?
>(b) more specifically, is a registration of a feature for language
>preference (in the same sense as that used for HTTP "accept-language")
>appropriate?
>
>#g
>
>------------
>Graham Klyne
>([email protected])
>