Re: Rewrite of feature tag syntax rules

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.

Received on Monday, 26 May 1997 13:11:04 UTC