Merge pull request #153 from WebAssembly/postmvp

Short document name bikeshed.

9 files changed, 26 insertions, 26 deletions

diff --git a/AstSemantics.md b/AstSemantics.md
index 05d2092..f295559 100644
--- a/AstSemantics.md
+++ b/AstSemantics.md
@@ -130,7 +130,7 @@ which leads to the following advantages:
     splitting, which can reduce throughput overhead, at the cost of increasing
     code size (potentially very significantly in pathological cases).
   * The
-    [signature-restricted proper tail-call](EssentialPostMVPFeatures.md#signature-restricted-proper-tail-calls)
+    [signature-restricted proper tail-call](PostMVP.md#signature-restricted-proper-tail-calls)
     feature would allow efficient compilation of arbitrary irreducible control
     flow.
 
@@ -158,12 +158,12 @@ to easily be folded into the hardware load instruction *and* for groups of loads
 with the same base and different offsets to easily share a single bounds check.
 
 In the MVP, the indices are 32-bit unsigned integers. With
-[64-bit integers](EssentialPostMVPFeatures.md#64-bit-integers) and
+[64-bit integers](PostMVP.md#64-bit-integers) and
 [>4GiB heaps](FutureFeatures.md#heaps-bigger-than-4gib), these nodes would also
 accept 64-bit unsigned integers.
 
 In the MVP, heaps are not shared between threads. When
-[threads](EssentialPostMVPFeatures.md#threads) are added as a feature, the basic
+[threads](PostMVP.md#threads) are added as a feature, the basic
 `LoadHeap`/`StoreHeap` nodes will have the most relaxed semantics specified in
 the memory model and new heap-access nodes will be added with atomic and
 ordering guarantees.
diff --git a/BinaryEncoding.md b/BinaryEncoding.md
index 97a143f..3aad2a6 100644
--- a/BinaryEncoding.md
+++ b/BinaryEncoding.md
@@ -123,8 +123,9 @@ conflict-avoidance practices surrounding string names:
   * To avoid (over time) large index-space declaration sections that are largely the same
     between modules, finalized versions of standards would define named baseline index spaces
     that modules could optionally use as a starting point to further refine.
-    * For example, to use all of [the MVP](MVP.md) plus [SIMD](EssentialPostMVPFeatures.md#fixed-width-simd)
-      the declaration could be "base" followed by the list of SIMD opcodes used.
+    * For example, to use all of [the MVP](MVP.md) plus
+      [SIMD](PostMVP.md#fixed-width-simd) the declaration could be "base"
+      followed by the list of SIMD opcodes used.
     * This feature would also be most useful for people handwriting the [text format](TextFormat.md).
     * However, such a version declaration does not establish a global "version" for the module
       or affect anything outside of the initialization of the index spaces; decoders would
diff --git a/FutureFeatures.md b/FutureFeatures.md
index dbadd13..dd4a33c 100644
--- a/FutureFeatures.md
+++ b/FutureFeatures.md
@@ -2,10 +2,10 @@
 
 These are features that make sense in the context of the
 [high-level goals](HighLevelGoals.md) of WebAssembly but are not considered part
-of the [Minimum Viable Product](MVP.md) or the
-[essential post-MVP feature set](EssentialPostMVPFeatures.md) which are expected
-to be standardized immediately after the MVP. These will be prioritized based on
-developer feedback, and will be available under [feature tests](FeatureTest.md).
+of the [Minimum Viable Product](MVP.md) or the essential [post-MVP](PostMVP.md)
+feature set which are expected to be standardized immediately after the
+MVP. These will be prioritized based on developer feedback, and will be
+available under [feature tests](FeatureTest.md).
 
 ## Great tooling support
 
diff --git a/HighLevelGoals.md b/HighLevelGoals.md
index 57d36ce..bd23ea7 100644
--- a/HighLevelGoals.md
+++ b/HighLevelGoals.md
@@ -12,8 +12,8 @@
     * ship an effective and efficient [polyfill](Polyfill.md) library for the
       MVP that translates WebAssembly code into JavaScript in the client so that
       WebAssembly MVP can run on existing browsers;
-    * ship a follow-up to the MVP which adds several more
-      [essential features](EssentialPostMVPFeatures.md); and
+    * ship a [follow-up to the MVP](PostMVP.md) which adds several more
+      essential features; and
     * continue to iteratively specify [additional features](FutureFeatures.md),
       prioritized by feedback and experience, including support for languages
       other than C/C++.
diff --git a/MVP.md b/MVP.md
index 4d557d1..e800528 100644
--- a/MVP.md
+++ b/MVP.md
@@ -3,10 +3,10 @@
 As stated in the [high-level goals](HighLevelGoals.md), the first release aims
 at being a Minimum Viable Product (MVP). This means that there are important
 features we *know* we want and need, but are post-MVP; these are in a separate
-[essential post-MVP features doc](EssentialPostMVPFeatures.md). The MVP will
-contain features which are available today in modern web browsers and which
-perform well even on mobile devices, which leads to roughly the same
-functionality as [asm.js](http://asmjs.org).
+essential [post-MVP](PostMVP.md) features document. The MVP will contain
+features which are available today in modern web browsers and which perform well
+even on mobile devices, which leads to roughly the same functionality as
+[asm.js](http://asmjs.org).
 
 This document explains the contents of the MVP at a high-level. There are also
 separate docs with more precise descriptions of:
diff --git a/Nondeterminism.md b/Nondeterminism.md
index 308861d..d6693ca 100644
--- a/Nondeterminism.md
+++ b/Nondeterminism.md
@@ -25,16 +25,16 @@ other practical way to achieve [portable](Portability.md) native performance.
 The following is a list of the places where the WebAssembly specification
 currently admits nondeterminism:
 
- - [When threads are added as a feature](EssentialPostMVPFeatures.md#threads),
-   even without shared memory, nondeterminism will be visible through the
-   global sequence of API calls. With shared memory, the result of load
-   operations is nondeterministic.
+ - [When threads are added as a feature](PostMVP.md#threads), even without
+   shared memory, nondeterminism will be visible through the global sequence of
+   API calls. With shared memory, the result of load operations is
+   nondeterministic.
 
  - [Out of bounds heap accesses *may* want some flexibility](AstSemantics.md#out-of-bounds)
 
  - [NaN bit patterns](AstSemantics.md#floating-point-operations)
 
- - [Fixed-width SIMD may want some flexibility](EssentialPostMVPFeatures.md#fixed-width-simd)
+ - [Fixed-width SIMD may want some flexibility](PostMVP.md#fixed-width-simd)
    - In SIMD.js, floating point values may or may not have subnormals flushed to zero.
    - In SIMD.js, operations ending in "Approximation" return approximations that may vary between platforms.
 
diff --git a/EssentialPostMVPFeatures.md b/PostMVP.md
index 9d4347f..9d4347f 100644
--- a/EssentialPostMVPFeatures.md
+++ b/PostMVP.md
diff --git a/README.md b/README.md
index ad79830..9d132a2 100644
--- a/README.md
+++ b/README.md
@@ -10,7 +10,7 @@ followed by the [FAQ](FAQ.md).
 
 We've mapped out features we expect to ship:
  1. In [the Minimum Viable Product (MVP)](MVP.md);
- 2. Closely [after the MVP](EssentialPostMVPFeatures.md);
+ 2. Closely [after the MVP](PostMVP.md);
  3. In [future versions](FutureFeatures.md).
 
 Join us:
diff --git a/Web.md b/Web.md
index e1f2513..f64e5cd 100644
--- a/Web.md
+++ b/Web.md
@@ -33,14 +33,13 @@ that the design, especially that of the [MVP](MVP.md), are sensible:
     and call an undefined `extern` function and the target JavaScript function
     would be given the (mangled) name of the `extern` and put inside the
     imported ES6 module.
-* Once [threads are supported](EssentialPostMVPFeatures.md#Threads), a
-  WebAssembly module would initially be distributed between workers via
-  `postMessage()`.
+* Once [threads are supported](PostMVP.md#Threads), a WebAssembly module would
+  initially be distributed between workers via `postMessage()`.
   - This also has the effect of explicitly sharing code so that engines don't
     perform N fetches and compile N copies.
   - May later standardize a more direct way to create a thread from WebAssembly.
-* Once [SIMD is supported](EssentialPostMVPFeatures.md#Fixed-width-SIMD), a Web
-  implementation of WebAssembly would:
+* Once [SIMD is supported](PostMVP.md#Fixed-width-SIMD), a Web implementation of
+  WebAssembly would:
   - Be statically typed analogous to [SIMD.js-in-asm.js][];
   - Reuse specification of operation semantics (with TC39);
   - Reuse backend implementation (same IR nodes).