RE: publish FPWD of Alarm API; deadline Jan 15

Hi. Colleagues.
Giri accepted to publish FPWD of Alarm API as [1]. So it appears this CfC
passed.

@Dave: Could you help the chair for the Transition Request and Publication
Request?


[1] http://lists.w3.org/Archives/Public/public-sysapps/2013Jan/0120.html

For the chairs,
Wonsuk.


> -----Original Message-----
> From: Adam Barth [mailto:w3c@adambarth.com]
> Sent: Tuesday, January 15, 2013 5:32 AM
> To: Mandyam, Giridhar
> Cc: public-sysapps@w3.org; Wonsuk Lee
> Subject: Re: publish FPWD of Alarm API; deadline Jan 15
> 
> On Mon, Jan 14, 2013 at 11:19 AM, Mandyam, Giridhar <mandyam@quicinc.com>
> wrote:
> > 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.
> 
> You're right that advancing a document to FPWD is an important step in its
> journey towards REC.  The most important issues to address at this stage
> relate to the scope of the document because those issues have a strong
> bearing on the call for exclusions.  (It's also important to address
> issues related to copyright and the level of interest from implementors
> and authors.)
> 
> > 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.
> 
> As chair, one of my jobs is to ensure that the working group (and the
> editor) consider technical feedback about our specifications.  By creating
> an issue in the issue tracker, we can be sure that we won't forget about
> your concerns, and we'll make sure the working group discusses the issues
> and reaches a decision (hopefully by rough
> consensus) prior to advancing the document to CR.
> 
> Adam
> 
> 
> > 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 Wednesday, 30 January 2013 08:46:26 UTC