RE: publish FPWD of Alarm API; deadline Jan 15

Hello Adam,
Thanks for your speedy response.  I do not believe that the step to making a spec an FPWD is a trivial one.  In particular, calls-for-exclusion attach (see http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion).  I agree that the spec will most likely undergo revisions in ensuing WD's, but at this point I would like to see as many technical issues addressed as reasonably possible prior to the publication of the FPWD.

I must also state that I don't believe some (if not all) of my comments on this spec are really new.  They have been repeated in some form or another on the mailing list by other persons.  Yet the editor in my opinion has not responded to them, nor has the text in the specification substantially changed in light of prior feedback.

We can certainly enter these issues into the tracker, but the objection to making this an FPWD still stands.  

-Giri

-----Original Message-----
From: Adam Barth [mailto:w3c@adambarth.com] 
Sent: Monday, January 14, 2013 9:37 AM
To: Mandyam, Giridhar
Cc: public-sysapps@w3.org; Wonsuk Lee
Subject: 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 19:20:19 UTC