RE: [capture] making capture attribute boolean, the first stab

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 06:01:08 UTC