Re: publish FPWD of Alarm API; deadline Jan 15

Hi Giri,

Thanks for your feedback.  Your concerns appear to be about technical
details of the specification, which means they're probably better
addressed after FPWD.  A first-public working draft is just that: a
working draft.  Typically FPWDs still need a lot of work before they
can advance further towards REC.

If you like, we can record (a)-(e) as issues in our issue tracker,
which will ensure that the working group will discuss and resolve the
issues before advancing the document beyond FPWD.  Does that sound
like a reasonable course of action?

Adam


On Mon, Jan 14, 2013 at 8:58 AM, Mandyam, Giridhar <mandyam@quicinc.com> wrote:
> Hello,
> Qualcomm Innovation Center, a member of the SysApps Working Group, objects to the publication of the Alarm API as an FPWD.
>
> Some items we would like clarified in any subsequent modifications of the Editor's Draft are:
>
> a) Section 4.2:  The error codes returned for add() and remove() are not defined.  This is not consistent with other device-level API's defined in the W3C that would likely be used in a SysApps deployment (e.g. see the Geolocation API, http://dev.w3.org/geo/api/spec-source.html#position_error_interface).
> b) Section 4.2: The data object in add() is has to be in valid JSON format.  Why?   Why not another textual format?
> c) Section 4: "The returned ID is unique (within the application origin) and can be used to specify and remove the added alarm."  The term 'application origin' does not clarify whether the ID is unique for each instance of the application, or it is unique with respect to all instances of an application that are open at any given instant in time on the same device.
> d) Section 4.2.  Why is TimeZoneDirective an enum (as opposed to a Boolean)?  If there are only two options for the method argument, I don't see the point in defining an enum.
> e) Section 4.2:  DST guidance is not apparent in the current spec.  Is DST always honored with respect to alarms?  I'm unclear as to what should occur if a DST event (e.g. moving the clock forward or backwards by an hour) occurs between when the alarm was set and when the alarm occurs.
>
> -Giri Mandyam
>
> -----Original Message-----
> From: Adam Barth [mailto:w3c@adambarth.com]
> Sent: Tuesday, January 08, 2013 11:53 PM
> To: public-sysapps@w3.org
> Cc: Wonsuk Lee
> Subject: CfC: publish FPWD of Alarm API; deadline Jan 15
>
> Colleagues,
>
> This is a Call for Consensus to publish a First Public Working Draft of the Alarm API spec using the following ED as the basis <http://sysapps.github.com/sysapps/proposals/alarm/Overview.html>.
>
> This CfC satisfies the group's requirement to "record the group's decision to request advancement".
>
> By publishing this FPWD, the group sends a signal to the community to begin reviewing the document. The FPWD reflects where the group is on this spec at the time of publication; it does not necessarily mean there is consensus on the spec's contents.
>
> If you have any comments or concerns about this CfC, please send them to public-sysapps@w3.org by January 15 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal.
>
> For the chairs,
> Adam
>

Received on Monday, 14 January 2013 17:37:38 UTC