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

Re: [capture] keywords (was: Agenda)

From: <Frederick.Hirsch@nokia.com>
Date: Tue, 27 Nov 2012 19:25:01 +0000
To: <anssi.kostiainen@nokia.com>
CC: <Frederick.Hirsch@nokia.com>, <tobie@fb.com>, <nn.murthy@cmcltd.com>, <public-device-apis@w3.org>, <fantasai.lists@inkedblade.net>
Message-ID: <1CB2E0B458B211478C85E11A404A2B270182C446@008-AM1MPN1-034.mgdnok.nokia.com>
Anssi 

> In line with this clarification, I renamed the generic term "A still image capture device" to a specific term "A camera" in the "Capture control type" column for the "camera" keyword.

I think the change  removing 'still image capture device'  undoes what the working group agreed, which is that the camera key word can include scanners etc. 

I would suggest reverting the change , especially as it did reflect consensus

I could suggest a minor change "A still image capture device, including cameras, scanners etc."

With regards to the list discussion of the keyword  'camera', I think it is fine to leave as is, since a scanner or other device that captures an image will include an embedded camera.

regards, Frederick

Frederick Hirsch
Nokia



On Nov 21, 2012, at 8:19 AM, Anssi Kostiainen wrote:

> On 21.11.2012, at 14.22, ext Tobie Langel wrote:
> 
>> On 11/21/12 12:48 PM, "Anssi Kostiainen" <anssi.kostiainen@nokia.com>
>> wrote:
> 
> [...]
> 
>>> 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, thanks for nicely summarizing what I was trying to say :)
> 
> The spec clearly serves the former scenario, because the accept (+ the potential live boolean) tackle the latter. I added the following note to clarify this, feel free to suggest better wording, extend it with more concrete examples etc.:
> 
> [[
> 
> A future version of this specification may define other keywords.
> 
> ]]
> 
> In line with this clarification, I renamed the generic term "A still image capture device" to a specific term "A camera" in the "Capture control type" column for the "camera" keyword.
> 
> Thanks!
> 
> -Anssi
Received on Tuesday, 27 November 2012 19:25:47 UTC

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