W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2012

Re: [capture] keywords (was: Agenda)

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 28 Nov 2012 07:50:31 -0800
Message-ID: <50B632C7.2060501@inkedblade.net>
To: Frederick.Hirsch@nokia.com
CC: tobie@fb.com, anssi.kostiainen@nokia.com, nn.murthy@cmcltd.com, public-device-apis@w3.org
On 11/27/2012 02:40 PM, Frederick.Hirsch@nokia.com wrote:
> I think what you mean is that the argument could be an enumeration of booleans, presumably an "or" of desired capture devices. This is essentially an extension of what we have now, which is a single value.
> This issue was discussed on the list before and I thought resolved, with precedence resolving conflict and so on.
> Is this a question of 'taste'/'style' or do we have a fundamental issue here? What would happen that is bad  if we did not change our approach? It sounds like keeping it would enable the extension you  mention.

The bad thing is that you now have an enumeration whose values
add the functionality of a boolean; and your enumeration
duplicates the information that *should be expressed* with the
'accept' attribute. The duplication of info is bad because
   - it creates the possibility of conflict
   - it encourages people to use the 'capture' attribute to give
     information that really belongs in 'accept'

My point in creating the extension example was, you can extend
from a boolean into the ability to select specific devices.
You don't need to start with an enum to do that. So given your
enumerated values don't add any new abilities, you should use
a boolean. And if at some point you add more specific device-
selecting abilities, you can extend the boolean to accept an
enumeration or a space-separated list or whatever.

Received on Wednesday, 28 November 2012 15:51:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:56 UTC