RE: Push API - use parameterized Promise types

I still don't understand what you mean by normative vs. informative in this context, so I can't say whether my original statement bolsters one or the other :P


How would implementations differ if it were normative vs. if it were informative?


________________________________
From: Michael van Ouwerkerk <mvanouwerkerk@google.com>
Sent: Thursday, March 20, 2014 11:59
To: Domenic Denicola
Cc: public-webapps
Subject: Re: Push API - use parameterized Promise types

Well, I interpreted your comment that way ("it has no impact on anything"). Maybe normative vs informative is not what you meant though?

/m



On Thu, Mar 20, 2014 at 3:56 PM, Domenic Denicola <domenic@domenicdenicola.com<mailto:domenic@domenicdenicola.com>> wrote:
I am not sure what you mean in this context by normative vs. informative. How would implementations differ if it were normative vs. if it were informative?
________________________________
From: Michael van Ouwerkerk<mailto:mvanouwerkerk@google.com>
Sent: ?3/?20/?2014 11:46
To: Domenic Denicola<mailto:domenic@domenicdenicola.com>
Cc: public-webapps<mailto:public-webapps@w3.org>
Subject: Re: Push API - use parameterized Promise types

So it is not normative? It seems it would be very informative though, so still worth adding to the spec. But it seems it would be even better if it was changed to be normative.

Thanks,

Michael





On Thu, Mar 20, 2014 at 3:39 PM, Domenic Denicola <domenic@domenicdenicola.com<mailto:domenic@domenicdenicola.com>> wrote:
From: Michael van Ouwerkerk <mvanouwerkerk@google.com<mailto:mvanouwerkerk@google.com>>

> Ah I didn't know it has no effect on return values. Why not?

Well, I believe it's the same with all WebIDL method return values. If you return something that doesn't match the declared return value, that's a spec bug, but it has no impact on anything. (This is unlike argument values, where if the user passes in something that doesn't match the declared parameter type then conversion is performed.)