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

> From: ext Kostiainen, Anssi [mailto:anssi.kostiainen@intel.com]
> 
> On 09 Jun 2014, at 13:17, Mounir Lamouri <mounir@lamouri.fr> wrote:
> 
> > On Sat, 7 Jun 2014, at 8:04, cathy.chan@nokia.com wrote:
> >> 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 defaults spec'd herein emulate fully charged battery. This means that
> with these defaults, the experience is the same as if the device had full
> battery.
> 
That's helpful in understanding the behaviors that are being specified. I think it's worth a note in the spec.

> >> [[
> >> 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.
> >> ]]
> 
> This should align with the defaults described above assuming we want to still
> emulate the full battery, thus chargingTime must be 0 if the implementation
> is unable to report the remaining charging time.
> 
> Mounir - WDYT? How do the implementations comply with the above
> proposal?
> 
> >> 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.
> 
> Cathy - what are the clarification needed to support multiple batteries?

Let's say a system has two batteries, is unable to determine the status of one, and the other one is discharging. The aggregate battery would have
   charging = true
   chargingTime =  positive infinity
   dischargingTime = positive infinity
   level = avg(1.0, level of second battery)
The aggregate chargingTime of positive infinity would match the definition of using positive infinity for unknown chargingTime, but not so much if unknown chargingTime is to be represented by 0. But since we have the catch-all "or otherwise" in using positive infinity for chargingTime, this might not be a big problem after all.

(Having said that, I'm in favor of not defining these aggregation rules at all. See http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0042.html).

> 
> > So, the confusion is that when the battery is charging but not full
> > and the system can't report the charging time, it should report it as
> > Infinity. I added that precision.
> 
> >> 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.
> >
> > Hmm, I am not sure what to do here. It is purely editorial and Anssi
> > wrote that originally so I would prefer to let him decide how to
> > change the wording.
> 
> I moved all the descriptive text into its own paragraph after the IDL block:
> 
> https://dvcs.w3.org/hg/dap/rev/65ff0151a2e5
> 

This is even better! Thanks.

One more comment:

[[
The dischargingTime attribute MUST be set to the value positive Infinity, if the battery is charging, the implementation is unable to report the remaining discharging time, there is no battery attached to the system, or otherwise.
]]

What does "or otherwise" mean when it appears in the first sentence of a paragraph? "otherwise" of what? Does it pretty much mean the UA can use the value of positive infinity at its own discretion?

- Cathy.

Received on Monday, 9 June 2014 21:39:13 UTC