Re: Comments on 22 June 2010 draft of Web Notifications

Thanks for your comments, Art.  I've addressed them below and pushed a new
draft.

On Thu, Sep 16, 2010 at 5:36 AM, Arthur Barstow <art.barstow@nokia.com>wrote:

>
>  Some high-level comments on the June 22 draft of Web Notifications:
>
> * Section 1/2 - "alert" should be defined, especially its relationship to
> the 3 types of notifications defined in Section 1; (would it be possible to
> not even use that term in its noun form in this spec e.g. replace it with
> "{ambient,interactive,persistent} notification"?)
>

I'm not sure which instance of the word 'alert' you mean (or which is
section 1/2), but I agree about using the word alert as a noun being
ambiguous, and have changed all cases to a verb form where an application
'alerts' the user using a notification.


> * Section 2, 1st req - I find this requirement a bit difficult to parse and
> that may be caused by it being more of a design goal than a specification
> requirement. I think part of the problem is the use of "implementation" at
> the beginning and "specification" at the end. For instance, to what does
> "implementation" refer?
>

It is a requirement of the specification that it can be implemented using
only system notification platforms.  It could be part of a separate
specification requirements document, along this entire Section 2, but is for
convenience placed at the beginning of the document.  Open to suggestions.


>
> * Section 2, 3rd req - seems like this should be "The specification must
> support ambient notifications" or is there some additional constraint you
> want to define; perhaps it would be useful to reword this as a positive
> "must" requirement rather than a "must not" requirement
>

This is not intended to refer to ambient notifications vs persistent
notifications, but to notifications coming from an unauthorized source,
regardless of ambience (i.e., it speaks to the permissions parts of the
spec).  I have rewritten it in an attempt to clarify.


>
> * Section 2, 6th req - I find this requirement a bit difficult to parse and
> I think the problem is with the use of "implementation" in this context.
> From the perspective of a requirement for the spec, it appears the idea is
> the spec must support persistent notifications and an implementation, for
> what ever reason, may not actually support those types of notifications.
>
> * Section 2, 4th UC - it seems like this is the same as the 1st UC (and if
> so, perhaps it should be deleted)
>

The goal is to indicate that Web Notifications API can be used by a browser
itself or operating system rather than just a web application.  If we don't
believe that should be in scope, I can remove it.


>
> * Section 2, 5th UC - I don't quite understand this UC. Is this trying to
> build a dependency on Web Workers?
>
> No, this UC motivates the inclusion of the replaceId feature which
specifically provides for preventing duplicates.


> * Section 3.2, 2nd para - this text is prescriptive so why is it in a
> non-normative section?
>

I have moved it to section 5.

>
> * Section 4 - "security origin" should be defined
>

Added a definition.


>
> * Section 5 - sorry for my ignorance here but why is "Center" used in the
> name; it would be useful to expand a bit on what is meant by "simple
> notification" (e.g. contrast it with Web Notifications)
>
> The name NotificationCenter is derived from the current WebKit
implementation, and merely tries to indicate a grouping of
notifications-related interfaces.  There's nothing particularly special
about it.  "Simple Notification" is defined in section 1, which I think
covers it, but if there is remaining confusion I will adjust this.


> * Section 5 - what is the use case for PERMISSION_UNKOWN; not sure what
> "unless otherwise specified" means in this context
>

I added a longer explanation.  The use case is for a web app to be able to
present appropriate UI requesting permission, and thus should know whether
permission has actually been denied, or is just in an off-by-default state.

>
> * Section 5 - createNotification says it returns a "text" notification
> objection and it's not clear what text means in this context.
>
> Changed to "simple notification" per the terminology.


> * Section 7.1 - this info seems more like hints and as such, perhaps it
> should be non-normative
>

Agreed and changed.


>
> * Section 9 - perhaps this info and examples should be marked non-normative
>

Agreed and changed.


>
> BTW, do you have a guestimate on when you think this spec will be ready for
> a First Public Working Draft?
>

Before this working group was created, there was a plan to break the spec
into a few pieces (simple notifications, web notifications, and permissions
model) so that there could be more consensus on more sections.  Now that we
are active, I will make this change ASAP unless there is objection from the
group and I think we can move forward to FPWD then.

As always, open to more comments on the current draft.

Thanks,
 -John