Update WoT runtime related text based on discussion in w3c#2

Signed-off-by: Zoltan Kis <[email protected]>

Author: zolkis

index.html

@@ -107,7 +107,7 @@
     This document defines conformance criteria that apply to a single product: the <dfn>UA</dfn> (user agent) that implements the interfaces it contains.
   </p>
   <p>
-    The UA may be implemented in the browser, or in a separate runtime environment.
+    The UA may be implemented in the browser, or in a separate runtime environment, such as [Node.js](https://nodejs.org/en/) or small embedded runtimes such as the [JavaScript Runtime for Zephyr OS](https://www.zephyrproject.org/community/blog/introducing-javascript-runtime-zephyr-os).
   </p>
   <p>
     This specification can be used for implementing the WoT Scripting API in multiple language bindings. Currently ECMAScript and TypeScript definitions are described in this document. For specifying bindings in other languages, extensions of this document may be created later.
@@ -125,7 +125,7 @@
 
   <section> <h2>Terminology and conventions</h2>
   <p>
-    A <dfn>WoT runtime</dfn> or simply <dfn>Runtime</dfn> is defined as a software stack that manages the lifecycle of WoT application scripts (see also the [Wikipedia definition](https://en.wikipedia.org/wiki/Runtime_system)). In the case of ECMAScript and TypeScript scripts, it consists of an ECMAScript interpreter, script lifecycle management, and an operating system API that provides access to local and remote resources. A Runtime can be modeled as a virtual machine in the sense that it should be completely isolated from other execution environments on memory address space, storage address space (file system), network namespace, etc. A runtime may be for instance a Node.js environment, an embedded runtime based on a small JavaScript engine, or provided by a browser.
+    A <dfn>WoT Runtime</dfn> or <dfn>WR</dfn> is defined as a software stack that manages the lifecycle of WoT application scripts, implements a script interpreter, an event loop, a security enforcement point for access management and uses an operating system API that provides access to local and remote resources. A <a>WR</a> should be isolated from other execution environments on memory address space, storage address space (file system), network namespace, etc. For instance, a <a>WR</a> may be implemented in a Node.js environment, or in an embedded runtime based on a small JavaScript engine, or in a browser.
   </p>
   <p>
     The following terms are defined in [[!WOT-PRACTICES]]:
@@ -375,13 +375,12 @@
   <p>
     The <dfn>WoT object</dfn> exposes only functions and has no internal state.
   </p>
-  <p class="issue">
-     Because of this, implementations MAY use a global object, or provide a constructor, or provide the API object, or by other means (e.g. by `require()`). Since the common denominator across various <a>Runtime</a> types would be to use a constructor, this would be recommended. As a consequence, the <a>ConsumedThing</a> and <a>ExposedThing</a> objects could also be constructed, complete with an asynchronous fetch functionality.
-  </p>
   <p class="note">
-    The WebIDL interfaces presented in this initial version of the document are based on the [[!WOT-PRACTICES]]. It is expected to be updated soon.
+     Browser implementations SHOULD use a namespace object such as `wot`, and [Node.js](https://nodejs.org/en/)-like runtimes MAY provide the API object through the [`require()`](https://nodejs.org/api/modules.html) mechanism.
   </p>
   <pre class="idl">
+    [SecureContext]
+    [NamespaceObject]
     interface WoT {
       Promise&lt;void&gt; discover(ThingFilter filter, ThingDiscoveryCallback onfound);
 
@@ -502,8 +501,7 @@
 
   <section> <h2>Acknowledgements</h2>
     <p>
-      The editors would like to thank Dave Raggett, Matthias Kovatsch, and Michael Koster for their
-      comments and guidance to this document.
+      The editors would like to thank Dave Raggett, Matthias Kovatsch, and Michael Koster for their comments and guidance to this document.
     </p>
   </section>