See also: IRC log
<trackbot> Date: 21 July 2011
<fjh> trackbot, start telecon
<trackbot> Meeting: Device APIs and Policy Working Group Teleconference
<trackbot> Date: 21 July 2011
<robin> http://www.w3.org/2011/07/DeviceAPICharter
<fjh> ScribeNick: ingmar
<fjh> discussion of what should be exposed to application and what should not, with example of reading audio volume
<Josh_Soref> I don't think that the Application needs to know anything about Audio Levels
<Josh_Soref> If it wants to show or have the option of showing Captions, it should just do so
<bryan> Anything that is typical of user behavior, e.g. turning off data usage when roaming, does not need to be an API.
<Josh_Soref> [charter-item] An API to read the current audio volume level of a device
fjh: I hear consensus that the volume read API might be another charter item which we will not work on
<robin> http://w3c-test.org/dap/proposals/request-feature/
fjh: introducer is on our list of things to do
... regarding privacy there are different rules in US/Canada and the EU, we might need to look at this
<discussion about the charter and if we need to work on all deliverables>
robin: the charter defines the bounderies for the IPRs, it does not oblige to work on a specific deliverable
<fjh> Gallery, http://dev.w3.org/2009/dap/gallery/
wonsuk: had an action item to review the gallery API
... need to do elaborate on use cases and requirements
... will provide input for the use cases and requirements section until end of August
robin: it will be interesting to look at Gallery API on how it could work with the HTTP approach
<fjh> ACTION-216?
<trackbot> ACTION-216 -- WonSuk Lee to reformulate gallery API to look like contacts API -- due 2010-07-21 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/216
<fjh> ACTION-368?
<trackbot> ACTION-368 -- WonSuk Lee to collect and summarize current use cases for Gallery API and includes a draft doc -- due 2011-03-23 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/368
<fjh> 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> aCTION-216 closed
<trackbot> ACTION-216 Reformulate gallery API to look like contacts API closed
wonsuk: will work on ACTION-368 until end of August
<fjh> ACTION-216: first need to review use cases and requirements, see ACTION-368, then decide on next steps
<trackbot> ACTION-216 Reformulate gallery API to look like contacts API notes added
fjh: there was a decision at the last TPAC to kill AppLauncher, we should remove it from the DAP page
<fjh> http://dev.w3.org/2009/dap/privacy-rulesets/
robin: we received feedback that some of the APIs we designed might be candidates for HTTP based APIs.
... we discussed this at least a year ago and didn't reach consensus on a generic approach
Josh_Soref: it should be relatively straight forward to do a limited binding for HTTP
<robin> http://www.w3.org/TR/WebIDL/
bryan: we should have a short discussion on the rationale
<robin> http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0061.html
<bryan> Also http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0083.html
<lgombos_> also related - https://lists.webkit.org/pipermail/webkit-dev/2011-July/017621.html
robin: if we would not define an API we would exclude a lot of services (as the browser would only have integration of the local contacts and probably a small list of HTTP based data sources)
bryan: points out that JS libraries could be used to access different HTTP based data sources
Josh_Soref: accessing the datasources using JS has security implications
bryan: we started to develop an API for local data sources such as contacts and now discussing a generic API for network based data sources. This is a change in scope.
<fjh> two models - direct access to local or web based providers, vs all access mediated by local that then syncs with others as needed
<discussion on what you could do with JS vs. what should be implemented in the browser>
bryan: makes the point that we started to do simple things for local services, we should keep things simple and not make it more complex by involving network based services
Josh_Soref: a network based API could be valuable if the browsers use e.g. network based access to the local contact database, i.e. the local database would be handled in the same way as a network based data source
robin: will start to write a first WebIDL mapping and Josh will help and review
fjh: what does it mean for the contacts spec? Do we need to change something?
Josh_Soref: we might need to add some fields
<fjh> discussion - if we move away from javascript + idl approach then idl would only serve as developer documentation, code directly written to access web info, no tool for pre-processing?
<fjh> this suggests that this approach would require something like web introducer to achieve complete api, including security etc?
<fjh> discussion as to whether this is actually simpler for developer
<fjh> I am concerned that we are making many assumptions in this assumption about what the browser/ua will do yet if that is not specified it may not occur.
<fjh> This could be an issue for privacy, user consent etc
<fjh> How can we require implementation of both web introducer and a contacts spec in combination - a conformance requirement document?
Josh_Soref: want the UA to allow the user to synthesize a contact instead of only taking it from existing data sources
robin: synthesizing contacts is an implementation detail
<Josh_Soref> [ I provided the example of me going to a street fair and being asked to drop in a card into a Bowl for a contest ]
<Josh_Soref> [ I could take my own business card from my wallet, or some other card I collected, or I could write down some items onto a piece of paper and drop that in. ]
<fjh> interface changes and performance concerns?
<Josh_Soref> [ I could even write out some items from an existing card, or cross items out from a card ]
<fjh> synthesized contact = returning portion of information from contact, effectively creating a virtual contact
<fjh> robin - performance issue could be naive implementation, using HTTP locally with overhead etc.
<fjh> ISSUE: how would feature discovery work for REST APIs
<trackbot> Created ISSUE-118 - How would feature discovery work for REST APIs ; please complete additional details at http://www.w3.org/2009/dap/track/issues/118/edit .
<bryan> For a URL-based approach, browser processing (e.g. what is returned in XHR response) would need to be clearly defined
<bryan> How a URL-based approach (which would appear to be directly usable by developers) would work with existing auth scheme such as OAuth would need to be addressed in the spec.
<Zakim> Josh_Soref, you wanted to respond to fjh to explain that the http approach means less work for Browser vendors which increases likelyhood of them implementing
fjh: the HTTP approach would add more complexity on the definition of the API
<bryan> With a URL-based approach, it would be more likely that developers would make errors in creating the URLs - this is the same issue as using MIME type attributes to define video capture API options.
<bryan> We would have to use caution to avoid duplicating similar RESTful API work, e.g. the OMA/OneAPI APIs.
<robin> https://github.com/andreasgal/dom.js/blob/master/tools/idl2domjs -> idl2js
<lgombos_> bryan - can you drop in a link for OneAPI (for contacts)
fjh: the discussion would benefit from an example, we need to think about security, privacy, discovery
<fjh> in walking through the example
<Zakim> ernesto_jimenez, you wanted to ask josh for clarification on the HTTP approach he has in mind
<bryan> Overall there seems to be little difference in the expected implementation cost.
<bryan> Do we expect other groups to move in this direction as well, e.g. why doesn't the File API use the URL approach? What about IndexedDB etc?
<fjh> good question - how is a remote database handled?
<bryan> Do we expect a general move away from both markup and Javascript APIs? Why do we need the <audio> tag when we can have an audio:// URL to invoke the same API?
<fjh> general question is one of uniformity of approach across webapps, dap, HTML5 etc
<bryan> Link to OneAPI: https://oneapi.aepona.com/authsec/portal/tws_gsma/Resources/Library
<ernesto_jimenez> I asked about the implications of using an HTTP API vs a Javascript API. Robin pointed out that using a restful approach doesn't require browser code necessarily. I pointed out that HTTP access to contacts we can do already and we would just be standardising the HTTP interface from the server side, if we want browser UI, device contacts, etc. you need to write code in the browser no matter if the API is JavaScript or HTTP
Josh_Soref: the reason why there is a audio element is that the object element was a disaster
<fjh> I suggest issues of uniformity can be handled by TAG, also architecture approach
<robin> ACTION: Frederick to raise the HTTP vs JS architectural issue with the TAG [recorded in http://www.w3.org/2011/07/21-dap-minutes.html#action01]
<trackbot> Created ACTION-441 - Raise the HTTP vs JS architectural issue with the TAG [on Frederick Hirsch - due 2011-07-28].
<bryan> Between the (at least) three approaches to defining APIs (declarative, procedural, RESTful), which one is used needs to be based upon rationales that are commonly understood (e.g. communicated by TAG) and used by the W3C groups in consistent ways to guide their API development.
<fjh> short term plan - review example of REST API for contacts review and look for issues
<robin> ACTION: Robin to produce a REST binding example for Contacts (client, server, protocol) [recorded in http://www.w3.org/2011/07/21-dap-minutes.html#action02]
<trackbot> Created ACTION-442 - Produce a REST binding example for Contacts (client, server, protocol) [on Robin Berjon - due 2011-07-28].
robin: we need to ask the TAG about some general issues, for the short term we can work on the HTTP binding for contacts
... we don't know at the moment on how to select the URL, the assumption for the moment is that the URL available
<fjh> laszlo - have specific fixed URL or variable/pluggable URL
<fjh> robin also notes this is where web introducer
bryan: does our work towards a REST binding mean that we move away from a JS binding?
robin: if we find that the REST approach is a good way to go we will follow this, but anybody could also do a JS or even a Java binding
<fjh> summary - what I suggested before that JS API is easier for developer, HTTP API offers other benefits
bryan: I understand that the group shifts focus to REST, but I would prefer to have multiple bindings including JS
fjh: we need to wait to have some more concrete examples to better understand the issues and decide on how to move on
<Josh_Soref> ScribeNick: Josh_Soref
<scribe> Scribe: Josh_Soref
<fjh> http://www.w3.org/2009/dap/track/issues/open
<fjh> ISSUE-81?
<trackbot> ISSUE-81 -- How to represent dates? ES has Date but with no TZ information; using strings is less than ideal; do we have to create a Web Dates specification? -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/81
fjh: that affects calendar
... so we can wait
ISSUE-87?
<trackbot> ISSUE-87 -- Degree of ruleset transmission with API calls, how often, which -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/87
ISSUE-88?
<trackbot> ISSUE-88 -- User interaction for ruleset confirmation when multiple APIs are used to provide functionality, usability etc -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/88
ISSUE-89?
<trackbot> ISSUE-89 -- Clarify how rulesets interact with pre-existing relationships -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/89
fjh: I have an action, I'm going to look at them
ISSUE-92?
<trackbot> ISSUE-92 -- Sysinfo, permissions for get vs monitor; -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/92
ISSUE-96?
<trackbot> ISSUE-96 -- Some properties of sysinfo are static so monitor might not make sense -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/96
fjh: given where we're going with sysinfo, i'm not sure what we're doing with their issues
... ISSUE-92, I'll follow up offline
... ISSUE-96 was Dom saying this would be moot if we reshape it
... So we're going to split things up into things like sensors
robin_: yeah, we can close 92 and 96
ISSUE-92 CLOSED
<trackbot> ISSUE-92 Sysinfo, permissions for get vs monitor; closed
ISSUE-96 CLOSED
<trackbot> ISSUE-96 Some properties of sysinfo are static so monitor might not make sense closed
<fjh> ISSUE-92: revisit when working on new specs dealing with this material
<trackbot> ISSUE-92 Sysinfo, permissions for get vs monitor; notes added
<fjh> ISSUE-96: revisit when working on new specs dealing with this material
<trackbot> ISSUE-96 Some properties of sysinfo are static so monitor might not make sense notes added
<fjh> ISSUE-95?
<trackbot> ISSUE-95 -- Different regulatory environments and relationship to privacy and rulesets -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/95
<fjh> ACTION: fjh to review various ruleset issues and follow up [recorded in http://www.w3.org/2011/07/21-dap-minutes.html#action03]
<trackbot> Created ACTION-443 - Review various ruleset issues and follow up [on Frederick Hirsch - due 2011-07-28].
ISSUE-105?
<trackbot> ISSUE-105 -- Should the capture hint in HTML Media Capture be specified through a MIME parameter? -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/105
fjh: We'll leave this open on Dom, but it might be moot
ISSUE-107?
<trackbot> ISSUE-107 -- How to better integrate URIs schemes in Messaging API -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/107
robin: I think this one can be closed
CLOSE ISSUE-107
<trackbot> ISSUE-107 How to better integrate URIs schemes in Messaging API closed
<fjh> ISSUE-107: done
<trackbot> ISSUE-107 How to better integrate URIs schemes in Messaging API notes added
<fjh> ISSUE-113?
<trackbot> ISSUE-113 -- AddEventListener in Battery Status has side effects -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/113
<robin> we need to process http://www.w3.org/2009/dap/track/issues/raised as well
<bryan_> Replacing the OneAPI link I provided earlier, this one does not require a OneAPI developer account: https://oneapi.aepona.com/sec/portal/tws_gsma/Resources/Library
<fjh> ISSUE-108?
<trackbot> ISSUE-108 -- Should Contacts API have MUST instead of SHOULD for extended attributes, is this a general issue for all specs? -- raised
<trackbot> http://www.w3.org/2009/dap/track/issues/108
robin: oh, I now understand what it is
<robin> http://dev.w3.org/2009/dap/contacts/#extended-contact-properties-and-parameters
robin: we have a SHOULD for extensions having a vendor prefix
<fjh> "Non-standard, private properties and parameters should have a prefixed name starting with X (U+0058 LATIN CAPITAL LETTER X) or use a vendor-specific prefix. Extended properties and parameters can be defined bilaterally between user agents without outside registration or standardization. "
robin: MUST would mean we'd need to be able to test it
Josh_Soref: we can actually test it by iterating over the object has own properties
... skipping properties we define.
... and skipping properties which have a prefix.
fjh: so let's make it a MUST ?
robin: I'm opening the spec so we can edit it
RESOLUTION: We will change the SHOULD to a MUST in the second paragraph of section 6
<fjh> ISSUE-108: resolved by changing SHOULD to MUST in section 6
<trackbot> ISSUE-108 Should Contacts API have MUST instead of SHOULD for extended contact properties, is this a general issue for all specs? notes added
<fjh> ISSUE-108 closed
<trackbot> ISSUE-108 Should Contacts API have MUST instead of SHOULD for extended contact properties, is this a general issue for all specs? closed
<fjh> ISSUE-109?
<trackbot> ISSUE-109 -- We need solid use cases for Feat Perms if it's going to fly -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/109
robin: it's unclear that implementers want to do this
... there's been pushback from mozilla
<fjh> ISSUE-109: closed
<trackbot> ISSUE-109 We need solid use cases for Feat Perms if it's going to fly notes added
fjh: so... doing this should be based on what is right
robin: it would be good to have introductory use cases as we have for other specs
fjh: we have an action item for that
<fjh> ISSUE-109: will need new section on use cases and requirements, being added to all docs
<trackbot> ISSUE-109 We need solid use cases for Feat Perms if it's going to fly notes added
ISSUE-113?
<trackbot> ISSUE-113 -- AddEventListener in Battery Status has side effects -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/113
ISSUE-114?
<trackbot> ISSUE-114 -- Battery spec should note relative ordering of battery low versus battery critical in terms of criticality -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/114
<fjh> http://www.w3.org/2009/dap/track/actions/open
<fjh> ACTION-148?
<trackbot> ACTION-148 -- Bryan Sullivan to compare user interaction input with what already available in HTML5 / WebApps -- due 2010-03-25 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/148
ACTION-148?
<trackbot> ACTION-148 -- Bryan Sullivan to compare user interaction input with what already available in HTML5 / WebApps -- due 2010-03-25 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/148
CLOSE ACTION-148
<trackbot> ACTION-148 Compare user interaction input with what already available in HTML5 / WebApps closed
robin: we covered this by adjusting the charter for the new charter
<fjh> ACTION-148: covered in rechartering
<trackbot> ACTION-148 Compare user interaction input with what already available in HTML5 / WebApps notes added
ACTION-229?
<trackbot> ACTION-229 -- Richard Tibbett to go through http://tools.ietf.org/html/rfc5546 and ensure the bindings provided map -- due 2010-10-22 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/229
CLOSE ACTION-229
<trackbot> ACTION-229 Go through http://tools.ietf.org/html/rfc5546 and ensure the bindings provided map closed
robin: we can close because richt looked at it and made changes
ACTION-230?
<trackbot> ACTION-230 -- Wojciech Maslowski to specify "add to calendar" based on ICS-objects opening -- due 2010-08-05 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/230
robin: that was from a writable-calendar
CLOSE ACTION-230
<robin> issue-78?
<trackbot> ACTION-230 Specify "add to calendar" based on ICS-objects opening closed
<trackbot> ISSUE-78 -- Capture has a minimisation problem with EXIF data (e.g. it could be Geotagged) -- closed
<trackbot> http://www.w3.org/2009/dap/track/issues/78
<fjh> ACTION-230: for writable calendar, group shifted to readable
<trackbot> ACTION-230 Specify "add to calendar" based on ICS-objects opening notes added
ACTION-251?
<trackbot> ACTION-251 -- John Morris to review privacy text related to ISSUE-78 for capture -- due 2010-10-20 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/251
CLOSE ACTION-251
<trackbot> ACTION-251 Review privacy text related to ISSUE-78 for capture closed
ACTION-257?
<trackbot> ACTION-257 -- Richard Tibbett to define what goes on for concurrent calls to find() when there is no error callback (and step three also needs to define that); then report to group so we can do the same to SysInfo get -- due 2010-09-29 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/257
CLOSE ACTION-257
<trackbot> ACTION-257 Define what goes on for concurrent calls to find() when there is no error callback (and step three also needs to define that); then report to group so we can do the same to SysInfo get closed
ACTION-281?
<trackbot> ACTION-281 -- Dominique Hazaël-Massieux to take a stab at updating the API Requirements documents -- due 2011-05-10 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/281
CLOSE ACTION-281
<trackbot> ACTION-281 Take a stab at updating the API Requirements documents closed
robin: we've dropped that document in favor of events
ACTION-297?
<trackbot> ACTION-297 -- Robin Berjon to draft up TZDate -- due 2010-11-11 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/297
<fjh> ACTION-257: addressed in document
<trackbot> ACTION-257 Define what goes on for concurrent calls to find() when there is no error callback (and step three also needs to define that); then report to group so we can do the same to SysInfo get notes added
robin: still open...
ACTION-300?
<trackbot> ACTION-300 -- Claes Nilsson to start working on use cases and requirements for video/audio conference à la <device> element -- due 2010-11-12 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/300
CLOSE ACTION-300
<trackbot> ACTION-300 Start working on use cases and requirements for video/audio conference à la <device> element closed
robin: this is now in the RTC WG
ACTION-307?
<trackbot> ACTION-307 -- Richard Tibbett to send email to list with resolutions for open issues against contacts, clarifying status -- due 2010-11-24 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/307
<fjh> ACTION-300: in RTC WG
<trackbot> ACTION-300 Start working on use cases and requirements for video/audio conference à la <device> element notes added
CLOSE ACTION-307
<trackbot> ACTION-307 Send email to list with resolutions for open issues against contacts, clarifying status closed
robin: because it was done
... email to the list sent
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
CLOSE ACTION-314
<trackbot> ACTION-314 React on media gallery use cases closed
ACTION-315?
<trackbot> ACTION-315 -- Dominique Hazaël-Massieux to look into pop-up windows in Permissions draft -- due 2011-05-11 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/315
ACTION-320?
<trackbot> ACTION-320 -- Richard Tibbett to make Calendar like Contacts in every possible way -- due 2010-12-22 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/320
CLOSE ACTION-320
<trackbot> ACTION-320 Make Calendar like Contacts in every possible way closed
robin: that's done...
<fjh> ACTION-320: implemented
<trackbot> ACTION-320 Make Calendar like Contacts in every possible way notes added
ACTION-329?
<trackbot> ACTION-329 -- Robin Berjon to maintain coordination with HTML+Speech on http://lists.w3.org/Archives/Public/public-device-apis/2011Jan/0057.html; include Claes in the discussion -- due 2011-01-26 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/329
robin: that's a continuous action
... not sure what to do with it
... we're on the calls
CLOSE ACTION-329
<trackbot> ACTION-329 Maintain coordination with HTML+Speech on http://lists.w3.org/Archives/Public/public-device-apis/2011Jan/0057.html; include Claes in the discussion closed
robin: it's the "hypertext coordination group"
<robin> http://www.w3.org/MarkUp/CoordGroup/
<fjh> ACTION-329: Hypertext Coordination Group, http://www.w3.org/MarkUp/CoordGroup/
<trackbot> ACTION-329 Maintain coordination with HTML+Speech on http://lists.w3.org/Archives/Public/public-device-apis/2011Jan/0057.html; include Claes in the discussion notes added
ACTION-330?
<trackbot> ACTION-330 -- John Morris to review SysInfo privacy considerations section, and ISSUE-64 on "generic" -- due 2011-01-26 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/330
CLOSE ACTION-330
<trackbot> ACTION-330 Review SysInfo privacy considerations section, and ISSUE-64 on "generic" closed
<fjh> ACTION-330: restructuring sysinfo
<trackbot> ACTION-330 Review SysInfo privacy considerations section, and ISSUE-64 on "generic" notes added
fjh: closing because it's sysinfo which is being split
robin: plus it relates to a closed issue
ACTION-338?
<trackbot> ACTION-338 -- Laszlo Gombos to look into multiple permission/installable designs for APIs -- due 2011-02-23 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/338
ACTION-339?
<trackbot> ACTION-339 -- Laszlo Gombos to go through existing DAP APIs to see if there are use cases there for Feat Perms (or if the existing approaches work better) -- due 2011-02-23 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/339
CLOSE ACTION-338
<trackbot> ACTION-338 Look into multiple permission/installable designs for APIs closed
CLOSE ACTION-339
<trackbot> ACTION-339 Go through existing DAP APIs to see if there are use cases there for Feat Perms (or if the existing approaches work better) closed
robin: ACTION-338 is heavily related to policy
lgombos_: ansi had some related work
robin: ACTION-339 is obsoleted by a new ACTION-XXX
lgombos_: we said that each spec needs to say things about feature-permissions
ACTION-340?
<trackbot> ACTION-340 -- Frederick Hirsch to look at how we're doing privacy by design -- due 2011-02-23 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/340
ACTION-345?
<trackbot> ACTION-345 -- Laszlo Gombos to look at Microsoft feedback on Capture API -- due 2011-03-16 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/345
robin: the feedback was sent by Microsoft to the HTML Speech people
fjh: we'll keep this open
ACTION-359?
<trackbot> ACTION-359 -- Bryan Sullivan to split out a generic sensors API (based on ambientlight/proximity/etc) from sysinfo -- due 2011-03-23 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/359
robin: bryan, you have an action item to write up the API
bryan_: I was hoping to do this
... I was hoping to have a submission
ACTION-360?
<trackbot> ACTION-360 -- Suresh Chitturi to see at possibilities of APIs for access to device characteristics -- due 2011-03-23 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/360
fjh: we have suresh looking for things
Josh_Soref: I think suresh is now me...
<robin> ACTION: Josh to investigate ACTION-360 with Suresh to figure out if it can be closed or should be reassigned [recorded in http://www.w3.org/2011/07/21-dap-minutes.html#action04]
<trackbot> Created ACTION-444 - Investigate ACTION-360 with Suresh to figure out if it can be closed or should be reassigned [on Josh Soref - due 2011-07-28].
ACTION-361?
<trackbot> ACTION-361 -- Bryan Sullivan to provide use cases for device characteristics access -- due 2011-03-23 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/361
<fjh> ACTION-360: Josh to follow up with Suresh, ACTION-444
<trackbot> ACTION-360 See at possibilities of APIs for access to device characteristics notes added
bryan_: I think this is part of sysinfo
... I suggest closing it if we aren't going to do anything with sysinfo
... I think there is a need for this, but I don't know that use cases will change anyone's mind
fjh: I think having use cases enables people to consider doing work
Josh_Soref: I think in this WG we're trying to always have UCs
... HTMLWG, WebApps, WebEvents, GeoLocation and DAP all try to require UCs
... and that pretty much defines browsers
CLOSE ACTION-361
<trackbot> ACTION-361 Provide use cases for device characteristics access closed
ACTION-362?
<trackbot> ACTION-362 -- Kangchan Lee to provide use cases for sysinfo-like features -- due 2011-03-23 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/362
CLOSE ACTION-362
<trackbot> ACTION-362 Provide use cases for sysinfo-like features closed
ACTION-364?
<trackbot> ACTION-364 -- Robin Berjon to get the COW started -- due 2011-03-23 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/364
ACTION-368?
<fjh> anyone can bring a use case into the WG without an action, also a proposal that is in scope
<trackbot> ACTION-368 -- WonSuk Lee to collect and summarize current use cases for Gallery API and includes a draft doc -- due 2011-03-23 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/368
ACTION-370?
<trackbot> ACTION-370 -- Robin Berjon to dive more deeply into Web Intents/Web Activities in view of integration -- due 2011-08-22 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/370
ACTION-374?
<trackbot> ACTION-374 -- Frederick Hirsch to complete Privacy Rulesets with binding considerations -- due 2011-03-23 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/374
ACTION-391?
<trackbot> ACTION-391 -- Dominique Hazaël-Massieux to look at overlap between MediaFileData and HTMLVideoElement -- due 2011-04-27 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/391
ACTION-396?
<trackbot> ACTION-396 -- Richard Tibbett to email the group looking for editors for Calendar -- due 2011-05-25 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/396
CLOSE ACTION-396
<trackbot> ACTION-396 Email the group looking for editors for Calendar closed
fjh: he did the email...
ACTION-397?
<trackbot> ACTION-397 -- Robin Berjon to coordinate with HTML WG chairs about Capture, include the HCG -- due 2011-05-25 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/397
ACTION-408?
<trackbot> ACTION-408 -- Dominique Hazaël-Massieux to check if dom + Suresh'es comments are integrated -- due 2011-06-15 -- CLOSED
<trackbot> http://www.w3.org/2009/dap/track/actions/408
ACTION-406?
<trackbot> ACTION-406 -- Frederick Hirsch to review feature request access containers -- due 2011-06-08 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/406
CLOSE ACTION-406
<trackbot> ACTION-406 Review feature request access containers closed
ACTION-411?
<trackbot> ACTION-411 -- Robin Berjon to reply to Jo about NetInfo -- due 2011-06-15 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/411
ACTION-412?
<trackbot> ACTION-412 -- Robin Berjon to go through inactive specs and ping editors to get a feel for their commitment to more work -- due 2011-06-15 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/412
CLOSE ACTION-412
<trackbot> ACTION-412 Go through inactive specs and ping editors to get a feel for their commitment to more work closed
fjh: we did that today
ACTION-413?
<trackbot> ACTION-413 -- Robin Berjon to contact Claudio Caldato from MS and discuss media capture -- due 2011-06-15 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/413
<fjh> ACTION-412: done during 21 July 2011 f2f
<trackbot> ACTION-412 Go through inactive specs and ping editors to get a feel for their commitment to more work notes added
ACTION-414?
<trackbot> ACTION-414 -- Anssi Kostiainen to write up an overview of the media capture landscape, with ideas of how to move forward -- due 2011-06-15 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/414
ACTION-415?
<trackbot> ACTION-415 -- Robin Berjon to make all the changes to Contacts from Dom's email http://lists.w3.org/Archives/Public/public-device-apis/2011Jun/0050.html -- due 2011-06-22 -- CLOSED
<trackbot> http://www.w3.org/2009/dap/track/actions/415
ACTION-417?
<trackbot> ACTION-417 -- Anssi Kostiainen to implement changes to battery event based on feedback, and RESOLUTION from 20110629 -- due 2011-07-06 -- CLOSED
<trackbot> http://www.w3.org/2009/dap/track/actions/417
ACTION-416?
<trackbot> ACTION-416 -- Frederick Hirsch to investigate privacy fingerprinting issues related to DAP -- due 2011-06-22 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/416
[ Scribe has issues with sequences ]
fjh: ernesto_jimenez, do you have everything you need for your editor work?
... you need to set up keys for CVS
... you can do that with francois today here
Josh_Soref: I should also get set up for that...
ACTION-423?
<trackbot> ACTION-423 -- WonSuk Lee to draft the use cases and requirements section for Battery -- due 2011-07-26 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/423
ACTION-424?
<trackbot> ACTION-424 -- Josh Soref to draft the use cases and requirements for Messaging, perhaps even take over Messaging editing -- due 2011-07-26 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/424
[ Josh_Soref looks ]
ACTION-427?
<trackbot> ACTION-427 -- Frederick Hirsch to prepare web app best practices for FPWD publication, including title change, shortname change, and adding reference to MWBP -- due 2011-07-26 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/427
CLOSE ACTION-427
<trackbot> ACTION-427 Prepare web app best practices for FPWD publication, including title change, shortname change, and adding reference to MWBP closed
fjh: I already did that
ACTION-429?
<trackbot> ACTION-429 -- Josh Soref to figure out if the PoCo handling of personal names is okay under I18N rules -- due 2011-07-26 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/429
ACTION-430?
<trackbot> ACTION-430 -- Josh Soref to provide sample input with potential outputs. -- due 2011-07-26 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/430
ACTION-432?
<trackbot> ACTION-432 -- Ernesto Jimenez to make a proposal for ISSUE-116 and ISSUE-117 -- due 2011-07-27 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/432
ACTION-433?
<trackbot> ACTION-433 -- Laszlo Gombos to reply to Anne about his Permissions questions -- due 2011-07-27 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/433
ACTION-434?
<trackbot> ACTION-434 -- Dominique Hazaël-Massieux to investigate if DAP could use the XPointer registration code for feature registration -- due 2011-07-27 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/434
ACTION-435?
<trackbot> ACTION-435 -- Laszlo Gombos to update the Permissions draft based on f2f discussion and summary email from Robin in planning for FPWD -- due 2011-09-01 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/435
ACTION-436?
<trackbot> ACTION-436 -- WonSuk Lee to provide an example for Permissions -- due 2011-07-27 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/436
ACTION-437?
<trackbot> ACTION-437 -- Laszlo Gombos to talk to the Android people about whether the Netinfo API is used and something they think was a good idea -- due 2011-07-27 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/437
ACTION-438?
<trackbot> ACTION-438 -- Josh Soref to talk to Brian Leroux about the Netinfo API in PhoneGap to ask about uptake and feedback -- due 2011-07-27 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/438
robin: I spoke with Brian about this
... pretty much every single phonegap api uses the connection api
... but I think they're using it for the wrong reason
ACTION-439?
<trackbot> ACTION-439 -- Bryan Sullivan to draft use cases for proximity, ambient light, and ambient sound sensors. -- due 2011-07-27 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/439
ACTION-440?
<trackbot> ACTION-440 -- Robin Berjon to create a wiki page with the list of tags -- due 2011-07-27 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/440
ACTION-441?
<trackbot> ACTION-441 -- Frederick Hirsch to raise the HTTP vs JS architectural issue with the TAG -- due 2011-07-28 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/441
ACTION-442?
<trackbot> ACTION-442 -- Robin Berjon to produce a REST binding example for Contacts (client, server, protocol) -- due 2011-07-28 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/442
ACTION-443?
<trackbot> ACTION-443 -- Frederick Hirsch to review various ruleset issues and follow up -- due 2011-07-28 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/443
ACTION-444?
<trackbot> ACTION-444 -- Josh Soref to investigate ACTION-360 with Suresh to figure out if it can be closed or should be reassigned -- due 2011-07-28 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/444
robin: End of Actions list
... 40 open actions
<fjh> proposed RESOLUTION: The DAP WG thanks Orange and Cécile Marc for excellent hosting
RESOLUTION: The DAP WG thanks Orange and Cécile Marc for excellent hosting
ACTION fjh to review the changes needed for the home page and priority list based on the new charter
<trackbot> Created ACTION-445 - Review the changes needed for the home page and priority list based on the new charter [on Frederick Hirsch - due 2011-07-28].
fjh: no meeting July 27
... we'll have a short meeting on Aug 3
proposed RESOLUTION: no call Aug 10
fjh: I don't know if we need a call on Aug 17
... robin and Dom are away
RESOLUTION: no call Aug 10
Adjourned
fjh: francois thanks for being Dom