14:27:14 <RRSAgent> RRSAgent has joined #dap
14:27:14 <RRSAgent> logging to http://www.w3.org/2009/12/02-dap-irc
14:27:16 <trackbot> RRSAgent, make logs world
14:27:16 <Zakim> Zakim has joined #dap
14:27:18 <trackbot> Zakim, this will be DAP
14:27:18 <Zakim> ok, trackbot; I see UW_DAP()10:00AM scheduled to start in 33 minutes
14:27:19 <trackbot> Meeting: Device APIs and Policy Working Group Teleconference
14:27:19 <trackbot> Date: 02 December 2009
14:31:10 <tlr> regrets: thomas
14:40:27 <ilkka> dom: very OK for me if you want to be Capture API editor
14:40:44 <dom> ilkka, thanks :)
14:47:49 <Dzung_Tran> Dzung_Tran has joined #dap
14:48:01 <Dzung_Tran> Present+ Dzung_Tran
14:48:19 <paddy> paddy has joined #dap
14:48:34 <wonsuk> Present+ Wonsuk_Lee
14:50:06 <arve> Re camera/capture API
14:50:29 <arve> Is there any particularily good reason why we don't express the audio/video data as URIs?
14:51:12 <dom> hmm… the stream of data is available behind a URI; providing the data as a data: URI wouldn't work (think of a big video record)
14:52:30 <darobin> darobin has joined #dap
14:52:49 <darobin> trackbot, start meeting
14:52:51 <trackbot> RRSAgent, make logs world
14:52:53 <trackbot> Zakim, this will be DAP
14:52:53 <Zakim> ok, trackbot; I see UW_DAP()10:00AM scheduled to start in 8 minutes
14:52:54 <trackbot> Meeting: Device APIs and Policy Working Group Teleconference
14:52:54 <trackbot> Date: 02 December 2009
14:52:59 <ilkka> arve: do you mean viewfinder stream or images/videos the user takes
14:53:06 <darobin> Present+ Robin_Berjon
14:53:08 <arve> dom: No, I'm not talking about addressing the stream
14:53:11 <darobin> Chair: Robin Berjon
14:53:12 <arve> but the resource providing it
14:53:14 <dom> s/arve:/arve,/
14:53:16 <darobin> Regrets: Frederick
14:53:22 <dom> s/dom:/dom,/g
14:53:38 <arve> <video src="foo:video/camera/1/">
14:54:09 <arve> then the spec would be concerned with extracting stream data from a well-defined resource
14:54:20 <dom> oh, you're talking about the viewfinder aspect; I think we're considering it out of scope for v1 based on the recent descriptions
14:54:47 <darobin> early talk seems indeed to consider putting the VF in <video> out of scope for v1
14:54:47 <dom> s/descriptions/discussions/
14:54:48 <arve> No, I'm not talking about the viewfinder aspect
14:54:54 <arve> I'm talking about the capture aspect as well
14:55:14 <arve> darobin: the actual context is a comment from Hixie on #whatwg
14:55:26 <dom> s/darobin:/darobin,/
14:55:28 <arve> because he doesn't see the value of the proposal over <input type="file">
14:55:30 <Zakim> UW_DAP()10:00AM has now started
14:55:37 <Zakim> + +035850486aaaa
14:56:14 <arve> dom: Would a strawman spec suffice?
14:56:28 <dom> absolutely
14:56:40 <dom> s/dom:/dom,/
14:56:43 <darobin> arve, while RRSAgent is logging can you use , instead of : to address people? otherwise it gets mixed up as someone being minuted
14:57:11 <arve> darobin, sure
14:57:14 <Zakim> + +47.23.69.aabb
14:57:17 <darobin> thanks!
14:57:27 <maxf> zakim, aabb is me
14:57:27 <Zakim> +maxf; got it
14:57:47 <maxf> Present+ Max_Froumentin
14:57:47 <ilkka> Zakim, aaaa is me
14:57:47 <Zakim> +ilkka; got it
14:58:08 <dom> Present+ Dominique_Hazael-Massieux
14:58:17 <ilkka> Present+ Ilkka_Oksanen
14:58:23 <Laura_Arribas> Laura_Arribas has joined #dap
14:58:26 <Zakim> +??P3
14:58:34 <darobin> Zakim, ??P3 is me
14:58:34 <Zakim> +darobin; got it
14:58:53 <Laura_Arribas> Present+ Laura_Arribas
14:59:08 <darobin> arve, for the record, strawmen proposals are always welcome on the list of course
14:59:21 <Zakim> + +0777541aacc
14:59:21 <darobin> Laura_Arribas, you're at the top of the victims list, ready to scribe?
14:59:24 <Zakim> - +0777541aacc
14:59:33 <Zakim> +Dom
14:59:34 <Laura_Arribas> yes
14:59:38 <darobin> excellent, thanks!
14:59:40 <Laura_Arribas> but not in the call yet
14:59:42 <dom> zakim, mute me
14:59:42 <Zakim> Dom should now be muted
14:59:43 <Laura_Arribas> :)
14:59:48 <darobin> Scribe: Laura Arribas
14:59:51 <darobin> ScribeNick: Laura_Arribas 
14:59:55 <Zakim> + +0777541aadd
15:00:06 <Zakim> +??P14
15:00:15 <darobin> Zakim, who's here?
15:00:15 <Zakim> On the phone I see ilkka, maxf, darobin, Dom (muted), +0777541aadd, ??P14
15:00:17 <Zakim> On IRC I see Laura_Arribas, darobin, paddy, Dzung_Tran, Zakim, RRSAgent, wonsuk, arve, tlr, maxf, shepazu, arg, dom, lgombos, trackbot, ilkka
15:00:18 <Dzung_Tran> Can only be on Chat today, my VOIP is not working
15:00:22 <paddy> Present+ Paddy_Byers
15:00:26 <Laura_Arribas> zakim, +0777541aadd is Laura_Arribas
15:00:26 <Zakim> +Laura_Arribas; got it
15:00:33 <dom> zakim, ??P14 is probably paddy
15:00:37 <Zakim> +paddy?; got it
15:00:38 <Zakim> +Bryan_Sullivan
15:00:58 <darobin> let's wait a minute or two
15:01:13 <darobin> arve, are you calling in?
15:01:18 <BryanSullivan> BryanSullivan has joined #dap
15:01:53 <Zakim> + +0208849aaee
15:01:57 <darobin> damn you Zakim!
15:02:20 <richt> richt has joined #dap
15:02:24 <marcin> marcin has joined #dap
15:02:26 <marengo> marengo has joined #dap
15:02:27 <richt> Present+ Richard_Tibbett
15:02:38 <marengo> Present+ Marco_Marengo
15:02:45 <darobin> Zakim, who's here?
15:02:45 <Zakim> On the phone I see ilkka, maxf, darobin (muted), Dom (muted), Laura_Arribas, paddy?, Bryan_Sullivan (muted), +0208849aaee
15:02:47 <Zakim> On IRC I see marengo, marcin, richt, BryanSullivan, Laura_Arribas, darobin, paddy, Dzung_Tran, Zakim, RRSAgent, wonsuk, arve, tlr, maxf, shepazu, arg, dom, lgombos, trackbot, ilkka
15:02:54 <darobin> ok, let's get started
15:03:04 <Zakim> + +47.23.69.aaff
15:03:06 <Zakim> +[IPcaller]
15:03:09 <arve> zakim, aaff is me
15:03:09 <Zakim> +arve; got it
15:03:26 <Zakim> + +2088290aagg
15:03:36 <marcin> Zakim, aagg is marcin
15:03:36 <Zakim> +marcin; got it
15:03:50 <marcin> Present+ Marcin_Hanclik
15:04:05 <AnssiK> AnssiK has joined #dap
15:04:06 <Laura_Arribas> robin: any announcements?
15:04:09 <wonsuk> Present+ Wonsuk_Lee
15:04:18 <Zakim> + +39.011.2.aahh
15:04:21 <dom> -> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0018.html Tlr's invitation to public-web-security mailing list
15:04:22 <Laura_Arribas> ... Thomas sent an e-mail about the web security mailing list
15:04:26 <dom> zakim, who's noisy?
15:04:33 <darobin> http://www.w3.org/mid/6CA62A05-248C-43C8-91CB-BEA6B0FAF11B@nokia.com
15:04:36 <Zakim> dom, listening for 10 seconds I heard sound from the following: ilkka (19%), darobin (26%), arve (5%)
15:04:38 <Zakim> + +035850486aaii
15:04:51 <dom> zakim, mute ilkka
15:04:51 <Zakim> ilkka should now be muted
15:04:58 <dom> zakim, mute arve
15:04:58 <Zakim> arve should now be muted
15:04:58 <AnssiK> Present+ Anssi_Kostiainen
15:05:08 <Laura_Arribas> robin: minutes approved
15:05:15 <Laura_Arribas> topic: policy segment
15:05:23 <richt> q+
15:05:28 <blassey> blassey has joined #dap
15:05:31 <darobin> ack richt 
15:05:38 <Zakim> +Ingmar_Kliche
15:05:44 <AnssiK> zakim, who is on the call? 
15:05:44 <Zakim> On the phone I see ilkka (muted), maxf, darobin, Dom (muted), Laura_Arribas, paddy?, Bryan_Sullivan (muted), richt, arve (muted), wonsuk, marcin, marengo (muted), +035850486aaii
15:05:47 <Zakim> ... (muted), Ingmar_Kliche
15:05:54 <dom> dom has changed the topic to: DAP code 3279 agenda  http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0022.html register attendance with Present+ first_last, update handle with zakim, aaaa is handle
15:06:00 <Ingmar> Ingmar has joined #dap
15:06:03 <darobin> action-50?
15:06:03 <trackbot> ACTION-50 -- Richard Tibbett to add security/privacy considerations to Contacts API inspired from Geolocation -- due 2009-11-10 -- PENDINGREVIEW
15:06:03 <trackbot> http://www.w3.org/2009/dap/track/actions/50
15:06:11 <darobin> trackbot, close action-50
15:06:12 <trackbot> ACTION-50 Add security/privacy considerations to Contacts API inspired from Geolocation closed
15:06:13 <dom> Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0022.html
15:06:21 <AnssiK> zakim, aaii is AnssiK
15:06:21 <Zakim> +AnssiK; got it
15:06:28 <Laura_Arribas> richt: everybody should review the work by the Geolocation WG
15:06:34 <richt> q-
15:06:58 <Ingmar> Present+ Ingmar_Kliche
15:07:00 <paddy> q+
15:07:05 <darobin> ack paddy 
15:07:13 <Laura_Arribas> robin: any updates from the editorial pool?
15:07:38 <Laura_Arribas> paddy: took an action in BONDI F2F to provide use cases into the policy requirements doc
15:07:59 <dom> q+
15:08:11 <darobin> ack dom
15:08:31 <Laura_Arribas> paddy: action to be completed by the end of next week
15:09:14 <Laura_Arribas> dom: features and capabilities, proposal to start creating a document on those
15:09:19 <dom> -> http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0169.html Dom’s proposals for first brick of policy framework
15:09:56 <darobin> laura: I took an action to review that, but I'll do it by next call
15:10:04 <dom> ACTION: Paddy to provide use cases for the policy requirements document - due december 11
15:10:04 <trackbot> Created ACTION-69 - provide use cases for the policy requirements document [on Paddy Byers - due 2009-12-11].
15:10:15 <Suresh> Suresh has joined #dap
15:10:24 <Laura_Arribas> topic: API segment
15:10:35 <Suresh> present+ Suresh Chitturi
15:10:48 <Suresh> only via IRC for another 30mins
15:11:05 <Laura_Arribas> subtopic:  Contacts
15:11:18 <Laura_Arribas> robin: there has been an update to the contacts API
15:11:33 <dom> -> http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0246.html Contacts API updated
15:11:38 <Laura_Arribas> ... 1) list of fields
15:11:45 <Laura_Arribas> ... 2) maturity level
15:11:50 <dom> -> http://dev.w3.org/2009/dap/contacts/ Contacts API draft
15:12:10 <dom> +1 to trimming down properties for v1
15:12:23 <Laura_Arribas> richt: 1) we should have a reduced number of fields
15:12:30 <Suresh> +1
15:13:00 <BryanSullivan> OK, but We need to describe how to extend the field set
15:13:15 <dom> -> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0010.html Robin’s analysis of supported fields across existing contacts APIs
15:13:32 <BryanSullivan> This should not repeat the "distributed extensibility" debate - we need to be more practical here
15:13:37 <Laura_Arribas> ... robin's proposal in the mailing list is good
15:13:54 <Laura_Arribas> ... potential issues: we loose some requirements
15:14:00 <BryanSullivan> q+
15:14:35 <AnssiK> q+
15:14:36 <darobin> ACTION: Richard to propose the list of fields for Contacts
15:14:36 <trackbot> Created ACTION-70 - Propose the list of fields for Contacts [on Richard Tibbett - due 2009-12-09].
15:14:50 <Laura_Arribas> richt: will make a proposal on the list about which fields to drop/keep
15:14:54 <darobin> ack BryanSullivan 
15:15:18 <Laura_Arribas> Bryan_Sullivan: we need ot be sure we extend this set
15:15:27 <richt> q+
15:15:38 <Laura_Arribas> ... we need to describe how to extent this set of fields
15:15:46 <darobin> q+ to point out existing extension approaches
15:15:51 <darobin> ack AnssiK 
15:15:58 <Laura_Arribas> ... and make it available to the developers, users of the APIs
15:16:18 <Zakim> -maxf
15:16:46 <BryanSullivan> +1 to vendor-specific prefixes as one approach to extensibility - but we need to state this option clearly in the spec
15:16:57 <BryanSullivan> q-
15:17:02 <Laura_Arribas> AnssiK: if we give recommendations about the fields to use, it might work
15:17:06 <darobin> ack darobin 
15:17:06 <Zakim> darobin, you wanted to point out existing extension approaches
15:17:12 <Zakim> + +0472369aajj
15:17:17 <maxf> zakim, aajj is me
15:17:17 <Zakim> +maxf; got it
15:17:33 <Laura_Arribas> robin: it would be a good idea to mention it as a mechanism
15:17:41 <Laura_Arribas> ... but not as a normative requirement
15:17:45 <dom> PROPOSED RESOLUTION: the Contacts API provides a set of core properties that need to be supported, and suggests a prefix-based extensions mechanism for additional properties
15:17:51 <Laura_Arribas> ... is not something you can test
15:18:28 <Laura_Arribas> BryanSullivan: thinks it is testable
15:18:59 <darobin> ack richt 
15:19:25 <Laura_Arribas> richt: vendor specific prefixes are a good idea
15:20:07 <arve> q+
15:20:09 <Laura_Arribas> robin: any objections to including a note in the spec saying what the extensions should do?
15:20:13 <BryanSullivan> q+
15:20:15 <darobin> ack arve 
15:20:56 <Laura_Arribas> arve: do we actually need to mention extensibility? the CSS spec doesn't actually tell you how to do that
15:21:12 <Laura_Arribas> robin: it doesn't cost anything to say so and it helps reaching consensus
15:21:17 <darobin> ack BryanSullivan 
15:22:35 <richt> q+
15:22:42 <darobin> ack richt 
15:23:17 <darobin> +1 to richt 
15:23:55 <darobin> richt: this is about common attributes, and if OMA attributes become common, we'll support those
15:24:58 <dom> RESOLUTION: the Contacts API provides a set of core properties that need to be supported, and suggests a prefix-based extensions mechanism for additional properties
15:25:07 <BryanSullivan> re Richard's point about extensions, we expect that there will be extensions quickly if the basic set of properties is not extensible in a web runtime - independent way. we need the ability to support vocabularies such as OMA CAB (Converged Address Book)\
15:25:18 <dom> s/<dom> RESOLUTION/<Laura_Arribas> RESOLUTION/
15:25:32 <dom> q+
15:25:35 <dom> ack me
15:25:38 <darobin> ack dom
15:25:53 <richt> q+
15:26:02 <darobin> ack richt 
15:26:06 <BryanSullivan> This is needed without having to design each device web runtime to suppor the specific properties of the native client (which can change, and be a "default" or other as the "current" client).
15:26:08 <dom> zakim, mute me
15:26:08 <Zakim> Dom should now be muted
15:26:44 <dom> [ok, the roadmap for contacts mentions "Jan 2010" for contacts API http://www.w3.org/2009/dap/#roadmap]
15:27:05 <Laura_Arribas> richt: prefers to keep it as it is, filtering at name attribute
15:27:11 <Laura_Arribas> robin: agrees
15:27:18 <BryanSullivan> In essence we should have the ability to deploy web runtimes on any device, and have the property vocabulary supported by the address book client transparently supported by the API. This is the approach to be taken by AT&T in our products and devices, at least.
15:27:33 <Laura_Arribas> robin: in future, better filtering available
15:27:49 <Laura_Arribas> richt: will be putting this in the update this week
15:27:55 <Laura_Arribas> subtopic: Capture API
15:28:12 <dom> -> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0025.html First stab at the Capture API (aka Camera API) from Tran, Dzung D 
15:28:18 <darobin> http://dev.w3.org/2009/dap/camera/Overview.html
15:28:23 <dom> -> http://dev.w3.org/2009/dap/camera/ Editors draft of Capture API
15:28:47 <Laura_Arribas> robin: one of the issues arised, currenlty no way of setting requirements
15:29:29 <Dzung_Tran> Sorry, I haven't read all the email threads, what do you mean of setting requirements?
15:29:30 <Laura_Arribas> ... either we get rid of the supported ?? formats, or we keep them
15:29:41 <dom> q+
15:29:42 <Laura_Arribas> robin: personally, preferred ot keep it simple
15:29:45 <dom> ack me
15:29:46 <ilkka> q+
15:29:46 <darobin> ack dom
15:29:56 <Dzung_Tran> Oh, the different resolutions
15:30:15 <arve> there's crosstalk
15:30:56 <arve> q+
15:31:54 <darobin> q?
15:32:13 <dom> dom: +1 to keeping setting the parameter on the device for v2
15:32:41 <dom> ... we need to keep a away to determine whether a device supports recording a type of input at all, though
15:32:52 <darobin> ack ilkka 
15:32:55 <dom> ... (which supported*Formats allow to do indirectly)
15:32:58 <arve> q-
15:33:32 <darobin> q+ to talk about alternatives for detection
15:33:50 <Dzung_Tran> how do you select which resolution you want to take the image?
15:34:02 <arve> q+
15:34:20 <darobin> ack me
15:34:21 <Zakim> darobin, you wanted to talk about alternatives for detection
15:34:22 <Dzung_Tran> Are you suggesting for version 1 just default
15:34:47 <dom> Dzung_Tran, I think the user would select the resolution in the native app
15:35:01 <darobin> ack arve
15:35:25 <Laura_Arribas> robin: we could have simple methods, or not having methods present (don't really like that one)
15:35:44 <darobin> robin: we could have canCaptureXXX
15:35:49 <Dzung_Tran> I guess that would be fine. We need to put that in the spec as an assumption.
15:36:18 <maxf> +1 to <input type=photo>
15:36:20 <darobin> q+ to point out programmatic triggering
15:36:31 <darobin> ack me
15:36:32 <Zakim> darobin, you wanted to point out programmatic triggering
15:36:55 <BryanSullivan> q+
15:36:58 <Laura_Arribas> darobin: advantage of the input file even if it requires some sort of prompting
15:38:01 <Laura_Arribas> arve: the camera and all the capture devices basically are just addressable resources, this should be done in a different way as the current draft does
15:38:16 <arve> <video src="URI_FOR_CAMERA_RESOURCE">
15:38:28 <darobin> ACTION: arve to make a strawman proposal about what he things the capture should be
15:38:28 <trackbot> Created ACTION-71 - Make a strawman proposal about what he things the capture should be [on Arve Bersvendsen - due 2009-12-09].
15:38:30 <Zakim> + +1.408.216.aakk
15:38:31 <darobin> q?
15:38:32 <dom> so I guess a question that arve raises (and in which I see merit) is: is the added value of a specific API to get pictures/sounds/videos from an external app worth the efforts?
15:38:34 <darobin> ack BryanSullivan 
15:39:52 <dom> [I think the notion that widgets might want to run non-interactive processes is something we are coming back to again and again]
15:40:17 <darobin> [I agree, I'd like to use arve's on-list proposal to ferret that one out]
15:40:46 <Dzung_Tran> My thinking is that the API would access the camera device and not an external app
15:40:47 <Laura_Arribas> BryanSullivan: we need to be sure that the method of capturing an image etcdoes not mandate user involvement
15:40:57 <BryanSullivan> if <input type=photo> mandates user involvement then it does not meet the requirements
15:41:30 <dom> Dzung_Tran, the current draft reads "Launch device native camera application for taking image(s)." for captureImage, for instance
15:41:32 <darobin> q?
15:41:40 <richt> I made a proposal on the list to support both <input ...> and programmatic APIs within the same spec. Is it of relevance here?
15:41:48 <dom> http://dev.w3.org/2009/dap/camera/#widl-Capture-captureAudio
15:41:54 <Laura_Arribas> robin: suggests that Arve makes proposal to the list and Bryan to provide arguments back
15:42:06 <Dzung_Tran> Yes, that was wrong
15:42:28 <Dzung_Tran> I will update the sentence
15:42:34 <marcin> richt, +1. I assume some X0% of the (sub)-interfaces should be reusable
15:42:42 <Laura_Arribas> robin: people should review the spec by the end of next week
15:42:50 <richt> Marcin, that is my proposal.
15:42:50 <dom> Dzung_Tran, there are other aspects of the API that make this more or less implied (e.g. the limit and duration parameters)
15:43:14 <Laura_Arribas> maxf: earlier this week created a wiki page
15:43:34 <dom> arve, could you put your comment on record (not /me)? and start a thread on that question as well on the ml?
15:43:59 <dom> -> http://www.w3.org/2009/dap/wiki/SysInfo Wiki page on SysInfo
15:44:17 <Laura_Arribas> ... I wrote the battery section of the spec according to those principles (copy the moto of Geo WG)
15:44:29 <dom> -> http://dev.w3.org/2009/dap/system-info/ SysInfo draft
15:44:32 <darobin> http://dev.w3.org/2009/dap/camera/Overview.html
15:44:35 <darobin> bah
15:44:40 <Laura_Arribas> ... specially interested in the battery section
15:44:41 <darobin> what dom said :)
15:44:53 <dom> -> http://dev.w3.org/2009/dap/system-info/#power Battery API
15:45:21 <arve> Rewinding to Camera: I guess what I'm saying is that the current proposal is not a proper camera API, nor does it offer anything over <input type="file" accept="image/jpeg">
15:45:49 <tlr> tlr has joined #dap
15:45:49 <Laura_Arribas> maxf: regarding marturity, the criteria needs to be fulfilled should be an agreement on the overall list of APIs
15:46:00 <Laura_Arribas> ... will submit a refined list
15:46:10 <Laura_Arribas> ... at most 10 items
15:46:23 <Laura_Arribas> ... that will be a big stop towards FPWD
15:47:15 <Laura_Arribas> maxf: in two weeks a call for FPWD could be possible
15:47:45 <richt> arve, could you comment on this thread on the ml? http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0005.html (regardless of the output of the actual semantics that could be used)
15:48:04 <darobin> q?
15:48:18 <darobin> http://dev.w3.org/2009/dap/device/
15:48:27 <Laura_Arribas> subtopic: core devices
15:48:49 <Laura_Arribas> robin: defines an empty device interface
15:49:13 <dom> s/subtopic:/topic:/g
15:49:24 <dom> q+ to suggest publishing it at the same time as the first api that uses it
15:49:28 <Laura_Arribas> ... if people support it we could move to publish it soon
15:49:30 <dom> ack me
15:49:31 <Zakim> dom, you wanted to suggest publishing it at the same time as the first api that uses it
15:49:50 <Laura_Arribas> dom: it is a useful spec to have
15:50:04 <marcin> arve, re "does not offer anything over ...". I think that the possibility for fully programmatic character of the API is different from <input>.
15:50:15 <richt> q+
15:50:26 <darobin> ack richt 
15:50:56 <Laura_Arribas> richt: does each spec need to hook into that?
15:51:15 <Laura_Arribas> robin: if you use a navigator.device, then yes
15:51:18 <marcin> arve, captureXXX() is an equivalent to clicking on <input>.
15:51:35 <richt> is this ok? http://dev.w3.org/2009/dap/contacts/#devicecontacts-interface
15:51:38 <Laura_Arribas> ... but the hooking is fairly straighforward
15:52:14 <dom> richt, looks ok at a glance
15:52:15 <Laura_Arribas> dom: yes, you do need the hooking
15:52:20 <darobin> "Objects implementing the NavigatorDevice interface (e.g. the window.navigator.device object in Web browsers [NAVIGATOR]) provide access to the Capture interface through the Capture interface . An instance of Capture would be then obtained by using binding-specific casting methods on an instance of NavigatorDevice."
15:52:33 <dom> (vastly inspired from the geolocation API :)
15:52:44 <richt> me too in the Contacts API :-)
15:53:42 <richt> q+
15:53:43 <marcin> arve, and this could be subject to policy decision. The policy effect of prompt-web would support only <input>, whereas captureXXX() would be effective within widget-environment policies.
15:53:46 <darobin> ack richt 
15:54:17 <dom> +1 to try to keep a consistent structure
15:54:31 <Laura_Arribas> richt: general structure of the docs, do we want a specific structure? (for ex. use cases in the annex...)
15:54:52 <Laura_Arribas> ... will propose something to the list, something simple
15:55:32 <Dzung_Tran> A general outline structure would be great. Make editors life easier
15:55:37 <dom> ACTION: rich to  propose a structure for a template for API specs
15:55:37 <trackbot> Sorry, couldn't find user - rich
15:55:38 <dom> q+
15:55:48 <dom> q+ to ask about other priority APIs
15:56:03 <darobin> q?
15:56:27 <richt> q+
15:56:32 <dom> q- later
15:56:45 <Laura_Arribas> suresh: calendar API, working with richt, trying to determinte the use cases
15:57:11 <Laura_Arribas> ... use cases an requirements
15:57:32 <Laura_Arribas> richt: we also had a discussion about the attributes
15:57:55 <dom> q+ to talk on calendar properties
15:57:58 <Laura_Arribas> ... related to the contacts API discussion on attributes
15:58:00 <dom> ack richt
15:58:17 <dom> ack me
15:58:17 <Zakim> dom, you wanted to ask about other priority APIs and to talk on calendar properties
15:59:08 <richt> q+
15:59:14 <richt> ack richt
15:59:50 <Dzung_Tran> You can just create another directory under CVS and move the file or check it in again
15:59:58 <dom> ack richt
16:00:37 <darobin> q+ dom to talk about priorities
16:01:14 <arve> dom: as a general policy, yes
16:01:23 <darobin> s/dom:/dom,/
16:01:34 <Laura_Arribas> robin: we should go through the fields in the list, being very careful if reducing the number
16:04:08 <blassey> blassey has joined #dap
16:04:10 <darobin> Laura_Arribas, it's online so no need to capture it :)
16:04:13 <wonsuk> wonsuk has left #dap
16:04:20 <Zakim> -Bryan_Sullivan
16:04:28 <Zakim> -Dom
16:04:32 <Zakim> -ilkka
16:04:35 <Zakim> -marcin
16:04:38 <Zakim> -paddy?
16:04:38 <Zakim> -richt
16:04:40 <darobin> RRSAgent, make minutes
16:04:40 <RRSAgent> I have made the request to generate http://www.w3.org/2009/12/02-dap-minutes.html darobin
16:04:40 <Zakim> -arve
16:04:43 <Zakim> -wonsuk
16:04:46 <Zakim> -marengo
16:04:48 <Zakim> - +1.408.216.aakk
16:04:51 <Zakim> -maxf
16:04:52 <darobin> bah
16:04:56 <arve> I really don't want us to reinvent the wheel
16:04:58 <arve> again
16:04:59 <Zakim> -Ingmar_Kliche
16:04:59 <darobin> RRSAgent, make log public
16:05:01 <darobin> RRSAgent, make minutes
16:05:01 <RRSAgent> I have made the request to generate http://www.w3.org/2009/12/02-dap-minutes.html darobin
16:05:07 <Zakim> -AnssiK
16:05:13 <darobin> RRSAgentm bye
16:05:15 <darobin> RRSAgent, bye
16:05:15 <RRSAgent> I see 4 open action items saved in http://www.w3.org/2009/12/02-dap-actions.rdf :
16:05:15 <RRSAgent> ACTION: Paddy to provide use cases for the policy requirements document - due december 11 [1]
16:05:15 <RRSAgent>   recorded in http://www.w3.org/2009/12/02-dap-irc#T15-10-04
16:05:15 <RRSAgent> ACTION: Richard to propose the list of fields for Contacts [2]
16:05:15 <RRSAgent>   recorded in http://www.w3.org/2009/12/02-dap-irc#T15-14-36
16:05:15 <RRSAgent> ACTION: arve to make a strawman proposal about what he things the capture should be [3]
16:05:15 <RRSAgent>   recorded in http://www.w3.org/2009/12/02-dap-irc#T15-38-28
16:05:15 <RRSAgent> ACTION: rich to  propose a structure for a template for API specs [4]
16:05:15 <RRSAgent>   recorded in http://www.w3.org/2009/12/02-dap-irc#T15-55-37
16:05:16 <Zakim> -Laura_Arribas