Re: [capture] keywords (was: Agenda)

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.

thanks

regards, Frederick

Frederick Hirsch
Nokia



On Nov 27, 2012, at 5:01 PM, ext fantasai wrote:

> On 11/27/2012 12:51 PM, Frederick.Hirsch@nokia.com wrote:
>> Tobie
>> 
>> I don't understand why it *should* be a boolean simply because we have
>> 'camera' to indicate device still image capture for a variety of devices
>> (let's ignore audio for now, as that is a different case)
> 
> Because the extent to which the values currently are distinct is
> already handled, and should therefore be expressed, by the 'accept'
> attribute.
> 
> If you want to be more specific later on, you can extend the boolean
> to take a list or something, and indicate preferences:
>  capture='front-camera, back-camera, scanner, camcorder'
> 
> But as for right now, you're just duplicating type information, and
> are therefore afaict better off just making it a boolean. It's easier
> to use, encourages people to put correct 'accept' values, and avoids
> even the possibility of mismatched values for 'capture' and 'accept'.
> 
> ~fantasai

Received on Tuesday, 27 November 2012 22:40:59 UTC