W3C home > Mailing lists > Public > public-device-apis@w3.org > August 2014

Re: CfC: publish new LC draft of Battery API, respond by 21 August 2014

From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
Date: Wed, 20 Aug 2014 08:59:34 +0000
To: Frederick Hirsch <w3c@fjhirsch.com>
CC: W3C Device APIs WG <public-device-apis@w3.org>, Dominique Hazael-Massieux <dom@w3.org>
Message-ID: <163CF1DB-D279-4D8D-8CB5-0B1F569318E6@intel.com>
Hi Frederick, All,

On 11 Aug 2014, at 22:52, Frederick Hirsch <w3c@fjhirsch.com> wrote:

> This is a Call for Consensus (CfC) to publish a new Last Call of the Battery API working draft on 28 August 2014 with a 5 week last call period, ending 2 October 2014.

Ive prepared the following LC proposal to ease the review.

Battery Status API W3C Last Call Working Draft 28 August 2014:

  https://dvcs.w3.org/hg/dap/raw-file/default/battery/Overview.html

Please review the proposal. Ill create a LC2.html snapshot when the group is happy with it. Passes pub rules and link checker.

> In May 2012 we published a Candidate Recommendation  of the Battery API [1] and received implementer feedback, moving us to an asynchronous promises-based solution, as in the current Editors Draft [2]. Subsequently weve carefully reviewed and received feedback on this draft, creating new issues [3] which we have resolved with updates to the editors draft [4].
> 
> At this point I am aware of no open issues with the Battery API draft.

Correct.

> To avoid confusion with the very old synchronous draft it is imperative that we publish a new update; given that we have no open issues and have been receiving implementer feedback I believe a Last Call is entirely appropriate. 
> 
> The status section upon publication will list the changes and should provide a link to a diff and implementation report. Here is the current editors draft language on changes:
> 
> [[
> 
> The following changes have been made since the last published version:
> 
> 	 Expose BatteryManager via getBattery() returning a Promise instead of a synchronous accessor. (Section 5)
> 	 Clarify default values when a BatteryManager object is created. (Section 6)
> 	 Specify the behavior when a host device has more than one battery. (Section 6.1)
> 
> ]]

Further clarified the second bullet to say: "Clarify default values when a BatteryManager object is created and the implementation is unable to report the battery status information.

> Please note that we will continue to progress this draft under the old W3C process, given there is no advantage to switch at this point (please set the appropriate ReSpec flag in the publication process).

Set "processVersion: 2005 for this spec as well.

> Please indicate support or concern regarding this CfC by replying to this message by 21 August  - silence will be considered agreement (explicit agreement, even just a +1 preferred). Earlier responses would be helpful.

+1

Thanks,

-Anssi

> [1] http://www.w3.org/TR/2012/CR-battery-status-20120508/
> 
> [2] https://dvcs.w3.org/hg/dap/raw-file/tip/battery/Overview.html
> 
> [3] https://www.w3.org/2009/dap/track/products/24
> 
> [4] http://lists.w3.org/Archives/Public/public-device-apis/2014Aug/0034.html
Received on Wednesday, 20 August 2014 09:01:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:11 UTC