See also: IRC log
<trackbot> Date: 16 March 2011
<soonho> Sorry for not attending meeting in this morning.
<soonho> I will be there afternoon.
<fjh> trackbot-ng, start telecon
<trackbot> Meeting: Device APIs and Policy Working Group Teleconference
<trackbot> Date: 16 March 2011
<fjh> ScribeNick: bryan
<fjh> ScribeNick: bryan_sullivan
<AnssiK> yes
<Suresh> Can we swap the morning and afternoon items in today's agenda?
<dom> Suresh, which items specifically would you like to switch?
<fjh> agenda bashing...
bryan: is this discussion in context of breaking sysinfo into pieces?
<dom> Bryan: 1st question: are we tackling this in context of new strategy for sysinfo with breaking it apart?
dom: where are we going and how
<dom> SysInfo editors draft
<Suresh> Did we talk about a vocabulary approach, yesterday?
<fjh> http://dev.w3.org/2009/dap/system-info/#system-properties
<dom> we did talk about how sysinfo relates to vocabulary-based approaches
bryan: what are the key functional blocks to consider as discrete APIs?
... how do the info access methods also influence the split?
<Suresh> To me it would be good to split the properties into static (display size, etc) and dynamic (connecttivity, etc)
dom: there are two parts, accessing device characteristics and monitoring dynamic properties
<Suresh> For static properties, we could define a very simple getPropXX () type API and for dynamic APIs decide how we want to proceed
<AnssiK> the current SystemInfo API draft is almost as extensive as /proc (procfs) in UNIX-like OSs
bryan: are the properties to be split per static and dynamic, or by the functional group e.g. connection info
<AnssiK> cf. http://en.wikipedia.org/wiki/Procfs
dom: the first step is to see what can be split out, e.g. connection info, and get editor volunteers
... suggestion to dive into the blocks, starting with the network info. this should be split out into a spec of its own
bryan: capabilities and status?
<dom> Rich's proposal for simple Network API
<AnssiK> +1 for the Network
dom: the next step is to find an editor for the network info API
<lgombos> I plan to take an iteration on the network part
<AnssiK> Battery would be another, which IMHO should not have privacy issues
<dom> navigator.connection in Android
<Suresh> +1 to Rich's proposal
dom: for the network API, richt made a proposal for the network API
<Suresh> i mean we could adopt a similar style to most of the sys info properties
dom: laslo or suresh, do you want to take this on?
<dom> ACTION: Suresh to provide first draft of Network Connection API [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action01]
<trackbot> Created ACTION-357 - Provide first draft of Network Connection API [on Suresh Chitturi - due 2011-03-23].
suresh: will take on the network info API
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
<dom> Battery status
<dom> ACTION: Anssi to provide first editors draft of a Battery status API [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action02]
<trackbot> Created ACTION-358 - Provide first editors draft of a Battery status API [on Anssi Kostiainen - due 2011-03-23].
dom: next was the thermometer, we could put this on the back burner
darobin: ok to put more things on the back burner
<dom> ACTION-358: Web Performance WG was interested on battery status — probably need coordination
<trackbot> ACTION-358 Provide first editors draft of a Battery status API notes added
<Suresh> CPU is something device vendors like to keep it to themselves
<dom> CPU is candidate for backburnering
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
<AnssiK> https://developer.mozilla.org/en/DOM/window.navigator.oscpu
dom: for the sensors, we have the question of a generic sensor API. Anssi sent something about what is available in android
<AnssiK> https://developer.mozilla.org/en/DOM/window.navigator.platform
anssik: not me
bryan: I can take on the sensors, but need to know what the plan is for a generic API for this
dom: sysinfo as it exists could be a start
bryan: i can put things in documents but I am not necessarily the technical SME
<dom> ACTION: Bryan to split out a generic sensors API (based on ambientlight/proximity/etc) from sysinfo [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action03]
<trackbot> Created ACTION-359 - Split out a generic sensors API (based on ambientlight/proximity/etc) from sysinfo [on Bryan Sullivan - due 2011-03-23].
<AnssiK> navigator.platform and navigator.oscpu expose CPU-related information already today, works in Moz, Chrome, Saf at least
<AnssiK> what I'm not sure is if developers are using that information
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)
<Suresh> Anssi, but that is only the OS information not info such frequency, processor info, etc
dom: we could start with considering which are most useful
... suresh, are the static properties e.g. cameras microphones etc of interest
suresh: can take on those
<dom> ACTION: Suresh to see at possibilities of APIs for access to device characteristics [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action04]
<trackbot> Created ACTION-360 - See at possibilities of APIs for access to device characteristics [on Suresh Chitturi - due 2011-03-23].
<Suresh> I assume device characteristics are 'read-only'?
bryan: should we package the dynamic I/O APIs as a package?
dom: we should consider that for each feature we want to make available rather than in the abstract
<AnssiK> I heard Bryan or Suresh say something about screen related props, for existing ones, see: http://www.quirksmode.org/dom/w3c_cssom.html
<AnssiK> CSS OM exposes much information that is useful for developers, such as the dimensions of the viewport
<dom> ACTION: Bryan to provide use cases for device characteristics access [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action05]
<trackbot> Created ACTION-361 - Provide use cases for device characteristics access [on Bryan Sullivan - due 2011-03-23].
<Zakim> 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
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
dom: CSSOM addresses a number of important characteristics from the dsplay
bryan: would CSSOM provide a pattern for audio?
dom: no, mostly for display characteristics
... that covers a first plan for sysinfo
bryan: what about storage?
dom: proposed work in webapps might cover that
darobin: unsure whether it covers all of it
<dom> Quota API discussion in WebApps
dom: suggest not to work on this given overlap with the work in webapps e.g. with filesystem
<dom> dom: probably covers most of what would be useful for storage
bryan: conceptually this is in the same ballpark as filesystem operations, e.g. to see the size of a filesystem
kangchan: the use case is very helpful to understand the recommendation, 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.
<dom> ACTION: Kangchan to provide use cases for sysinfo-like features [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action06]
<trackbot> Created ACTION-362 - Provide use cases for sysinfo-like features [on Kangchan Lee - due 2011-03-23].
<Zakim> Suresh, you wanted to clarify the change in direction for Messaging
<darobin> Dom's Messaging proposal
suresh: missed last week's discussion, if the group has agreed to simplify this, what is it based upon?
<Suresh> We clearly say in the scope that the API complements the URI schemes, so this is not competing with URI schemes
dom: the discussion last week was based upon earlier discussion that this is related to what can be done with URI schemes
<dom> dom: the latest proposal I sent for messaging is feature-equivalent to the draft we have currently published as working draft
<Suresh> Super simplification would not allow us to extend in the future if we were to add folder management, search, etc.
<Suresh> 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
dom: re extensbility, we can consider more and more advanced 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.
<Suresh> we also talked about the need to separate the design for different messaging technology and ease of use...
dom: the previous proposal is not integrated well into the Web architecture
... the two existing proposals are mostly feature equivalent
<Suresh> This is the same analogy we have between using HTML Media Capture and Camera
bryan: the other use cases e.g. read/receive are not in the current API anyway, and can be considered for future work
<Suresh> the point i was making was can we have the two models co-exist, URI schemes and a detailed programtic style API
dom: implementers don't want to develop duplicate features
... the stream API is significantly different from HTML media capture
... even if we do consider a programmatic API eventually, that doesn't mean we need to start with it
<Suresh> From ease of use, developers would want to be able to set properties than creating a URL to populate them
dom: a start may be to update the current draft with the new proposal, and call for feedback before moving forward
... having an interface to build messages is a convenience function
darobin: libraries can do that
<Suresh> relying on libaries is not the same as having a standard API
<Suresh> implemented in the browser....
dom: there are good reasons on both sides, let's put the two proposals on the table
<dom> PROPOSED RESOLUTION: publish new messaging API as WD and ask for feedback (esp. from developers and implementors)
<darobin> +1
<Suresh> perhaps as you suggest we should have a call for implementations
<dom> RESOLUTION: publish new messaging API as WD and ask for feedback (esp. from developers and implementors)
<dom> ACTION: Dom to see with Maria on how to proceed for updated messaging api draft [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action07]
<trackbot> Created ACTION-363 - See with Maria on how to proceed for updated messaging api draft [on Dominique Hazaël-Massieux - due 2011-03-23].
<Suresh> just to summarize, we would present both the proposals and ask for feedback right>
<dom> indeed, suresh
<Suresh> thanks!
<dom> ??P2 is DAPWG
<Suresh> i will be here until noon session
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Mar/0012.html
anssik: the feature permissions spec is being produced by web notiifications group
<AnssiK> http://dev.w3.org/2006/webapi/WebNotifications/publish/FeaturePermissions.html
anssik: the deliverable is proposed to be moved to DAP
<lgombos> I reached John Gregg and touch based on the spec
<AnssiK> http://dev.w3.org/2009/dap/docs/feat-perms/feat-perms.html
anssik: I have done some investigation and as demo that implements this with a usable interface
<lgombos> John Gregg has no particular plan to advance the spec for the needs that the WebNotification group has
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
<AnssiK> http://dev.w3.org/2009/dap/docs/feat-perms/feat-perms.html#changes
anssik: some changes have been proposed to the DAP spec based upon the investigation
... 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.
<darobin> +10 on prototypes
dom: this is a good way to consider our motivation to do this work
... this could be useful for other specs outside DAP, e.g. geolocation, some APIs in webapps etc
<dom> http://dev.w3.org/2009/dap/features/
dom: if you can bring in the Feature Permissions spec and propose changes based upon the investigation, that would be a start
<lgombos> dom: I think we should merge the two
dom: a question is the relationship to the current API perms draft
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
dom: first we need to get an editors draft in DAP space integrate anssi's comments, and the APIs in scope, and then go to FPWD of Permissions 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.
logombos: will take on the spec merging task
<Suresh> Contacts/Calendar? but we may need Rich..
<AnssiK> I'm happy to help Laszlo with editing Feat Perms
<fjh> suresh expressed concern about chartering limiting to browser context rather than also allowing widgets
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
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
dom: the current charter references the browser context as the main reference point
<Suresh> thanks dom
darobin: everything that works in a browser should work in a widget, but the converse is not true
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
<Suresh> replacing the current statement with "APIs that can be demonstrated
<Suresh> without the need of a specialized policy framework will be released" is a good
<Suresh> alternative to indicate that the APIs will be demonstrated using the web
<Suresh> runtime only and not with the assumption of an underlying policy framewrok
<Suresh> which appeared to be the main concern from browser vendors
fjh: as rechartering we are increasing number of deliverables, and will have enough work delivering, might not be wise to add more
<darobin> "without the need of a specialised policy framework" doesn't really help — it needs to also be safe
<darobin> and if it's safe and works without policy — then it works in a browser
dom: what we have heard from browser vendors is that they object to working on things that don't work in the open web
suresh: we need to understand the "open web" and what works in different contexts more clearly
... I would rather that we stay silent or generic on the context
darobin: it is generic, we need APIs that are safe in an untrusted environment
dom: a main hypothesis is that if it works in the browser it should work in other contexts
<dom> 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?
dom: given the group's current progress, we should not expand the charter scope
suresh: do we expect tests to demonstrate ability to use the APIs in both browser and widget contexts?
... 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
dom: the concerns about usability and security are constraints on the design process, which needs to verify whether things are really usable and safe
suresh: how do we capture these objectives in the charter, and keep the door open to flexibility in API design?
dom: unless we can prove it works in a browser context, we should not work on it
... there are a number of criteria to consider, the best way to prove something works is to provide a prototype
... the intent of the charter scope is to limit meta discussions
... 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
suresh: the issue seemed to be more with the policy framework than widgets
... my proposal was to say e.g. if the API is designed to run without a policy framework, it passes the criteria
... is that something that can be in the success criteria?
bryan: could we rephrase this as "installable web applications" instead of widgets, to be more generic?
suresh: does the success criteria affect also the design of the API?
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 during CR
<Suresh> "However, this does not preclude the APIs to be demonstrated in Widgets or Installed environments"
suresh: we should have a statement re "the intent is not to preclude..."
darobin: the restrictions are focused around ensuring the APIs work in a Web context
dom: will add something to the charter based upon Suresh's proposals, e.g. referencing "not precluding support for installable web applications".
darobin: where is content security policy going?
<darobin> Content Security Policy
dom: this is a mozilla-led spec intended to limit XSS attack, enabling external website resources to be used safely
... 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
... this included CORS and UMP
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
dom: we could throw some ideas on the wiki to see what sticks
<darobin> ACTION: Robin to get the COW started [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action08]
<trackbot> Created ACTION-364 - Get the COW started [on Robin Berjon - due 2011-03-23].
<darobin> ACTION: Frederick to help raise the COW [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action09]
<trackbot> Created ACTION-365 - Help raise the COW [on Frederick Hirsch - due 2011-03-23].
bryan: this would include security approaches, right?
darobin: yes, trust and security
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
<dom> ACTION-298?
<trackbot> ACTION-298 -- Dominique Hazaël-Massieux to work with rich on test-enabling the contacts API -- due 2011-03-09 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/298
darobin: we need to test contacts soon
<fjh> close ACTION-348
<trackbot> ACTION-348 Send concrete proposal for navigator.sendMessage with URI scheme closed
bryan: what basis for framework and examples wll be used to start?
dom: we earlier agreed to use the Webapps javascript framework as used in the HTML tests, XHR, etc
<fjh> DAP wiki for testing , including framework -> http://www.w3.org/2009/dap/wiki/Testing
dom: one struggle will be defining a test environment e.g. due to dependency upon underlying data, which may require loading of fake data
<fjh> Dom is planning on testing related to contacts, so is Rich, plan to make call for contributions later
<AnssiK> I presented the QUnit-based approach to unit testing at the last f2f
<AnssiK> http://www.w3.org/2009/dap/wiki/Testing#Notes_on_testing_framework_used_by_Phonegap
fjh: what about HTML media capture?
<AnssiK> the group decided to align with the WebApps WG harness instead
dom: we are stuck
<AnssiK> so I have not made further progress on the unit testing front after that
darobin: the "role" attribute is intended for assistive technologies and not for other purposes - we need to find another approach
<AnssiK> I believe jgraham of Opera is the original author of the WebApps harness contributed to W3C
<AnssiK> but I'm not 100% sure, Opera participants probably know the best
<dom> ACTION: Dom to restart with HTML WG on getting new attribute for HTML Media Capture [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action10]
<trackbot> Created ACTION-366 - Restart with HTML WG on getting new attribute for HTML Media Capture [on Dominique Hazaël-Massieux - due 2011-03-23].
fjh: we need to update the draft and can then go to last call
darobin: better to put out a new WD first
... a draft will help get feedback from the HTML WG
<dom> ACTION: Dom to update HTML Media Capture with new attribute [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action11]
<trackbot> Created ACTION-367 - Update HTML Media Capture with new attribute [on Dominique Hazaël-Massieux - due 2011-03-23].
<dom> ACTION-366: todo after ACTION-367
<trackbot> ACTION-366 Restart with HTML WG on getting new attribute for HTML Media Capture notes added
<fjh> plan is to update HTML Media capture, then publish new WD, get feedback, then consider last call
<dom> http://www.w3.org/TR/test-methodology/
bryan: what are the steps in getting ready for tests?
darobin: there is a methodology
<dom> linked from http://www.w3.org/2009/dap/wiki/Testing
dom: the the best way is to identify test assertions and tests to cover them
fjh: the spec editors need to use the document markup conventions supporting the test assertions
dom: it's more important to just get started on creating tests, and then progress through an interative process
fjh: the test assertions and tests are essential to move spec further in the process...
<dom> Web Tracking and User Privacy Workshop, April 28-29
<dom> [we're breaking until 2pm local time]
<dom> AnssiK, we'll be using 26631 as a conf code; I'm not sure why the regular one doesn't work
<dom> ScribeNick: dom
-> http://dev.w3.org/2009/dap/contacts/ Contacts API Editors draft
Frederick: actually, let's start with Gallery
ACTION-314?
<trackbot> ACTION-314 -- Anssi Kostiainen to react on media gallery use cases -- due 2010-12-15 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/314
<fjh> http://dev.w3.org/2009/dap/gallery/
Anssi: should look at use cases before deciding to work on it
... also need to check how much priority this should get
<darobin> François
Anssi: we got some useful list of use cases from francois
... could look at prototyping
... there has been little progress under the current charter
... at the last F2F we quickly hacked together some quick design to replice the BONDI replica
... I'm trying to find out if that's on the critical path
... does the the group feel that the deliverable has decent use cases and there is demand from developers
... before investing time in a new draft
... coming up with good design and prototype will require some of my time that would be taken away from other deliverables work
... it's still largely unproven
<darobin> we're still switching to someone else
<darobin> rejoin!
<darobin> AnssiK: what is the kind of consensus around the priority for that API?
<darobin> ... I don't think that it has a proven track record
<darobin> ... not sure if the BONDI version materialised at all
<dom_> ScribeNick: dom_
<darobin> back
<darobin> we're redialing
<darobin> ... not clear that there's much prior art in this
<Zakim> fjh, you wanted to ask about how much to to be done
Frederick: how much work do you think this requires?
Anssi: the requirements from the use cases would require quite a number of features
... would probably start with something small
... I'm struggling to find what would be low-hanging fruit
... I welcome ideas around that
... we could simply conclude that we don't have currently enough interest
... whereas if it's clear that we have RoI, then I'm happy to do that
... I could do a small thing as a trigger for discussions
<fjh> +1 to low cost evaluation of where to begin
Anssi: we could probably take a file-picker approach for low-hanging — but not clear this brings any additional value over existing APIs
<darobin> +1 to code and small things
Dom: I would suggest doing some very rough, maybe a number of code examples of what the API would like
... and then bring it to the Web & TV IG to get feedback on usefulness/importance
... for instance, being able to search through your recorded collection of movies on your TV set-top box from your smartphone
<wonsuk> web and TV paper related with gallery API: http://www.w3.org/2010/11/web-and-tv/papers/webtv2_submission_6.pdf
Dom: could also look at position paper I noted to the mailing list which mentioned the need for a gallery API
Wonsuk: we need to make clear use cases for Gallery API
... we got use cases from Dom and Francois
... we also got one from Web & TV workshop
... we should enhance the use cases in the Gallery API doc
... might need also input to file systems API
<scribe> ACTION: Wonsuk to collect and summarize current use cases for Gallery API and includes a draft doc [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action12]
<trackbot> Created ACTION-368 - Collect and summarize current use cases for Gallery API and includes a draft doc [on WonSuk Lee - due 2011-03-23].
Wonsuk: there are lots of related specs: HTML Media Capture, Media Annotations, Media Ontology, FileSystems API
... this will require significant coordination
Dom: think writing code samples is best way to approach that complexity
-> http://lists.w3.org/Archives/Public/public-device-apis/2011Mar/att-0037/minutes-2011-03-09.html#item08 Discussion during last teleconf on Contacts API
Dom: only remaining thing is removing search filters, and then we can make a call for consensus for Last Call
Frederick: ok, so not much to discuss then
<fjh> http://dev.w3.org/2009/dap/calendar/
<darobin> navigator.service.calendar.EVENT_TYPE
Robin: could we go move forward with FPWD for Calendar?
<AnssiK> http://lists.w3.org/Archives/Public/public-contacts-coord/2011JanMar/0001.html
Dom: we have a dependency on TZDate
Robin: doesn't seem to be a blocker for FPWD
... there has been an update to vCard 4
... don't think the last changes have an effect on Contacts, but could check
... I think Richard looked
... vCard4 is a superset of vCard3
Anssi: vCard2 and 3 were not explicit about the timezone format
... I sent a message to the list with a report on the differences
<AnssiK> http://lists.w3.org/Archives/Public/public-device-apis/2011Jan/0087.html
Anssi: Olsson database is the recommended way, but many implementations only use utcOffset
Dom: This matches what's currently in the API
Robin: would be good to go to FPWD
Frederick: +1
Robin: would need maybe a quick review to remove most important bugs
<Zakim> fjh, you wanted to ask about publishing updated WD of calendar
Dom: should do a call for consensus
<fjh> +1
Dom: would like to make sure that the issue re TZDate is clearly documented in the draft, to avoid worrying people
... likewise for the recurrence model limitations
Robin: will send CfC then
Dom: I'll add the note on the issues in the draft
<dom> ScribeNick: dom
<fjh> http://www.w3.org/2009/dap/
-> http://www.w3.org/2009/dap/#roadmap DAP Roadmap
Frederick: we will not be meeting on Friday since we have already gone through the agenda and people have started to depart early
... regarding our roadmap, the rechartering doesn't prevent us from continuing our existing work, right?
dom: right
Frederick: let's look at our roadmap then
... we've determined a path for contacts
... likewise for Calendar, we've just sent a CfC for FPWD
Robin: if contacts goes to last call, we can hope to go to LC with Calendar soon (maybe June?)
Frederick: what about HTML Media Capture?
Robin: we're planning to publish an updated draft with a new attribute
... and depending on feedback, we might be able to go to LC soon
<AnssiK> Any feedback from Google? "As defined by the HTML Media Capture specification, the Browser allows web applications to access audio, image and video capture capabilities of the device." http://developer.android.com/sdk/android-3.0.html
<fjh> contacts - we have remaining edit from Rich, then CfC to go to Last Call in April
<fjh> calendar - CfC in place for publishing FPWD
<fjh> in April
PROPOSED RESOLUTION: we will publish a new updated HTML Media Capture once new attribute is done
<fjh> HTML Media Capture, outstanding edit from Dom then publish updated WD
Robin: you'll need to add an API for the new attribute based on WebIDL
... might use white-space separated tokens
RESOLUTION: we will publish a new updated HTML Media Capture once new attribute is done
<fjh> Media Capture API - looking for feedback on interest in it
close ACTION-351
<trackbot> ACTION-351 Draft HTML Media Capture with role attribute closed
<AnssiK> Microsoft's feedback
<scribe> ACTION: Robin to talk with Microsoft re Capture API future [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action13]
<trackbot> Created ACTION-369 - Talk with Microsoft re Capture API future [on Robin Berjon - due 2011-03-23].
Frederick: I think we're wondering about keeping it at all, vs upgrading it with stream support
Robin: I would qualify it as "future under discussion", decision expected sometimes in April
Frederick: Messaging will be updated with the new approach
Dom: and if no negative feedback, we can hope to go to last call in June
... re sysinfo, lots of work to take into account the new split
... I guess the plans for last call are probably less clear
Robin: some might be relatively straightforward
Dom: indeed, maybe Network could go quickly to LC
<fjh> Messaging - also updated WD in April
Frederick: Permissions API will get a FPWD
Dom: open question on merging the permissions API with the permissions strings
Robin: I'd rather keep them separate but don't mind strongly
Anssi: we could probably go fast unless we need coordination with Web Notif
Dom: don't think we need to coordinate
Frederick: so we can plan for a FPWD in April
Anssi: first step will be to put draft into ReSpec format
... and then bring in my changes
... I can do start and then pass it to Lazlo for review
Frederick: [bashing ReSpec]
<fjh> s/bashing/expressing admiration for/
Anssi: regarding merging with features ids or not
... I think they're independent
<fjh> we should ReSpec for our drafts to pick up common formatting, bibliography etc
Dom: thinking about it, I think they need to be kept independent since features ids are also useful for widgets feature
... we should publish an updated draft referring to the API once we go with FPWD
Anssi: wondering where the feature strings should go
... ideally, I think they should come with the API spec themselves
... but that's probably a minor issue
... I'm thinking the feature string could be a serialization of the entry of the APIs e.g. navigator.geolocation
Dom: I don't think that would work for all cases, e;g. when no direct entry point but from DOM element
... so I think arbitraty strings are probably our best option
Anssi: true
Frederick: for Gallery?
Dom: plan is to come up with code samples, formalized use cases
Robin: not ready to publish as is
Dom: re Device Interface?
<fjh> will wait with Gallery until clarity on requirements and draft
Robin: can have a draft next month
Dom: but do we still actually need it?
Robin: Contacts API doesn't use it anymore
Dom: now that we mention it, Contacts doesn't do HTML5 Event loop correctly, does?
Robin: doesn't look like it
ACTION-271?
<trackbot> ACTION-271 -- Robin Berjon to figure out the event loop stuff for sysinfo -- due 2010-09-22 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/271
ISSUE: Contacts API needs to integrate HTML Event Loop
<trackbot> Created ISSUE-110 - Contacts API needs to integrate HTML Event Loop ; please complete additional details at http://www.w3.org/2009/dap/track/issues/110/edit .
Dom: so that's a showstopper for moving to LC
Robin: I hope the work in Web Apps for this for file API can serve as inspiration
... I'm not entirely sure if that's entirely needed
ACTION-271 due 2011-03-23
<trackbot> ACTION-271 Figure out the event loop stuff for contacts due date now 2011-03-23
Dom: moving back to Device Interface, should we drop it then?
<fjh> Not going further with Device interface
Robin: if nobody using it, sure
<fjh> Application Launcher, http://dev.w3.org/2009/dap/app-launcher/
Dom: re Application Launcher, we've talked about using Web Intents
... but we don't have a plan for it
Robin: I don't think anybody has volunteered for that
Dom: we could make a call for editors
<darobin> ACTION: Robin to talk to Mozilla/Paul about Web Intents [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action14]
<trackbot> Created ACTION-370 - Talk to Mozilla/Paul about Web Intents [on Robin Berjon - due 2011-03-23].
Kangchan: the proposed approach of Web Intent is quite different from the current API
... I've started discussing with Bryan and Paul to reconcile the views on this
Dom: what about Web Introducer? Should it be added to the roadmap
... ?
<darobin> ACTION: Robin to talk to Claes about how to make Web Introducer happen in the WG [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action15]
<trackbot> Created ACTION-371 - Talk to Claes about how to make Web Introducer happen in the WG [on Robin Berjon - due 2011-03-23].
Robin: I think that would make sense
... we need to see if they're still interested in doing work on this as part of the group
ACTION-353?
<trackbot> ACTION-353 -- Dominique Hazaël-Massieux to check with Claes re Web introducer contributors and bringing it to DAP -- due 2011-03-22 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/353
<fjh> it would be best to have active participation of those who created the draft in the DAP WG
close ACTION-353
<trackbot> ACTION-353 Check with Claes re Web introducer contributors and bringing it to DAP closed
ACTION-353: overtaken by ACTION-371
<trackbot> ACTION-353 Check with Claes re Web introducer contributors and bringing it to DAP notes added
Dom: next is Tasks
... it has been suggested it could be a simple addition to the Calendar API
Frederick: would qualify as unscheduled work for now
Dom: will add relationship to Calendar in roadmap too
... probably worth taking up with the Calendar editors to see if they want to fold it in
<fjh> might make sense to include tasks with calendar since tasks are time based events
How does tasks relate to Process management?
Dom: different topic, but we could consider process management as part of new charter
Robin: please send use cases and potential input to the list if you want to include it in consideration for new charter
Dom: nothing has been done on User Interaction
... we want to do vibration, beep and menus per our new charter
... Opera has said they have proposals in this space
Robin: for menus and vibration
<scribe> ACTION: Dom to talk with Opera on contributions for User Interactions deliverable [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action16]
<trackbot> Created ACTION-372 - Talk with Opera on contributions for User Interactions deliverable [on Dominique Hazaël-Massieux - due 2011-03-23].
Dom: Communication Log to be dropped
... likewise for Policy Framework
Frederick: we should keep ref to them in a history section somewhere
Dom: re APIs requirements, can hope to update for May
ACTION-281 due 2011-05-10
<trackbot> ACTION-281 Take a stab at updating the API Requirements documents due date now 2011-05-10
Dom: policy-reqs is probably done
Robin: should we end of life it?
Frederick: we might want to update it at some point
Dom: we could publish it as a note to mark it as done
<scribe> ACTION: Frederick to prepare policy-reqs as WG Note [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action17]
<trackbot> Created ACTION-373 - Prepare policy-reqs as WG Note [on Frederick Hirsch - due 2011-03-23].
Dom: what about privacy-reqs?
Frederick: it's an important doc
Dom: how are we intending to make progress on privacy-reqs
... ?
Frederick: workshops are a way to get input
Dom: I think we are less likely to make progress if we don't have a plan, but don't mind keeping it as is
Frederick: re Rulesets
... I think we should publish it as FPWD, despite its issues
Robin: reading the document, it's not clear what it is supposed to do
Dom: it doesn't tell how the rulesets are bound to data
<fjh> so your concern is the lack of clarify of how this would integrate in the API architecture
Robin: I still think there is no point in using Rulesets in the same way as Geopriv
... attaching information to an API is something that no-one wants to do
Dom: we had interesting discussions in a previous F2F about using rulesets only in some cases (e.g. with Web site with which you have no pre-exisitng relationship)
... there were quite a few ideas
<fjh> possible need to capture ideas in rulesets proposal for this and other ideas
Dom: but they need to be captured as text and discussed if we want to make progress
<scribe> ACTION: Frederick to complete Privacy Rulesets with binding considerations [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action18]
<trackbot> Created ACTION-374 - Complete Privacy Rulesets with binding considerations [on Frederick Hirsch - due 2011-03-23].
Dom: last one is API Design Patterns, can be removed
<scribe> ACTION: Dom to add API Checklist to home page [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action19]
<trackbot> Created ACTION-375 - Add API Checklist to home page [on Dominique Hazaël-Massieux - due 2011-03-23].
Dom: I think documenting our experience could be useful
... could help make the Web a better place
... I wouldnt' phrase it as "you should do this or that", but rather here what've faced and learned
<fjh> Thank you to our hosts and Kangchan
<fjh> Next F2F is in July in France, please complete questionnaire http://www.w3.org/2002/09/wbs/43696/juljun-f2f/
<fjh> for information on upcoming meetings and minutes see http://www.w3.org/2009/dap/minutes