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

[admin] updated Last Call resolution for LC-2644 to refer to change to boolean solution

From: <Frederick.Hirsch@nokia.com>
Date: Thu, 6 Dec 2012 14:22:18 +0000
To: <nn.murthy@cmcltd.com>
CC: <Frederick.Hirsch@nokia.com>, <anssi.kostiainen@nokia.com>, <public-device-apis@w3.org>
Message-ID: <1CB2E0B458B211478C85E11A404A2B270184FE4B@008-AM1MPN1-033.mgdnok.nokia.com>
NNM

Much thanks

I have updated the tracker resolution for this comment to refer to changing to boolean as a resolution and point to your  email below.

https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-html-media-capture-20120712/doc/

thanks

regards, Frederick

Frederick Hirsch, Nokia
Chair, W3C DAP Working Group





On Dec 6, 2012, at 12:59 AM, ext NN Murthy wrote:

> Whether desired device is document scanner or live scanner, if MIME main
> type is image, it is sufficient and meets very large number of use cases.
> The reason earlier I have been asking for a change is that with word
> "Camera", people who are reading the document understand differently. With
> Boolean implementation, that ambiguity is gone.
> NNM
> 
> -----Original Message-----
> From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com] 
> Sent: 05 December 2012 20:15
> To: nn.murthy@cmcltd.com
> Cc: Frederick.Hirsch@nokia.com; anssi.kostiainen@nokia.com;
> public-device-apis@w3.org
> Subject: Re: [capture] making capture attribute boolean, the first stab
> 
> 
> if the desired device were a scanner would it have a different accept MIME
> type?
> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> 
> 
> On Nov 30, 2012, at 2:22 AM, ext NN Murthy wrote:
> 
>> It is interesting and addressing the issue we have to specify a device 
>> type such as "camera" or some other device type.
>> 
>> -----Original Message-----
>> From: Anssi Kostiainen [mailto:anssi.kostiainen@nokia.com]
>> Sent: 29 November 2012 21:17
>> To: DAP public-device-apis@w3.org
>> Subject: [capture] making capture attribute boolean, the first stab
>> 
>> Hi,
>> 
>> As per my ACTION-595, and as discussed on the yesterday's call, I 
>> started to look at how the HTML Media Capture spec might look like -- 
>> and what the implications might be -- if we'd make the capture 
>> attribute a boolean instead of an enumerated attribute.
>> 
>> The short rationale is that we don't want to duplicate the information 
>> that is already expressed with the accept attribute. Also, given the 
>> feature is not yet widely deployed, we can probably still change things
> for better.
>> 
>> I started writing the proposal in a mail first, but quickly found out 
>> it would be easier for everyone if I make an unofficial draft instead 
>> so that you'll get a proper diff etc.
>> 
>> So I branched the spec, and reworked it. I also added new examples 
>> that should clarify how the revised spec would actually be used in 
>> both simple declarative-only scenario based on an HTML form, and in 
>> more advanced use cases involving scripting, such as upload via XHR, 
>> or drawing the captured image to a canvas on the client-side. I also 
>> wanted to clarify that uploading of the file is optional and that this 
>> feature is useful in client-side only scenarios too.
>> 
>> The "new" unofficial version with a boolean capture is at: 
>> 
>> http://dev.w3.org/2009/dap/camera/unofficial.html
>> 
>> The "old" Editor's Draft with an enumerated attribute is at:
>> 
>> http://dev.w3.org/2009/dap/camera/
>> 
>> The diff:
>> 
>> 
>> http://dev.w3.org/cvsweb/2009/dap/camera/unofficial.html.diff?r1=1.1;r
>> 2=1.2;
>> f=h
>> 
>> That said, I'm looking for feedback whether we should go the boolean
> route.
>> Also suggestions how to make the boolean spec better are welcome. 
>> There are probably some rough edges as I drafted this one rather quickly.
>> 
>> -Anssi
>> 
>> ______________________________________________________________________
>> ________
>> 
>> DISCLAIMER
>> 
>> The information contained in this e-mail message and/or attachments to 
>> it may contain confidential or privileged information. If you are not 
>> the intended recipient, any dissemination, use, review, distribution, 
>> printing or copying of the information contained in this e-mail 
>> message and/or attachments to it are strictly prohibited. If you have 
>> received this communication in error, please notify us by reply e-mail 
>> or directly to netsupport@cmcltd.com or telephone and immediately and 
>> permanently delete the message and any attachments. Thank you.
>> 
>> ______________________________________________________________________
>> ________
>> 
>> This email has been scrubbed for your protection by SecureMX.
>> For more information visit http://securemx.in 
>> ______________________________________________________________________
>> _______
>> 
> 
> 
> ______________________________________________________________________________
> 
> DISCLAIMER
> 
> The information contained in this e-mail message and/or attachments to it may
> contain confidential or privileged information. If you are not the intended
> recipient, any dissemination, use, review, distribution, printing or copying
> of the information contained in this e-mail message and/or attachments to it
> are strictly prohibited. If you have received this communication in error,
> please notify us by reply e-mail or directly to netsupport@cmcltd.com or
> telephone and immediately and permanently delete the message and any
> attachments. Thank you.
> 
> ______________________________________________________________________________
> 
> This email has been scrubbed for your protection by SecureMX.
> For more information visit http://securemx.in
> _____________________________________________________________________________
> 
Received on Thursday, 6 December 2012 14:22:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 6 December 2012 14:23:00 GMT