Re: Standardize Buttons For TV-Web Remotes?

It is simply a matter of best practices to define normative conventions for
avoiding collisions when arbitrary parties can create names. That is why we
have .com, .org, etc in domain names; that is why Unicode has a private use
area and doesn't allow users to define character codes outside such area.
Java has a convention for ensuring non-collision of package names.
Furthermore, you don't want a third party creating a name and then in the
future you want to revise the standard to include a standard definition that
would use or reuse such a private name.

If you don't want to define a convention to permit avoiding collisions
between 3rd parties, at least define a convention that all private uses must
employ in order to distinguish from standard use. In CSS, property names
that start with '-' (HYPHEN) are considered private uses; in MIME types,
sub-types that start with "x-" are considered private use.

Now is the time to define a convention, and not later when private uses
impose constraints on new standard uses.

Regards,
Glenn

On Wed, May 25, 2011 at 10:11 AM, Doug Schepers <schepers@w3.org> wrote:

> Hi, Glenn-
>
> Glenn Adams wrote (on 5/25/11 12:20 AM):
>
>  Thanks, this looks good. My only remaining concern is in regards to
>> implementation defined key values. The definition:
>>
>> [[
>> If there is no appropriate key value in the key values set, then a key
>> value must be devised. The key value should be as human friendly as
>> possible and must not contain whitespace characters. The value must be
>> composed only of characters in the ranges \u0030..\u0039,
>> \u0041..\u005A, or \u0061..\u007A, and must begin with a character in
>> the range \u0041..\u005A.
>> ]]
>>
>> is not adequate to prevent name collisions between custom definitions.
>> Some normative convention is needed to prevent collisions.
>>
>
> What conflicts do you anticipate?
>
> Even if there are keys on different devices that have the same values,
> webapps can still interpret the pressing of those keys in whatever way works
> best for that application; this is the intent of the key value feature.
>
> The main goal of listing key values explicitly is to promote convergence,
> not to differentiate between implementations.  I am very reluctant to add a
> convention that promotes the proliferation, rather than reduction and
> coordination, of new key values.  While such things are useful for certain
> types of extensions (new events, for example), I don't think they will be
> useful in this case, because they aren't associated with functionality
> exposed to webapps... they are only the indication that a particular button
> or key was pressed, and don't trigger any specific webapp feature (other
> than what the webapp itself "assigns" to that key value, via script).
>
> In any case, I believe that this is a comment that could be addressed in
> Last Call, because it does not introduce any normative changes to
> implementations.  Unless you see this as an issue that blocks us moving to
> Last Call, I believe the most prudent course of action is for us to do so.
>
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG, WebApps, and Web Events WGs
>