RE: [battery] Still some questions on battery status

Thank you Anssi for the update.

I think the changes would be sufficient to remove the potential ambiguities.
It's fine to go without describing the processing model. 

A couple additional comments on the table for the attribute values
1. The rows for critical/low have different meaning from that for ok: for
critical, it is to be interpreted as {isPlugged is false AND level <
critical_threshold}, whereas for ok, it is to be interpreted as {isPlugged
is true OR level > low_threshold}. To keep this table format, we need two
separate rows for ok, one for {isPlugged is false and level > low_threshold}
and another for {isPlugged is true} (with any value of level).
2. The boundary cases of level=critical_threshold and level=low_threshold
are missing. My bad for the oversight in the first place.

Regards, Cathy.


-----Original Message-----
From: Anssi Kostiainen [mailto:anssi.kostiainen@nokia.com] 
Sent: Monday, September 12, 2011 7:53 AM
To: public-device-apis@w3.org WG; Chan Cathy (Nokia-CIC/Boston)
Subject: Re: [battery] Still some questions on battery status

Hi,

On 9.9.2011, at 23.59, ext Cathy.Chan@nokia.com wrote:

> I don't necessarily argue with that design and usage, but I would 
> argue that it's not clearly presented. If there's room for 
> misinterpretation, there's probably room for improvement.
> 
> IMHO the confusion comes from basing the definition of a state (the 
> status
> attribute) on the definition of a state change (the battery 
> critical/low/ok events). To me, that seems a bit backward. I would 
> rather define the exact conditions under which the status attribute is 
> assigned each of the defined values, and define that the events are 
> triggered when the value of the status attribute changes.

The spec is written with the following processing model in mind:

1. isPlugged and/or level changes, values are set 2. if the stated
conditions are met status attribute changes its value to "low", "critical"
or "ok" and a battery{low|critical|ok} event is dispatched 3. a
batterystatus event is dispatched

I'd guess that if you're implementing this API, you'd be listening to some
platform-level API in step 0 for isPlugged and level changes (in the
playground demo I was listening to change events on input elements).

Would it make things clearer if the above-mentioned processing model would
be in the spec?

> Based on Robin's explanation and Anssi's battery events playground 
> (which is very useful by the way, so thanks Anssi), my understanding 
> is that for the status attribute:
> 	critical: isPlugged is false and level < critical_threshold
> 	low: isPlugged is false and critical_threshold < level < 
> low_threshold
> 	ok: isPlugged is true or level > low_threshold
> 	null: level is null
> Those conditions should go into the definition for the status attribute.

Thanks, I added this to the spec as a table under the status attribute
definition.

> If I were allowed to pick one more nit, I would also say that the 
> status attribute does more than "represents how much of the internal 
> power source remains", as isPlugged also plays a role in its value.

Changed to: "Represents the battery status of the hosting device".

Thanks for the feedback.

-Anssi