Re: Progressing Wake Lock API to W3C FPWD?

On 12/14/14 17:52, Marcos Caceres wrote:
> 
> 
> 
> On December 12, 2014 at 11:09:23 PM, Dominique Hazael-Massieux (dom@w3.org) wrote:
>>> See http://www.w3.org/2014/08/pubworkflow.html — the idea  
>> is to make it
>> possible to automatically push updates of editors draft as published  
>> Working Drafts in TR space (provided the WG agrees to use that  
>> shortcut).
> 
> I can't remember if we ran a CFC to do this or not in this group (I think we did one in WebApps and no objections were raised). If not, we should start one ASAP. 

[sorry if this eventually ends up as a dup, I've tried to change my
email address - still within the same org - but the W3C system seems to
have only partially accepted that]

I haven't followed the entire discussion of this, but I'd like to point
out there's a mismatch between the two documents in question.

In the actual specification, we have:
===
2. Wake Locks

A wake lock prevents some aspect of the device or operating system from
entering a power-saving state.

This specification deals specifically with the screen wake lock which
prevents the screen(s) of the device from entering a power-saving state.
===

and in the non-normative Use Case document we have:
===
12. Requirements

Any specification seeking to address these requirements:

    MUST support requesting a wake lock on at least the system and on
the display. The display being the screen or primary output modality of
the device. The system meaning that the device can put the screen to
sleep, but MUST continue running a task until an application releases
the lock on the system. Keeping the screen awake MUST (obviously) also
keep the system awake.
===

that is, the use cases are saying the resulting specification needs to
address two lock targets, while it actually addresses only one. Perhaps
we need to update the Use Case document? I'm not sure how a use case doc
can have MUST claims in it anyway, as a non-normative doc.

Received on Tuesday, 16 December 2014 15:36:52 UTC