generalize phrasing to avoid specific host preference

Author: bfarias-godaddy

README.md

@@ -36,52 +36,55 @@ This proposal pursues the third option, as we expect it to lead to the best deve
 
 Module attributes have to be made available in several different contexts. This section contains one possible syntax, but there are other options, discussed in [#6](https://github.com/littledan/proposal-module-attributes/issues/6).
 
-Here, a key-value syntax is used, with the key `type` indicating the module type. Such key-value syntax can be used in various different contexts. Another option is to have just a single string (discussion in [#11](https://github.com/littledan/proposal-module-attributes/issues/11)).
+Here, a key-value syntax is used, with the key `type` used as an example indicating the module type. Such key-value syntax can be used in various different contexts. Another option is to have just a single string (discussion in [#11](https://github.com/littledan/proposal-module-attributes/issues/11)).
 
-The JavaScript standard would basically be responsible for passing the options bag up to the host environment, which could then decide how to interpret it. Issues [#24](https://github.com/littledan/proposal-module-attributes/issues/24) and [#25](https://github.com/littledan/proposal-module-attributes/issues/25) discuss the Web and Node.js semantics respectively, and issue [#10](https://github.com/littledan/proposal-module-attributes/issues/10) discusses how much we may or may not want to aim for unified behavior across different JavaScript environments.
+The JavaScript standard would basically be responsible for passing the options bag up to the host environment, which could then decide how to interpret it. Issues [#24](https://github.com/littledan/proposal-module-attributes/issues/24) and [#25](https://github.com/littledan/proposal-module-attributes/issues/25) discuss the Web and Node.js feature and semantic requirements respectively, and issue [#10](https://github.com/littledan/proposal-module-attributes/issues/10) discusses how to allow different JavaScript environments to have interoperability.
 
 ### import statements
 
 The ImportDeclaration would allow any arbitrary attributes after the `with` keyword.
 
-A `type` key should be mandatory to load a module that isn't JavaScript (json, css, html, ...).
+For example, in some environments a `type` key could be mandatory to load a module that isn't JavaScript (json, css, html, ...).
 
 ```js
 import json from "./foo.json" with type: "json";
 ```
 
 ### dynamic import()
 
-The `import` function will allow to provide arbritrary attributes as its second arguments.
+The `import` function will allow to provide arbitrary attributes as its second arguments.
 
 ```js
 import("foo.json", { type: "json" })
 ```
+### Integration Example
 
-### HTML
+A host environment may wish to have `type` or similar apply to loading WebAssembly. WebAssembly's validation would fail if the magic number is not correct, but we'd assert that the mimetype matches the type before even before running the WebAssembly validation.
 
-```html
-<script src="foo.wasm" type="webassembly"></script>
-```
-
-WebAssembly's validation would fail if the magic number is not correct, but we'd assert that the mimetype matches the type before even before running the WebAssembly validation.
+Note, this is an example; it's still uncertain whether importing WebAssembly modules would need to be marked specially, or could use `type="module"` just like JavaScript (and no special `with type:` in import statements). Further discussion in [#19](https://github.com/littledan/proposal-module-attributes/issues/19).
 
-Note, it's still uncertain whether importing WebAssembly modules would need to be marked specially, or could use `type="module"` just like JavaScript (and no special `with type:` in import statements). Further discussion in [#19](https://github.com/littledan/proposal-module-attributes/issues/19).
+From there, a host environment could integrate with its own APIs or even other languages:
 
-### WebAssembly
-
-For imports of other module types from within a WebAssembly module, this proposal would introduce a new custom section (named `importattributes`) that will annotate with attributes each imported module (which is listed in the import section).
-
-### Worker instantiation
+#### Worker instantiation
 
 ```js
 new Worker("foo.wasm", { type: "webassembly" });
 ```
 
+#### HTML
+
+```html
+<script src="foo.wasm" type="webassembly"></script>
+```
+
+#### WebAssembly
+
+For imports of other module types from within a WebAssembly module, this proposal would introduce a new custom section (named `importattributes`) that will annotate with attributes each imported module (which is listed in the import section).
+
 ## Status and plan for standardization
 
 This proposal has not yet been presented in a standards body. It's considered Stage 0 in TC39's process because we plan to present it to the committee. The plan is to collect feedback in issues, and present for Stage 1 in the December 2019 TC39 meeting.
 
-Standardization here would consist of building consensus not just in TC39 but also in WHATWG HTML as well as the Node.js ESM effort and a general plan for semantics across various JS environments ([#10](https://github.com/littledan/proposal-module-attributes/issues/10), [#24](https://github.com/littledan/proposal-module-attributes/issues/24) and [#25](https://github.com/littledan/proposal-module-attributes/issues/25)). Stage 2 will also require that we have a strong initial answer for the surface syntax ([#6](https://github.com/littledan/proposal-module-attributes/issues/6)), including the choice of whether we use a single string or key/value pairs ([#12](https://github.com/littledan/proposal-module-attributes/issues/12)).
+Standardization here would consist of building consensus not just in TC39 but also in WHATWG HTML as well as the Node.js ESM effort and a general audit of semantic requirements across various host environments ([#10](https://github.com/littledan/proposal-module-attributes/issues/10), [#24](https://github.com/littledan/proposal-module-attributes/issues/24) and [#25](https://github.com/littledan/proposal-module-attributes/issues/25)). Stage 2 will also require that we have a strong initial answer for the surface syntax ([#6](https://github.com/littledan/proposal-module-attributes/issues/6)), including the choice of whether we use a single string or key/value pairs ([#12](https://github.com/littledan/proposal-module-attributes/issues/12)).
 
 Please leave any feedback you have in the [issues](http://github.com/littledan/proposal-module-attributes/issues)!