- From: Frederick Hirsch <w3c@fjhirsch.com>
- Date: Tue, 2 Feb 2016 21:22:09 -0500
- To: Anssi Kostiainen via GitHub <sysbot+gh@w3.org>
- Cc: public-device-apis@w3.org
Yes, basically having a template for the extension specs. Need to be careful with the truly normative testable portions however. I'd suggest using some other convention for the normative language intended for the extension specs (and customization) so that it is obvious. Perhaps formatting (italics) or different words, worth thinking about. good discussion here. > On Feb 1, 2016, at 6:11 AM, Anssi Kostiainen via GitHub <sysbot+gh@w3.org> wrote: > > I'd say your "informal" option sounds good. That is, use RFC2119 terms > everywhere and just wrap those blueprint reqs that need to be adapted > by extension specs into Note/Example blocks to make them > non-normative *in the Generic Sensor spec*. In addition, say in the > prose clearly what authors are expected to do if they want to write an > extensions spec for an AwesomeFutureSensor that conforms to the > Generic Sensor API. > > -- > GitHub Notification of comment by anssiko > Please view or discuss this issue at > https://github.com/w3c/sensors/issues/84#issuecomment-177918107 using > your GitHub account > regards, Frederick Frederick Hirsch Chair, W3C Device APIs WG (DAP) www.fjhirsch.com @fjhirsch
Received on Wednesday, 3 February 2016 02:22:46 UTC