Update README and rationale

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

Author: zolkis

README.md

@@ -1,9 +1,8 @@
 # Specification 'Web of Things (WoT) Scripting API'
 
-The main deliverable is the [WoT Scripting API Specification](./index.html).
-See the rendered version here: [http://w3c.github.io/wot-scripting-api/](http://w3c.github.io/wot-scripting-api/).
+The main deliverable is the [WoT Scripting API Specification](http://w3c.github.io/wot-scripting-api/).
 
-Copies of the releases for [published versions](https://www.w3.org/TR/wot-scripting-api/) are found in [releases](./releases/).
+Releases for [published versions](https://www.w3.org/TR/wot-scripting-api/) are found in [releases](./releases/).
 
 See the [rationale.md](./rationale.md) for explanation on API design choices.
 

rationale.md

@@ -15,19 +15,20 @@ As discussed in [issue 3](https://github.com/w3c/wot-scripting-api/issues/3), an
 Resolutions:
 - The browser implementations of the WoT Scripting API uses a namespace object `wot` in the browser.
 - Non-browser implementations that use various runtimes may use either a namespace object `wot`, or an API object provided by the `require()` or `import()` or similar mechanisms.
-- The `ConsumedThing` and `ExposedThing` objects are created by factory methods.
-
+- The `ConsumedThing` and `ExposedThing` objects are expected to be created by factory methods, though constructors are defined.
+- Interaction data can be retrieved with an attempted conversion by implementation as convenience interface for most JavaScript types, or as streams the applications can interpret.
+- Errors during protocol operations are exposed to applications.
 
 ## Discovery API
 
-Based on [WoT Current Practices](https://w3c.github.io/wot/current-practices/wot-practices.html#td-discovery), there are different discovery types: local (to the hardware), proximity based (such as BLE or NFC), registry (directory) based, and broadcast/multicast based. The discovery type is specific to the underlying protocol bindings.
+Represents the second stage of discovery in the [2-stage discovery process](https://github.com/w3c/wot-discovery/blob/master/proposals/directory.md).
 
 The discovery results may be filtered either at the source or at reception, by constraints made on the Thing Description.
 
 Based on [issue 16](https://github.com/w3c/wot-scripting-api/issues/16) there is a need to be able to tell the WoT Runtime to stop discovery (or in the case of open ended requests, suppress further discovery results). Therefore returning `Promise` was not an option any more, since cancellable `Promise`s were [dropped](https://github.com/tc39/proposal-cancelable-promises).
 
 Resolutions:
-- Use [Observables](https://github.com/tc39/proposal-observable) for controlling the discovery process (subscribe, unsubscribe).
+- Use [Observables](https://github.com/tc39/proposal-observable) or similar pattern for controlling the discovery process (subscribe, unsubscribe, handle notifications).
 - Use a single filter definition that also contains a property for discovery type, defaulting to `"any"`. It is simpler and more intuitive to use than having a separate parameter for discovery type. Some of the discovery types, such as registry/directory based discovery also require another parameter for the address of the directory. This can be provided as a required property in the discovery filter, described in the discovery algorithm.
 
 ## Server API (`ExposedThing`)