00:02:03 RRSAgent has joined #dap 00:02:03 logging to http://www.w3.org/2011/03/16-dap-irc 00:02:05 RRSAgent, make logs world 00:02:05 Zakim has joined #dap 00:02:07 Zakim, this will be DAP 00:02:07 ok, trackbot; I see UW_DAP(DAPWGF2F)7:00PM scheduled to start 62 minutes ago 00:02:08 Meeting: Device APIs and Policy Working Group Teleconference 00:02:08 Date: 15 March 2011 00:02:14 Present+ Soonho_Lee 00:02:34 Present+ Dominique_Hazael-Massieux 00:02:49 Sorry for not attending meeting in this morning. 00:03:16 I will be there afternoon. 00:03:30 shan has joined #dap 00:03:52 Present+ Soonbo_Han 00:04:04 marengo has joined #dap 00:04:18 bryan_sullivan has joined #dap 00:04:28 present+ bryan_sullivan 00:04:32 UW_DAP(DAPWGF2F)7:00PM has now started 00:04:39 +??P2 00:04:49 Kangchan has joined #dap 00:04:50 Zakim, ??P2 is DAPWG 00:04:50 +DAPWG; got it 00:05:01 Present+ Marco_Marengo 00:05:37 minkyo has joined #dap 00:06:06 +Suresh 00:07:10 donghyun_kang has joined #DAP 00:08:08 fjh has joined #dap 00:08:37 trackbot-ng, start telecon 00:08:40 RRSAgent, make logs world 00:08:42 Zakim, this will be DAP 00:08:42 ok, trackbot, I see UW_DAP(DAPWGF2F)7:00PM already started 00:08:43 Meeting: Device APIs and Policy Working Group Teleconference 00:08:43 Date: 15 March 2011 00:08:48 RRSAgent, this meeting span midnight 00:08:48 I'm logging. I don't understand 'this meeting span midnight', dom. Try /msg RRSAgent help 00:08:57 RRSAgent, this meeting spans midnight 00:09:04 Chair: Robin_Berjon, Frederick_Hirsch 00:09:14 AnssiK has joined #dap 00:09:21 Liao_Jun has joined #dap 00:09:23 Present+ DongHyun_Kang 00:09:25 Present+ Robin_Berjon, Frederick_Hirsch 00:09:32 Chen has joined #dap 00:09:33 sungok has joined #dap 00:09:40 Present+ Jun_Liao 00:09:55 ktaklee has joined #dap 00:09:58 +??P4 00:10:01 Agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_15,_16,_18_March_2011,_Seoul 00:10:03 Chen_Bo has joined #dap 00:10:06 Present+ Kyung-Tak_Lee 00:10:07 darobin has joined #dap 00:10:19 zakim, +??P4 is AnssiK 00:10:19 sorry, AnssiK, I do not recognize a party named '+??P4' 00:10:20 Present+ Bo_Chen 00:10:26 homata__ has joined #dap 00:10:26 present+ Kangchan_Lee 00:10:28 zakim, ??P4 is AnssiK 00:10:28 +AnssiK; got it 00:10:34 Present+ Anssi_Kostiainen 00:10:38 ScribeNick: bryan 00:10:47 BJ has joined #dap 00:10:47 ScribeNick: bryan_sullivan 00:11:27 Topic: Admin 00:11:29 Present+ Minkyo_in 00:12:55 yes 00:12:59 Can we swap the morning and afternoon items in today's agenda? 00:13:10 Present+ sungok_you 00:13:24 Suresh, which items specifically would you like to switch? 00:13:24 agenda bashing... 00:13:41 wuj has joined #dap 00:14:16 Liang has joined #dap 00:15:04 minkyo has left #dap 00:15:26 zakim, who is here? 00:15:26 On the phone I see DAPWG, Suresh, AnssiK 00:15:27 On IRC I see Liang, wuj, BJ, homata__, darobin, Chen_Bo, ktaklee, sungok, Liao_Jun, AnssiK, fjh, donghyun_kang, Kangchan, bryan_sullivan, marengo, shan, Zakim, RRSAgent, soonho, 00:15:29 ... Suresh, homata_, richt, ilkka, lgombos, ingmar, dom, trackbot 00:18:14 topic: sysinfo and sensors 00:18:34 + +1.781.534.aaaa 00:18:45 Present+ Laszlo_Gombos 00:18:57 zakim, aaaa is laszlo 00:18:57 +laszlo; got it 00:19:02 bryan: is this discussion in context of breaking sysinfo into pieces? 00:19:02 Bryan: 1st question: are we tackling this in context of new strategy for sysinfo with breaking it apart? 00:19:10 dom: where are we going and how 00:19:21 -> http://dev.w3.org/2009/dap/system-info/ SysInfo editors draft 00:19:39 Did we talk about a vocabulary approach, yesterday? 00:20:46 http://dev.w3.org/2009/dap/system-info/#system-properties 00:20:52 we did talk about how sysinfo relates to vocabulary-based approaches 00:20:58 bryan: what are the key functional blocks to consider as discrete APIs? 00:21:15 minkyo has joined #dap 00:21:49 bryan: how do the info access methods also influence the split? 00:22:17 To me it would be good to split the properties into static (display size, etc) and dynamic (connecttivity, etc) 00:22:38 dom: there are two parts, accessing device characteristics and monitoring dynamic properties 00:23:12 For static properties, we could define a very simple getPropXX () type API and for dynamic APIs decide how we want to proceed 00:24:17 the current SystemInfo API draft is almost as extensive as /proc (procfs) in UNIX-like OSs 00:24:26 bryan: are the properties to be split per static and dynamic, or by the functional group e.g. connection info 00:24:54 cf. http://en.wikipedia.org/wiki/Procfs 00:24:57 dom: the first step is to see what can be split out, e.g. connection info, and get editor volunteers 00:26:24 dom: suggestion to dive into the blocks, starting with the network info. this should be split out into a spec of its own 00:26:33 bryan: capabilities and status? 00:27:55 -> http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0076.html Rich's proposal for simple Network API 00:28:32 +1 for the Network 00:28:52 dom: the next step is to find an editor for the network info API 00:28:53 I plan to take an iteration on the network part 00:29:02 Battery would be another, which IMHO should not have privacy issues 00:29:05 -> http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0058.html navigator.connection in Android 00:29:32 +1 to Rich's proposal 00:30:03 Gyubong has joined #dap 00:30:11 dom: for the network API, richt made a proposal for the network API 00:30:15 Present+ Gyubong_Oh 00:30:16 i mean we could adopt a similar style to most of the sys info properties 00:30:31 dom: laslo or suresh, do you want to take this on? 00:31:58 ACTION: Suresh to provide first draft of Network Connection API 00:31:58 Created ACTION-357 - Provide first draft of Network Connection API [on Suresh Chitturi - due 2011-03-23]. 00:31:59 suresh: will take on the network info API 00:33:11 dom: next, anssi mentioned that battery was likely simple enough re privacy and is useful. we don't have a concrete proposal, but the current content in sysinfo can be used as a start 00:33:12 Battery status 00:33:37 ACTION: Anssi to provide first editors draft of a Battery status API 00:33:37 Created ACTION-358 - Provide first editors draft of a Battery status API [on Anssi Kostiainen - due 2011-03-23]. 00:34:27 dom: next was the thermometer, we could put this on the back burner 00:34:52 darobin: ok to put more things on the back burner 00:35:09 ACTION-358: Web Performance WG was interested on battery status — probably need coordination 00:35:09 ACTION-358 Provide first editors draft of a Battery status API notes added 00:35:40 CPU is something device vendors like to keep it to themselves 00:36:03 CPU is candidate for backburnering 00:37:00 dom: next is CPU, it is unsure whether there are strong use cases for it; could be related to performance, e.g. the Web performance group is focused on battery impacts 00:37:55 https://developer.mozilla.org/en/DOM/window.navigator.oscpu 00:37:56 dom: for the sensors, we have the question of a generic sensor API. Anssi sent something about what is available in android 00:37:57 https://developer.mozilla.org/en/DOM/window.navigator.platform 00:38:42 anssik: not me 00:38:54 Chen_Bo has joined #dap 00:39:37 bryan: I can take on the sensors, but need to know what the plan is for a generic API for this 00:39:43 Zakim, who's noisy? 00:40:00 dom, listening for 14 seconds I heard sound from the following: DAPWG (90%) 00:40:09 dom: sysinfo as it exists could be a start 00:40:45 bryan: i can put things in documents but I am not necessarily the technical SME 00:41:21 ACTION: Bryan to split out a generic sensors API (based on ambientlight/proximity/etc) from sysinfo 00:41:21 Created ACTION-359 - Split out a generic sensors API (based on ambientlight/proximity/etc) from sysinfo [on Bryan Sullivan - due 2011-03-23]. 00:41:54 navigator.platform and navigator.oscpu expose CPU-related information already today, works in Moz, Chrome, Saf at least 00:42:19 what I'm not sure is if developers are using that information 00:43:26 dom: most of the other things are about static properties of the device, most re privacy have abilities re fingerprinting (building a unique identifier based upon device capabilities) 00:44:11 Anssi, but that is only the OS information not info such frequency, processor info, etc 00:44:18 q+ to ask do we have a use case that is not fulfilled with the existing platform and oscpu properties on the navigator 00:44:25 dom: we could start with considering which are most useful 00:45:20 dom: suresh, are the static properties e.g. cameras microphones etc of interest 00:45:35 suresh: can take on those 00:46:11 ACTION: Suresh to see at possibilities of APIs for access to device characteristics 00:46:11 Created ACTION-360 - See at possibilities of APIs for access to device characteristics [on Suresh Chitturi - due 2011-03-23]. 00:46:55 I assume device characteristics are 'read-only'? 00:47:43 bryan: should we package the dynamic I/O APIs as a package? 00:48:29 dom: we should consider that for each feature we want to make available rather than in the abstract 00:48:56 I heard Bryan or Suresh say something about screen related props, for existing ones, see: http://www.quirksmode.org/dom/w3c_cssom.html 00:49:08 wonsuk has joined #dap 00:49:23 Present+ Wonsuk_Lee 00:49:39 CSS OM exposes much information that is useful for developers, such as the dimensions of the viewport 00:49:59 ACTION: Bryan to provide use cases for device characteristics access 00:49:59 Created ACTION-361 - Provide use cases for device characteristics access [on Bryan Sullivan - due 2011-03-23]. 00:50:00 q+ to clarify the Screen part 00:50:07 ack AnssiK 00:50:07 AnssiK, you wanted to ask do we have a use case that is not fulfilled with the existing platform and oscpu properties on the navigator and to clarify the Screen part 00:51:11 bryan: I will look into the dynamic I/O properties and provide some input, as I think these are related in value to some of the sensor properties, not in terms of a common API but just to help focus what we repackage in the new APIs 00:52:14 dom: CSSOM addresses a number of important characteristics from the dsplay 00:52:55 bryan: would CSSOM provide a pattern for audio? 00:53:14 dom: no, mostly for display characteristics 00:54:39 dom: that covers a first plan for sysinfo 00:55:09 bryan: what about storage? 00:55:21 dom: proposed work in webapps might cover that 00:55:35 darobin: unsure whether it covers all of it 00:56:05 -> http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0346.html Quota API discussion in WebApps 00:56:45 q- 00:57:52 dom: suggest not to work on this given overlap with the work in webapps e.g. with filesystem 00:58:01 dom: probably covers most of what would be useful for storage 00:59:11 bryan: conceptually this is in the same ballpark as filesystem operations, e.g. to see the size of a filesystem 01:00:57 kangchan: the use cases are hard to understand, in Korea there are many projects e.g. for n-screen and mobile cloud computing, and sysinfo is unique in the world providing the access to this info. We can look at the use cases and provide additional input. 01:01:08 ACTION: Kangchan to provide use cases for sysinfo-like features 01:01:08 Created ACTION-362 - Provide use cases for sysinfo-like features [on Kangchan Lee - due 2011-03-23]. 01:02:33 topic: messaging 01:02:36 s/the use cases are hard to understand/the use case is very helpful to understand the recommendation/ 01:02:47 q+ to clarify the change in direction for Messaging 01:03:04 ack Sureash 01:03:07 ack Suresh 01:03:07 Suresh, you wanted to clarify the change in direction for Messaging 01:03:13 -> http://lists.w3.org/Archives/Public/public-device-apis/2011Mar/0036.html Dom's Messaging proposal 01:03:18 s/ack Sureash// 01:03:24 rrsagent, generate minutes 01:03:24 I have made the request to generate http://www.w3.org/2011/03/16-dap-minutes.html fjh 01:03:48 suresh: missed last week's discussion, if the group has agreed to simplify this, what is it based upon? 01:04:30 We clearly say in the scope that the API complements the URI schemes, so this is not competing with URI schemes 01:04:33 dom: the discussion last week was based upon earlier discussion that this is related to what can be done with URI schemes 01:05:08 dom: the latest proposal I sent for messaging is feature-equivalent to the draft we have currently published as working draft 01:06:51 Super simplification would not allow us to extend in the future if we were to add folder management, search, etc. 01:08:20 wuj_ has joined #dap 01:09:09 But is there a real concern with the current API? Why don't wait for some time to see if there are real issues with implementing as it is 01:09:46 dom: re extensbility, we can consider more and mroe advancef features separately, but the majority of send message is covered by the URI scheme proposal. Creating wrappers around URI based methods can also fill the gaps. 01:10:42 we also talked about the need to separate the design for different messaging technology and ease of use... 01:10:43 dom: the previous proposal is not integrated well into the Web architecture 01:11:01 s/mroe advancef/more advanced/ 01:12:01 dom: the two existing proposals are mostly feature equivalent 01:12:41 This is the same anaolgy we have between using HTML Media Capture and Camera 01:13:11 s/anaolgy/analogy/ 01:13:14 bryan: the other use cases e.g. read/receive are not in the current API anyway, and can be considered for future work 01:15:05 the point i was making was can we have the two models co-exist, URI schemes and a detailed programtic style API 01:16:01 dom: implementers don't want to develop duplicate features 01:16:27 dom: the stream API is significantly different from HTML media capture 01:17:05 dom: even if we do consider a programmatic API eventually, that doesn't mean we need to start with it 01:17:06 From ease of use, developers would want to be able to set properties than creating a URL to populate them 01:17:40 dom: a start may be to update the current draft with the new proposal, and call for feedback before moving forward 01:18:04 dom: having an interface to build messages is a convenience function 01:18:17 darobin: libraries can do that 01:18:41 relying on libaries is not the same as having a standard API 01:18:56 implemented in the browser.... 01:19:00 dom: there are good reasons on both sides, let's put the two proposals on the table 01:19:15 PROPOSED RESOLUTION: publish new messaging API as WD and ask for feedback (esp. from developers and implementors) 01:19:16 +1 01:19:26 perhpas as you suggest we should have a call for implementations 01:19:55 s/perhpas/perhaps/ 01:21:44 RESOLUTION: publish new messaging API as WD and ask for feedback (esp. from developers and implementors) 01:21:56 ACTION: Dom to see with Maria on how to proceed for updated messaging api draft 01:21:56 Created ACTION-363 - See with Maria on how to proceed for updated messaging api draft [on Dominique Hazaël-Massieux - due 2011-03-23]. 01:22:00 just to summarize, we would present both the proposals and ask for feedback right> 01:22:14 indeed, suresh 01:22:20 thanks! 01:22:53 -DAPWG 01:24:28 -Suresh 01:34:00 blassey has joined #dap 01:57:51 +Suresh 01:58:59 minkyo has joined #dap 01:59:05 +??P2 01:59:17 ??P2 is DAPWG 01:59:19 zakim, who is here? 01:59:19 On the phone I see AnssiK, laszlo, Suresh, ??P2 01:59:20 On IRC I see minkyo, blassey, wuj_, wonsuk, Chen_Bo, Liang, BJ, homata__, darobin, ktaklee, sungok, AnssiK, fjh, donghyun_kang, Kangchan, bryan_sullivan, shan, Zakim, RRSAgent, 01:59:21 Zakim, who's on the bridge 01:59:23 ... soonho, Suresh, homata_, richt, ilkka, lgombos, ingmar, dom, trackbot 01:59:25 I don't understand 'who's on the bridge', dom 01:59:27 Zakim, who's on the bridge? 01:59:27 I don't understand your question, dom. 01:59:33 Zakim, who's on the phone? 01:59:33 On the phone I see AnssiK, laszlo, Suresh, ??P2 02:02:10 i will be here until noon session 02:02:15 topic: feature permissions 02:02:28 http://lists.w3.org/Archives/Public/public-device-apis/2011Mar/0012.html 02:02:57 marengo has joined #dap 02:03:21 Gyubonh has joined #dap 02:03:59 anssik: the feature permissions spec is being produced by web notiifications group 02:04:00 http://dev.w3.org/2006/webapi/WebNotifications/publish/FeaturePermissions.html 02:04:39 anssik: the deliverable is proposed to be moved to DAP 02:04:44 I reached John Gregg and touch based on the spec 02:05:28 http://dev.w3.org/2009/dap/docs/feat-perms/feat-perms.html 02:05:30 anssik: I have done some investigation and as demo that implements this with a usable interface 02:05:42 Gyubong has joined #dap 02:05:49 John Gregg has no particular plan to advance the spec for the needs that the WebNotification group has 02:05:51 Present+ Gyubong_Oh 02:06:38 anssik: the demo should run in any browser; open the link and click the run buttons which will execute the code and show an information bar 02:07:20 http://dev.w3.org/2009/dap/docs/feat-perms/feat-perms.html#changes 02:07:37 anssik: some changes have been proposed to the DAP spec based upon the investigation 02:09:18 anssik: suggest to use this demo to evaluate whether this is a good idea to decouple the permissions from the API invocations; this is just one way to implement the UI, e.g. from usability point of view, e.g. a drag and drop API from the chrome to the page. Constrained devices would need other UI approaches. 02:09:41 +10 on prototypes 02:10:07 dom: this is a good way to consider our motivation to do this work 02:10:46 dom: this could be useful for other specs outside DAP, e.g. geolocation, some APIs in webapps etc 02:11:20 http://dev.w3.org/2009/dap/features/ 02:11:26 dom: if you can bring in the Feature Permissions spec and propose changes based upon the investigation, that would be a start 02:11:56 dom: I think we should merge the two 02:12:02 dom: a question is the relationship to the current API perms draft 02:12:57 lgombos: I have looked at this and we should merge the two specs - there are a few APIs with valid scope - we should consider what other APIs would possibly be in scope 02:14:09 dom: first we need to get and editor, integrate anssi's comments, and the APIs in scope, and then go to FPWD or contact the other groups to let them know we have this work and a prototype, so see if they are interested. The first step is to take ownership of the spec. 02:14:32 logombos: will take on the spec merging task 02:14:48 s/get and editor,/get an editors draft in DAP space/ 02:16:02 Contacts/Calendar? but we may need Rich.. 02:16:13 I'm happy to help Laszlo with editing Feat Perms 02:17:23 Liao_Jun has joined #dap 02:17:33 topic: success criteria 02:19:37 -AnssiK 02:20:04 suresh expressed concern about chartering limiting to browser context rather than also allowing widgets 02:20:16 suresh: we left off where my comment was that the success criteria based upon the default browser model is too restrictive; we should avoid discussions re whether an approach will not work in the browser context but consider it more broadly, e.g. a policy framework can enable the apps to run the same in a browser or widget context 02:21:35 fjh: unclear about the reference to framework - our rationales were discussed e.g. avoiding plugins - our result was that this does not preclude widgets as long as plugins were not involved 02:22:16 dom: the current charter references the browser context as the main reference point 02:22:18 thanks DOM 02:22:26 s/DOM/dom 02:23:18 darobin: everything that works in a browser should work in a widget, but the converse is not true 02:23:53 +??P3 02:24:18 dom: a concrete example is e.g. we discussed message reading as out of scope as its difficult to see how to implement this in a browser context due to security 02:24:20 replacing the current statement with "APIs that can be demonstrated 02:24:20 without the need of a specialized policy framework will be released" is a good 02:24:20 alternative to indicate that the APIs will be demonstrated using the web 02:24:20 runtime only and not with the assumption of an underlying policy framewrok 02:24:20 which appeared to be the main concern from browser vendors 02:24:47 AnssiK has joined #dap 02:24:58 fjh: as rechartering we are increasing scope, and will have trouble delivering 02:24:58 "without the need of a specialised policy framework" doesn't really help — it needs to also be safe 02:25:12 and if it's safe and works without policy — then it works in a browser 02:25:53 dom: what we have heard from browser vendors is that they object to working on things that don't work in the open web 02:26:16 wuj_ has joined #dap 02:26:25 s/increasing scope/increasing number of deliverables/ 02:26:31 s/trouble/enough work/ 02:26:39 suresh: we need to understand the "open web" and what works in different contexts more clearly 02:26:51 AnssiK1 has joined #dap 02:26:55 s/delivering/delivering, might not be wise to add more 02:27:09 AnssiK has joined #dap 02:27:11 rrsagent, generate minutes 02:27:11 I have made the request to generate http://www.w3.org/2011/03/16-dap-minutes.html fjh 02:27:15 suresh: I would rather that we stay silent or generic on the context 02:27:37 darobin: it is generic, we need APIs that are safe in an untrusted environment 02:28:14 dom: a main hypothesis is that if it works in the browser it should work in other contexts 02:29:07 Suresh, are you trying to make it so that the group scope included non-browsers-compatible APIs, or are you trying to clarify that our APIs will also work beyond the browser context? 02:29:47 dom: given the group's current progress, we should not expand the charter scope 02:30:31 suresh: do we expect tests to demonstrate ability to use the APIs in both browser and widget contexts? 02:32:18 suresh: the discussions that are concerning are those e.g. saving contacts not having a simple way to represent in the browser context, which unecessarily limit the implementation choices 02:33:23 dom: the concerns about usability and security are constraints on the process, which needs to verify whether things are really usable and safe 02:33:35 s/process/design process/ 02:34:30 suresh: how do we capture these objectives in the charter, and keep the door open to flexibility in API design? 02:35:01 dom: unless we can prove it works in a browser context, we should not work on it 02:36:09 dom: there are a number of criteria to consider, the best way to prove something works is to provide a prototype 02:36:29 dom: the intent of the charter scope is to limit meta discussions 02:37:27 dom: re including widgets in the charter, we have made some efforts to remove it to prevent misconceptions, but new text can be proposed on the list 02:37:56 suresh: the issue seemed to be more with the security than widgets 02:38:07 s/security/policy framework/ 02:38:28 suresh: my proposal was to say e.g. if the API is designed to run without a policy framework, it passes the criteria 02:38:50 suresh: is that something that can be in the success crieria? 02:39:50 bryan: could we rephrase this as "installable web applications" instead of widgets, to be more generic? 02:39:57 s/crieria/criteria/ 02:41:03 suresh: does the success criteria affect also the design of the API? 02:42:34 dom: the difficulty we have is to convince browser vendors that the DAP APIs are important to them. We would live with the current criteria in the charter and consider the results on an API by API basis e.g. what contexts are supported and how the success criteria is met 02:42:48 s/is met/is met during CR/ 02:43:09 "However, this does not preclude the APIs to be demonstrated in Widgets or Installed environments" 02:43:36 suresh: we should have a statement re "the intent is not to preclude..." 02:44:12 darobin has joined #dap 02:44:53 darobin: the restrictions are focused around ensuring the APIs work in a Web context 02:45:47 suresh: will add something to the charter based upon Suresh's proposals, e.g. referencing "not precluding support for installable web applications". 02:47:22 s/suresh:/dom:/ 02:47:40 topic: security 02:47:52 darobin: where is content security policy going? 02:48:29 -> https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-unofficial-draft-20110303.html Content Security Policy 02:48:34 dom: this is a mozilla-led spec intended to limit XSS attack, enabling external website resources to be used safely 02:48:39 Chen_Bo has joined #dap 02:49:17 dom: robin asked where this is going - a charter for "Web Applications Security" was sent to the AC a year ago - it's delayed to find a chair and determine interest 02:49:35 dom: this included CORS and UMP 02:52:20 darobin: our work may include a "COW" document "Characterization of the Open Web" (what are the properties that define the open web) - as a way to be clear about our scope critera 02:53:09 dom: we could throw some ideas on the wiki to see what sticks 02:53:19 ACTION: Robin to get the COW started 02:53:20 Created ACTION-364 - Get the COW started [on Robin Berjon - due 2011-03-23]. 02:53:41 ACTION: Frederick to help raise the COW 02:53:41 Created ACTION-365 - Help raise the COW [on Frederick Hirsch - due 2011-03-23]. 02:54:16 wuj_ has joined #dap 02:55:00 bryan: this would include security approaches, right? 02:55:12 darobin: yes, trust and security 02:58:16 bryan: this will be important to help us find the way forward on security, what is being provided by other groups, and how what we have drafted already (e.g. feature permissions) fits in an "open web" model as compared to a widget model 02:58:43 topic: testing 02:59:03 ACTION-298? 02:59:03 ACTION-298 -- Dominique Hazaël-Massieux to work with rich on test-enabling the contacts API -- due 2011-03-09 -- OPEN 02:59:03 http://www.w3.org/2009/dap/track/actions/298 02:59:03 darobin: we need to test contacts soon 02:59:10 close ACTION-348 02:59:11 ACTION-348 Send concrete proposal for navigator.sendMessage with URI scheme closed 02:59:53 bryan: what basis for framework and examples wll be used to start? 03:00:37 dom: we earlier agreed to use the Webapps javascript framework as used in the HTML tests, XHR, etc 03:00:52 DAP wiki for testing , including framework -> http://www.w3.org/2009/dap/wiki/Testing 03:01:28 dom: one struggle will be defining a test environment e.g. due to dependency upon underlying data, which may require loading of fake data 03:02:19 Dom is planning on testing related to contacts, so is Rich, plan to make call for contributions later 03:04:44 I presented the QUnit-based approach to unit testing at the last f2f 03:05:30 http://www.w3.org/2009/dap/wiki/Testing#Notes_on_testing_framework_used_by_Phonegap 03:05:41 fjh: what about HTML media capture? 03:05:46 the group decided to align with the WebApps WG harness instead 03:05:51 dom: we are stuck 03:05:59 topic: HTML media capture 03:06:06 so I have not made further progress on the unit testing front after that 03:07:00 darobin: the "role" attribute is intended for assistive technologies and not for other purposes - we need to find another approach 03:07:00 I believe jgraham of Opera is the original author of the WebApps harness contributed to W3C 03:07:16 but I'm not 100% sure, Opera participants probably know the best 03:07:31 ACTION: Dom to restart with HTML WG on getting new attribute for HTML Media Capture 03:07:31 Created ACTION-366 - Restart with HTML WG on getting new attribute for HTML Media Capture [on Dominique Hazaël-Massieux - due 2011-03-23]. 03:07:58 fjh: we need to update the draft and can then go to last call 03:08:20 darobin: better to put out a new WD first 03:09:00 darobin: a draft will help get feedback from the HTML WG 03:09:01 ACTION: Dom to update HTML Media Capture with new attribute 03:09:01 Created ACTION-367 - Update HTML Media Capture with new attribute [on Dominique Hazaël-Massieux - due 2011-03-23]. 03:09:15 ACTION-366: todo after ACTION-367 03:09:15 ACTION-366 Restart with HTML WG on getting new attribute for HTML Media Capture notes added 03:09:30 plan is to update HTML Media capture, then publish new WD, get feedback, then consider last call 03:10:25 http://www.w3.org/TR/test-methodology/ 03:10:32 bryan: what are the steps in getting ready for tests? 03:10:44 darobin: there is a methodology 03:11:11 Gyubong_ has joined #dap 03:11:13 linked from http://www.w3.org/2009/dap/wiki/Testing 03:11:25 Present+ Gyubong_Oh 03:11:56 dom: the best way is to identify test assertions and tests to cover them 03:12:24 fjh: the spec editors need to use the document markup conventions supporting the test assertions 03:13:16 dom: it's more important to just get started on the test assertions 03:13:51 s/the test assertions/creating tests, and then progress through an interative process/ 03:14:31 fjh: the test assertions and tests are essential to move spec further in the process... 03:18:07 -> http://www.w3.org/2011/track-privacy/ Web Tracking and User Privacy Workshop, April 28-29 03:19:35 [we're breaking until 2pm local time] 03:27:36 -??P3 03:29:55 -Suresh 03:50:31 homata has joined #dap 03:55:28 -laszlo 03:59:51 AnssiK has joined #dap 04:06:32 AnssiK has joined #dap 04:31:31 marengo has joined #dap 04:31:38 minkyo has joined #dap 04:35:00 darobin has joined #dap 04:51:11