Re: Rewrite of feature tag syntax rules
Koen Holtman (koen@win.tue.nl)
Mon, 26 May 1997 22:07:09 +0200 (MET DST)
Martin J. Duerst:
>
>On Mon, 19 May 1997, Jeffrey Mogul wrote:
>> Fine; just introduce a map between a set of human-sensible,
>> internationalized names, and the enumerated set of feature tags.
>
>To "introduce" such a map is easy. But if it's an add-on that
>won't be implemented because the original implementors don't
>need it, it's a non-starter.
I agree this would be a non-starter as an add-on.
> The two real solutions are:
>
>- Have a syntax that allows meaningful names for the whole
> world. (This would mean e.g. URI syntax with
> correct treatment of %HH and such.)
>
>- Have a two-level system for the whole world, i.e. strictly
> limit the syntax of the lower level to something that
> can't possibly ever make sense, such as digits only.
> (This would mean e.g. digits only, with the "description
> field" mentionned by Koen used as the second level.)
What you are really asking for, with both solutions, is a large
initial startup overhead, a type of i18n tax, so that things will be
easier _if_ things develop in such a way that people will want to do
i18n for feature tags. I have concluded that people are not willing
to pay this i18n tax.
We have two levels of mapping above feature tags already: description
attributes and list responses, and both are nicely i18nized (see the
revision of the description field in the latest draft). Note that
browsers are _required_ to show the description attribute, not the
feature tags, if the attribute is present. I think this makes the
chance of the _if_ above occurring small enough.
>Regards, Martin.
Koen.