Re: [capture] keywords (was: Agenda)

On 11/21/12 12:48 PM, "Anssi Kostiainen" <anssi.kostiainen@nokia.com>
wrote:

>On 21.11.2012, at 11.34, ext NN Murthy wrote:
>
>> People associate some meaning to camera where as we mean that it is any
>> device that can help in capturing a still image. If you want, you can
>>use
>> "scanner" or "ImageInputDevice" or any such generic name.
>
>"Scanner" is a very specific term, see:
>http://en.wikipedia.org/wiki/Image_scanner
>
>"ImageInputDevice" is not much of an improvement over "Still Image
>Capture Device": it is still hard to remember, too long, and case
>sensitive (or consists of multiple words concatenated together).
>
>My point is, it is hard to come up with a generic term that works better
>than a term that is to the point most of the time. I'd argue a large
>majority of today's image capture on web-enabled devices happens via a
>camera, and not via a scanner or some other more niche image capture
>device (just look at the EXIF data stats of your favorite image hosting
>service). Given this, using "camera" as a keyword sounds reasonable to me
>at least.
>
>Btw. historically, naming discussions such as this have not been very
>productive.

I must admit being slightly confused, here.

If the goal is to enable more precise keywords in the future (such as
"scanner", or "front-camera"), there's little point in arguing about
making "camera" less specific. On the other hand if the keywords we're
using today are meant to be all encompassing, then fantasai is right and
capture should just be a boolean attribute that describes whether the file
should come from a live source (camera, camcorder, microphone) or the
filesystem. In this second scenario, the capture control type would be
exclusively defined by the accept attribute.

Maybe a note in the spec saying that this list of keyword can be extended
in the future would help clarify this.

--tobie

Received on Wednesday, 21 November 2012 12:23:28 UTC