Merge pull request #274 from radu-matei/fix-docs-bundle

docs/invoice-spec.md

@@ -38,14 +38,14 @@ label.name = "foo.js"
 label.size = 248098
 label.origin = "footastic 1.2.3"
 ```
-(Source)[../test/data/simple-invoice.toml]
+[Source](../test/data/simple-invoice.toml)
 
 The above bindle declares its `bindle` description, and then declares a manifest containing three parcels.
 
 ## Top-level Fields
 
 - `bindleVersion` is required, and should be `1.0.0` for this version of the specification.
-- `yanked` is a boolean field that indicates whether a Bindle has been yanked. This field appears outside of the `bindle` because it is mutable, though it can only be toggled on. Once set to true, a Bindle MUST NOT be un-yanked. A yanked bundle should never be served in an index or search, but MAY be accessed directly.
+- `yanked` is a boolean field that indicates whether a Bindle has been yanked. This field appears outside of the `bindle` because it is mutable, though it can only be toggled on. Once set to true, a Bindle MUST NOT be un-yanked. A yanked bindle should never be served in an index or search, but MAY be accessed directly.
 - `yanked_reason` (OPTIONAL) is a string field in which a human-readable reason can be given for yanking the invoice.
 
 ## `bindle` Fields
@@ -68,7 +68,7 @@ The `annotations` section contains arbitrary name/value pairs. Implementors of t
 
 The annotations section is OPTIONAL.
 
-Implementations MUST NOT add fields anywhere else in the invoice except here and in the `annotations` field of a bundle label.
+Implementations MUST NOT add fields anywhere else in the invoice except here and in the `annotations` field of a bindle label.
 
 ### Reserved Annotations
 
@@ -202,7 +202,7 @@ label.mediaType = "application/x-javascript"
 label.name = "third"
 conditions.memberOf = ["utility"]
 ```
-(Source)[../test/data/full-invoice.toml]
+[Source](../test/data/full-invoice.toml)
 
 In the example above, three groups are declared:
 

docs/webassembly.md

@@ -699,7 +699,7 @@ library = "true"
 
 Above, we have used the `group` technique to declare two entrpoints, where the runtime must choose exactly one. One entrypoint has a `ui_kit` requirement and the other does not.
 
-When sg1 executes the bundle above, it will read through the `entrypoint` group, determining that it cannot execute `weather-ui.wasm` (because of the `ui_kit` requirement), but determining that it can run `weather-cli.wasm`.
+When sg1 executes the bindle above, it will read through the `entrypoint` group, determining that it cannot execute `weather-ui.wasm` (because of the `ui_kit` requirement), but determining that it can run `weather-cli.wasm`.
 
 Sg1 will then fetch `weather-cli.wasm` and `libalmanac.wasm` and execute those two locally.
 

src/standalone/mod.rs

@@ -17,7 +17,7 @@ pub const INVOICE_FILE: &str = "invoice.toml";
 /// The name of the parcels directory
 pub use crate::provider::file::{PARCEL_DAT, PARCEL_DIRECTORY as PARCEL_DIR};
 
-/// A struct containing paths to all of the key components of a standalone bundle
+/// A struct containing paths to all of the key components of a standalone bindle
 pub struct StandaloneRead {
  pub invoice_file: PathBuf,
  pub parcel_dir: PathBuf,