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

RE: [battery] Battery Editors Draft update needed to prepare for LC

From: <cathy.chan@nokia.com>
Date: Fri, 6 Jun 2014 22:04:05 +0000
To: <mounir@lamouri.fr>, <public-device-apis@w3.org>
Message-ID: <503e7ef4249a43aaab482a741352587f@NOKWDCFIEXCH02P.nnok.nokia.com>
A few comments on the changes...

In Section 5 Navigator Interface, the second step says 
If those steps were previously successfully run in the current browsing context ...
It is not clear what "those steps" refer to. "these steps" would actually be more accurate. Alternatively, consider something like "If an instance of BatteryManager has previously been created in the current browsing context..."

In Section 6 BatteryManager Interface, the following two statements are conflicting with regard to what the value of chargingTime should be when the implementation is unable to report it:
When a BatteryManager object is created, if the implementation is unable to report the battery's charging state, charging time, level or remaining time, charging MUST be set to true, ***chargingTime to 0***, level to 1.0 and dischargingTime to the value positive Infinity respectively.
The chargingTime attribute MUST be set to 0, if the battery is full or there is no battery attached to the system, and ***to the value positive Infinity if the battery is discharging, the implementation is unable to report the remaining charging time***, or otherwise.
I don't remember which one was the agreed behavior, but would note that the latter one works well in the multiple batteries scenario as described. If the former one is used, the multiple batteries description might need more tweaks.

While we're looking at the attributes of BatteryManager, I would suggest swapping the order of the sentences within each paragraph. Begin with what the attribute represents, followed by how its value should be set. For example:
The charging attribute represents the charging state of the system's battery. It MUST be set to false if the battery is discharging, and set to true, if the battery is charging, the implementation is unable to report the state, or there is no battery attached to the system, or otherwise. When the battery charging state is updated, the user agent MUST queue a task which sets the charging attribute's value and fires a simple event named chargingchange at the BatteryManager object.
It reads more naturally.

In Examples 3 and 4:
	navigator.getBattery(function(battery) {
should be 
	navigator.getBattery().then(function(battery) {

Finally, clearly just a nit...
In Example 1 & 2, clearTimeout(...) should be clearInterval(...).

Regards, Cathy.

> -----Original Message-----
> From: ext Mounir Lamouri [mailto:mounir@lamouri.fr]
> Sent: Friday, June 06, 2014 8:51 AM
> To: public-device-apis@w3.org
> Subject: Re: [battery] Battery Editors Draft update needed to prepare for LC
> On Tue, 3 Jun 2014, at 23:19, Frederick Hirsch wrote:
> > Anssi, Mounir
> >
> > As I mentioned earlier [1], the Battery CfC has completed successfully
> > so we have agreed to the propose to use promises (async proposal).
> >
> > Can you, the editors of the specification, please incorporate the
> > changes proposed by Tim Volodine [2] into the editors draft? This will
> > require additional edits beyond a simple cut-paste, as the details
> > will span more of the document.
> >
> > Please also add a reference to Promises. For now I guess the best is
> > to put both a link to the ECMAScript wiki [3] as well as the latest
> > draft which includes the latest promises revision (22 May 2014 Draft
> > revision )
> > http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
> > (PDF
> > download)
> >
> > In addition, can you please update the status section to list this
> > change (and any others since the last publication (CR on 8 May),
> > provide  a link to a diff, add a link to the test cases, and check the
> > validation and links.
> >
> > Once we have this draft I would like to start a CfC to publish a Last
> > Call, which will require a publication draft with updated dates.
> > Having this editors draft should help with DAP members review it and
> > respond to the CfC.
> Hi,
> I have updated the editor draft. It can be found here:
> https://dvcs.w3.org/hg/dap/raw-file/default/battery/Overview.html
> It contains a list of changes in the "State of this Document" section.
> Otherwise, a detailed list of commits can be found here:
> https://dvcs.w3.org/hg/dap/rev/104f34bf5872
> https://dvcs.w3.org/hg/dap/rev/f9fb2068c558 (editorial changes)
> https://dvcs.w3.org/hg/dap/rev/77dbe211ed07
> https://dvcs.w3.org/hg/dap/rev/d03d51adec91
> Frederick, let me know when would be a good time to generate a LC
> document. I assume that we will do the CfC before?
> Thanks,
> -- Mounir
Received on Friday, 6 June 2014 22:04:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:03 UTC