- 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>
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