From fcd8a3ecab8401715f29ff542839717f72b963e8 Mon Sep 17 00:00:00 2001
From: Luke Wagner <mail@lukewagner.name>
Date: Thu, 18 Jun 2026 15:41:25 -0500
Subject: [PATCH 1/3] Add @external-id

---
 design/mvp/Binary.md    |  72 ++++----
 design/mvp/Explainer.md | 356 +++++++++++++++-------------------------
 design/mvp/WIT.md       |  95 ++++++++---
 3 files changed, 242 insertions(+), 281 deletions(-)

diff --git a/design/mvp/Binary.md b/design/mvp/Binary.md
index d8e0a88b..94b04301 100644
--- a/design/mvp/Binary.md
+++ b/design/mvp/Binary.md
@@ -87,7 +87,7 @@ sort                ::= 0x00 cs:<core:sort>                                => co
                       | 0x03                                               => type
                       | 0x04                                               => component
                       | 0x05                                               => instance
-inlineexport        ::= n:<exportname'> si:<sortidx>                       => (export n si)
+inlineexport        ::= na:<nameattributes> si:<sortidx>                   => (export na si)
 ```
 Notes:
 * Reused Core binary rules: [`core:name`], (variable-length encoded) [`core:u32`]
@@ -101,8 +101,8 @@ Notes:
   for aliases (below).
 * Validation of `core:instantiatearg` initially only allows the `instance`
   sort, but would be extended to accept other sorts as core wasm is extended.
-* Validation of `instantiate` requires each `<importname>` in `c` to match a
-  `name` in a `with` argument (compared as strings) and for the types to
+* Validation of `instantiate` requires each `<externname>` in `c` to match a
+  `name` in a `with` argument (using plain string equality) and for the types to
   match.
 * When validating `instantiate`, after each individual type-import is supplied
   via `with`, the actual type supplied is immediately substituted for all uses
@@ -201,8 +201,8 @@ defvaltype    ::= pvt:<primvaltype>                       => pvt
                 | 0x70 t:<valtype>                        => (list t)
                 | 0x67 t:<valtype> len:<u32>              => (list t len)  (if len > 0) 🔧
                 | 0x6f t*:vec(<valtype>)                  => (tuple t+)    (if |t*| > 0)
-                | 0x6e l*:vec(<label'>)                   => (flags l+)    (if 0 < |l*| <= 32)
-                | 0x6d l*:vec(<label'>)                   => (enum l+)     (if |l*| > 0)
+                | 0x6e l*:vec(<labelname>)                => (flags l+)    (if 0 < |l*| <= 32)
+                | 0x6d l*:vec(<labelname>)                => (enum l+)     (if |l*| > 0)
                 | 0x6b t:<valtype>                        => (option t)
                 | 0x6a t?:<valtype>? u?:<valtype>?        => (result t? (error u)?)
                 | 0x69 i:<typeidx>                        => (own i)
@@ -210,9 +210,9 @@ defvaltype    ::= pvt:<primvaltype>                       => pvt
                 | 0x66 t?:<valtype>?                      => (stream t?) 🔀
                 | 0x65 t?:<valtype>?                      => (future t?) 🔀
                 | 0x63 k:<valtype> v:<valtype>            => (map k v) (if k is in <keytype>) 🗺️
-labelvaltype  ::= l:<label'> t:<valtype>                  => l t
-case          ::= l:<label'> t?:<valtype>? 0x00           => (case l t?)
-label'        ::= len:<u32> l:<label>                     => l    (if len = |l|)
+labelvaltype  ::= l:<labelname> t:<valtype>               => l t
+case          ::= l:<labelname> t?:<valtype>? 0x00        => (case l t?)
+labelname     ::= len:<u32> l:<label>                     => "l"  (if len = |l|)
 <T>?          ::= 0x00                                    =>
                 | 0x01 t:<T>                              => t
 valtype       ::= i:<typeidx>                             => i
@@ -231,8 +231,8 @@ instancedecl  ::= 0x00 t:<core:type>                      => t
                 | 0x01 t:<type>                           => t
                 | 0x02 a:<alias>                          => a
                 | 0x04 ed:<exportdecl>                    => ed
-importdecl    ::= in:<importname'> ed:<externdesc>        => (import in ed)
-exportdecl    ::= en:<exportname'> ed:<externdesc>        => (export en ed)
+importdecl    ::= na:<nameattributes> ed:<externdesc>     => (import na ed)
+exportdecl    ::= na:<nameattributes> ed:<externdesc>     => (export na ed)
 externdesc    ::= 0x00 0x11 i:<core:typeidx>              => (core module (type i))
                 | 0x01 i:<typeidx>                        => (func (type i))
                 | 0x02 b:<valuebound>                     => (value b) 🪙
@@ -272,8 +272,10 @@ Notes:
   index spaces. (Note: *subsequent* aliases can introduce new type indices
   equivalent to this fresh type.)
 * Validation rejects `resourcetype` type definitions inside `componenttype` and
-  `instancettype`. Thus, handle types inside a `componenttype` can only refer
+  `instancetype`. Thus, handle types inside a `componenttype` can only refer
   to resource types that are imported or exported.
+* `<label>` is defined as part of the
+   [text format](Explainer.md#import-and-export-definitions).
 * All parameter labels, result labels, record field labels, variant case
   labels, flag labels, enum case labels, component import names, component
   export names, instance import names and instance export names must be
@@ -391,16 +393,14 @@ flags are set.
 (See [Import and Export Definitions](Explainer.md#import-and-export-definitions)
 in the explainer.)
 ```ebnf
-import         ::= in:<importname'> ed:<externdesc>                     => (import in ed)
-export         ::= en:<exportname'> si:<sortidx> ed?:<externdesc>?      => (export en si ed?)
-importname'    ::= 0x00 len:<u32> in:<importname>                       => in      (if len = |in|)
-                 | 0x01 len:<u32> in:<importname>                       => in      (if len = |in|)
-                 | 0x02 len:<u32> in:<importname> opts:vec(<nameopt>)   => in opts (if len = |in|) 🏷️/🔗
-exportname'    ::= 0x00 len:<u32> in:<exportname>                       => in      (if len = |in|)
-                 | 0x01 len:<u32> in:<exportname>                       => in      (if len = |in|)
-                 | 0x02 len:<u32> in:<importname> opts:vec(<nameopt>)   => in opts (if len = |in|) 🏷️/🔗
-nameopt        ::= 0x00 len:<u32> n:<interfacename>                     => (implements i) 🏷️
-                 | 0x01 len:<u32> vs:<semversuffix>                     => (versionsuffix vs) 🔗
+import         ::= na:<nameattributes> ed:<externdesc>                  => (import na ed)
+export         ::= na:<nameattributes> si:<sortidx> ed?:<externdesc>?   => (export na si ed?)
+nameattributes ::= 0x00 len:<u32> en:<externname>                       => "en"                 (if len = |en|)
+                 | 0x01 len:<u32> en:<externname>                       => "en"                 (if len = |en|)
+                 | 0x02 len:<u32> en:<externname> a*:vec(<attribute>)   => "en" a*              (if len = |en|) 🏷️/🔗
+attribute      ::= 0x00 len:<u32> in:<interfacename>                    => (implements "in")    (if len = |in|) 🏷️
+                 | 0x01 len:<u32> vs:<semversuffix>                     => (versionsuffix "vs") (if len = |vs|) 🔗
+                 | 0x02 n:<name>                                        => (external-id n) 🏷️
 ```
 
 Notes:
@@ -412,21 +412,26 @@ Notes:
   (which disallows core sorts other than `core module`). When the optional
   `externdesc` immediate is present, validation requires it to be a supertype
   of the inferred `externdesc` of the `sortidx`.
-* `<importname>` and `<exportname>` refer to the productions defined in the
-  [text format](Explainer.md#import-and-export-definitions).
-* `<importname'>` and `<exportname'>` will [be cleaned up for a 1.0
-  release](##binary-format-warts-to-fix-in-a-10-release).
-* The `<importname>`s of a component must all be [strongly-unique]. Separately,
-  the `<exportname>`s of a component must also all be [strongly-unique].
+* `<externname>`, `<interfacename>` and `<semversuffix>` are defined as part of
+  the [text format](Explainer.md#import-and-export-definitions).
+* The redundant `0x00`/`0x01` cases of `nameattributes` will
+  [be cleaned up for a 1.0 release](#binary-format-warts-to-fix-in-a-10-release).
+* The `externname`s of all imports in a given component or component-type must
+  be [strongly-unique]; attributes are ignored.
+* The `externname`s of all exports in a given component, instance, component-
+  type or instance-type must be [strongly-unique]; attributes are ignored.
 * Validation requires that `[constructor]`, `[method]` and `[static]` annotated
   `plainname`s only occur on `func` imports or exports and that the first label
   of a `[constructor]`, `[method]` or `[static]` matches the `plainname` of a
   preceding `resource` import or export, respectively, in the same scope
   (component, component type or instance type).
 * 🏷️ Validation requires that `implements`-annotated imports or exports are
-  `instance`-typed.
-* 🏷️ Validation requires that `implements`-annotated imports or exports have a
-  `<plainname>` name.
+  `instance`-typed and have a `plainname` name.
+* 🏷️/🔗 Validation requires that a `vec(<attribute>)` contains each kind of
+  `attribute` at most once.
+* 🏷️/🔗 Even though `componenttype` and `instancetype` structurally contain a
+  `vec(<attribute>)`, this list is entirely ignored when validating the types
+  of components and instances.
 * Validation of `[constructor]` names requires a `func` type whose result type
   is either `(own $R)` or `(result (own $R) E?)` where `$R` is a resource type
   labeled `r`.
@@ -437,8 +442,6 @@ Notes:
   the `versionsuffix` results in a `valid semver` as defined by
   [https://semver.org](https://semver.org/). A `versionsuffix` is otherwise
   ignored for validation except to improve diagnostic messages.
-* `<integrity-metadata>` is as defined by the
-  [SRI](https://www.w3.org/TR/SRI/#dfn-integrity-metadata) spec.
 
 ## 🪙 Value Definitions
 
@@ -530,12 +533,9 @@ named once.
 ## Binary Format Warts to Fix in a 1.0 Release
 
 * The opcodes (for types, canon built-ins, etc) should be re-sorted
-* The two `depname` cases should be merged into one (`dep=<...>`)
 * The two `list` type codes should be merged into one with an optional immediate
   and similarly for `func`.
-* The `0x00` and `0x01` variant of `importname'` and `exportname'` will be
-  removed. Any remaining variant(s) will be renumbered or the prefix byte will
-  be removed or repurposed.
+* The redundant `0x00` and `0x01` opcodes of `nameattributes` will be merged.
 * Most built-ins should have a `<canonopt>*` immediate instead of an ad hoc
   subset of `canonopt`s.
 * Add optional `shared` immediate to all canonical definitions (explicitly or
diff --git a/design/mvp/Explainer.md b/design/mvp/Explainer.md
index c4869747..b8637aaa 100644
--- a/design/mvp/Explainer.md
+++ b/design/mvp/Explainer.md
@@ -305,8 +305,7 @@ sort           ::= core <core:sort>
                  | type
                  | component
                  | instance
-inlineexport   ::= (export "<exportname>" <sortidx>)
-                 | (export "<exportname>" <versionsuffix> <sortidx>) 🔗
+inlineexport   ::= (export <externnamestr> <attribute>* <sortidx>)
 ```
 Because component-level function, type and instance definitions are different
 than core-level function, type and instance definitions, they are put into
@@ -581,13 +580,13 @@ defvaltype    ::= bool
                 | f32 | f64
                 | char | string
                 | error-context 📝
-                | (record (field "<label>" <valtype>)+)
-                | (variant (case "<label>" <valtype>?)+)
+                | (record (field <labelstr> <valtype>)+)
+                | (variant (case <labelstr> <valtype>?)+)
                 | (list <valtype>)
                 | (list <valtype> <u32>) 🔧
                 | (tuple <valtype>+)
-                | (flags "<label>"+)
-                | (enum "<label>"+)
+                | (flags <labelstr>+)
+                | (enum <labelstr>+)
                 | (option <valtype>)
                 | (result <valtype>? (error <valtype>)?)
                 | (map <keytype> <valtype>) 🗺️
@@ -600,7 +599,7 @@ valtype       ::= <typeidx>
 keytype       ::= bool | s8 | u8 | s16 | u16 | s32 | u32 | s64 | u64 | char | string 🗺️
 resourcetype  ::= (resource (rep i32) (dtor <core:funcidx>)?)
                 | (resource (rep i64) (dtor <core:funcidx>)?) 🐘
-functype      ::= (func async? (param "<label>" <valtype>)* (result <valtype>)?)
+functype      ::= (func async? (param <labelstr> <valtype>)* (result <valtype>)?)
 componenttype ::= (component <componentdecl>*)
 instancetype  ::= (instance <instancedecl>*)
 componentdecl ::= <importdecl>
@@ -609,10 +608,8 @@ instancedecl  ::= core-prefix(<core:type>)
                 | <type>
                 | <alias>
                 | <exportdecl>
-importdecl    ::= (import "<importname>" bind-id(<externtype>))
-                | (import "<importname>" <versionsuffix> bind-id(<externtype>)) 🔗
-exportdecl    ::= (export "<exportname>" bind-id(<externtype>))
-                | (export "<exportname>" <versionsuffix> bind-id(<externtype>)) 🔗
+importdecl    ::= (import <externnamestr> <attribute>* bind-id(<externtype>))
+exportdecl    ::= (export <externnamestr> <attribute>* bind-id(<externtype>))
 externtype    ::= (<sort> (type <u32>) )
                 | core-prefix(<core:moduletype>)
                 | <functype>
@@ -794,8 +791,8 @@ The sets of values allowed for the remaining *specialized value types* are
 defined by the following mapping:
 ```
                     (tuple <valtype>*) ↦ (record (field "𝒊" <valtype>)*) for 𝒊=0,1,...
-                    (flags "<label>"*) ↦ (record (field "<label>" bool)*)
-                     (enum "<label>"+) ↦ (variant (case "<label>")+)
+                   (flags <labelstr>*) ↦ (record (field <labelstr> bool)*)
+                    (enum <labelstr>+) ↦ (variant (case <labelstr>)+)
                     (option <valtype>) ↦ (variant (case "none") (case "some" <valtype>))
 (result <valtype>? (error <valtype>)?) ↦ (variant (case "ok" <valtype>?) (case "error" <valtype>?))
                                 string ↦ (list char)
@@ -879,8 +876,8 @@ capabilities of the component model.
 
 The `importdecl` and `exportdecl` declarators correspond to component `import`
 and `export` definitions, respectively, allowing an identifier to be bound for
-use by subsequent declarators. The definitions of `label`, `importname` and
-`exportname` are given in the [imports and exports](#import-and-export-definitions)
+use by subsequent declarators. The definitions of `labelstr`, `externnamestr`
+and `attribute` are given in the [imports and exports](#import-and-export-definitions)
 section below. Following the precedent of [`core:typeuse`], the text format
 allows both references to out-of-line type definitions (via `(type <typeidx>)`)
 and inline type expressions that the text format desugars into out-of-line type
@@ -1268,7 +1265,7 @@ produces a new local "name" for a resource type that is distinct from all
 preceding resource types. The interesting case is when resource type equality
 is considered from *outside* the component, particularly when a single
 component is instantiated multiple times. In this case, a single resource type
-definition that is exported with a single `exportname` will get a fresh type
+definition that is exported with a single name will get a fresh type
 with each component instance, with the abstract typing rules mentioned above
 ensuring that each of the component's instance's resource types are kept
 distinct. Thus, in a sense, the generativity of resource types *generalizes*
@@ -2352,11 +2349,11 @@ val      ::= false | true
            | '<core:stringchar>'
            | <core:name>
            | (record <val>+)
-           | (variant "<label>" <val>?)
+           | (variant <labelstr> <val>?)
            | (list <val>*)
            | (tuple <val>+)
-           | (flags "<label>"*)
-           | (enum "<label>")
+           | (flags <labelstr>*)
+           | (enum <labelstr>)
            | none | (some <val>)
            | ok | (ok <val>) | error | (error <val>)
            | (binary <core:datastring>)
@@ -2521,8 +2518,8 @@ of core linear memory.
 
 ### Import and Export Definitions
 
-Import and export definitions are similar to Core Webssembly import and export
-definitions, but different in a few ways.
+Import and export definitions are similar to Core WebAssembly import and export
+definitions, but different in a few ways:
 
 The first is that component-level imports have only a single name. (Two- and
 even N-level imports can be achieved by importing `instance` types).
@@ -2549,35 +2546,102 @@ exported (e.g., `(export $x "x" (func $f))` binds a new identifier `$x`).
 
 Given this, the syntax of imports and exports are defined as follows:
 ```ebnf
-import        ::= (import "<importname>" bind-id(<externtype>))
-                | (import "<importname>" <versionsuffix> bind-id(<externtype>)) 🔗
-export        ::= (export <id>? "<exportname>" <sortidx> <externtype>?)
-                | (export <id>? "<exportname>" <versionsuffix> <sortidx> <externtype>?) 🔗
-versionsuffix ::= (versionsuffix "<semversuffix>") 🔗
-```
-
-All import names must be [strongly-unique]. Separately, all export
-names must be [strongly-unique]. The rest of the grammar for
-imports and exports defines a structured syntax for the contents of import and
-export names. Syntactically, these names appear inside quoted string literals.
-The grammar thus restricts the contents of these string literals to provide
-more structured information that can be mechanically interpreted by toolchains
-and runtimes to support idiomatic developer workflows and source-language
-bindings. The rules defining this structured name syntax below are to be
-interpreted as a *lexical* grammar defining a single token and thus whitespace
-is not automatically inserted, all terminals are single-quoted, and everything
+import        ::= (import <externnamestr> <attribute>* bind-id(<externtype>))
+export        ::= (export <id>? <externnamestr> <attribute>* <sortidx> <externtype>?)
+attribute     ::= <versionsuffix> 🔗
+                | <implements> 🏷️
+                | <externalid> 🏷️
+versionsuffix ::= (versionsuffix <semversuffixstr>) 🔗
+implements    ::= (implements <interfacenamestr>) 🏷️
+externalid    ::= (external-id <string>) 🏷️
+```
+Imports and exports both have a *name* (`externnamestr`) and a list of
+*attributes* (`attribute*`). Imports always include a type (`externtype`).
+Exports always refer to a preceding definition (`sortidx`) whose type is used by
+default as the type of the export. However, this "inferred" type can be
+overridden with an optional type ascription (`externtype`) which must be
+compatible with the exported definition's type.
+
+Import and export names are used by hosts and [parent][Donut Wrapped] components
+to *identify* imports and exports. Names are expected to be bound to source
+language variable-, function- and type-names. Thus, names are required to be
+[strongly-unique] and have a more restrictive, structured syntax that provides
+bindings generators extra hints that allow more idiomatic bindings, as described
+next.
+
+In contrast, import and export attributes are not used to identify imports
+and exports and instead provide extra semantic information *about* imports and
+exports that hosts or tools can automatically interpret to determine *how* to
+supply imports and call exports. In particular:
+
+🔗 The `versionsuffix` attribute provides the minor/patch/pre-release/build
+information that was stripped from the [Canonical interface name](#-canonical-interface-name)
+so that this information can be used in error messages to reconstruct the full
+original semantic version.
+
+🏷️ The `implements` attribute indicates that an imported or exported `instance`
+implements a particular WIT interface. This enables a component to semantically
+import or export the same `interfacename` multiple times (with different names).
+For example:
+```wat
+(component
+  (import "primary" (implements "wasi:keyvalue/store") (instance ...))
+  (import "secondary" (implements "wasi:keyvalue/store") (instance ...))
+)
+```
+This ensures that imports and exports continue to have unique names (so that,
+e.g., guest code executing inside this component has distinct `primary`-
+and `secondary`-scoped names for all `wasi:keyvalue/store` operations) while
+still providing the semantic information conveyed by the `interfacename` (so
+that, e.g., hosts can implement both imports with a standard static host
+`wasi:keyvalue/store` implementation that is dynamically parameterized by the
+store names `"primary"` and `"secondary"`).
+
+🏷️ The `external-id` attribute addresses the naming-expressivity gap left
+between the restricted syntax of `externname` (shown next) and whatever
+preexisting identifier syntax a host needs. For example, in a [JavaScript
+embedding](#javascript-embedding), a [Module Specifier] can be any Unicode
+string (with URLs being a common use case) and so for components loaded via
+[ESM-integration], the `external-id` would be interpreted as the Module
+Specifier, thereby providing components the same expressivity as JavaScript
+modules. E.g.:
+```wat
+(component $ESM
+  (import "slugify"
+    (external-id "https://esm.unpkg.com/slugify@1.6.6")
+    (func (param "text" string) (result string)))
+)
+```
+Used together, `implements` and `external-id` allow a single component to, e.g.,
+import multiple `wasi:keyvalue/store`s using their platform's internal store
+naming scheme without needing to create a separate mapping or name-mangling
+scheme:
+```wat
+(component
+  (import "users"
+    (implements "wasi:keyvalue/store") (external-id "user-db-prod:region-a")
+    (instance ...))
+  (import "catalog"
+    (implements "wasi:keyvalue/store") (external-id "catalog-db-prod:region-a")
+    (instance ...))
+)
+```
+
+The following grammar defines the syntax of import and export names. Unlike all
+the other *parsing* rules in this document, the following are *lexical rules*
+for lexing individual characters into the top-level `-str` tokens that are used
+by all the other parsing rules. Thus, in the following rules, whitespace is
+*not* inserted automatically, all terminals are single-quoted and everything
 unquoted is a meta-character.
 ```ebnf
-exportname        ::= <plainname>
+externnamestr     ::= '"' <externname> '"'
+externname        ::= <plainname>
                     | <interfacename>
-importname        ::= <exportname>
-                    | <depname>
-                    | <urlname>
-                    | <hashname>
 plainname         ::= <label>
                     | '[constructor]' <label>
                     | '[method]' <label> '.' <label>
                     | '[static]' <label> '.' <label>
+labelstr          ::= '"' <label> '"'
 label             ::= <first-fragment> ( '-' <fragment> )*
 first-fragment    ::= <first-word>
                     | <first-acronym>
@@ -2587,6 +2651,7 @@ fragment          ::= <word>
                     | <acronym>
 word              ::= [0-9a-z]+
 acronym           ::= [0-9A-Z]+
+interfacenamestr  ::= '"' <interfacename> '"'
 interfacename     ::= <namespace> <words> <projection> <interfaceversion>?
                     | <namespace>+ <words> <projection>+ <interfaceversion>? 🪺
 namespace         ::= <words> ':'
@@ -2598,106 +2663,15 @@ canonversion      ::= [1-9] [0-9]* 🔗
                     | '0.' [1-9] [0-9]* 🔗
                     | '0.0.' [1-9] [0-9]* 🔗
                     | '0.0.0' 🔗
+semversuffixstr   ::= '"' <semversuffix> '"' 🔗
 semversuffix      ::= [0-9A-Za-z.+-]* 🔗
-depname           ::= 'unlocked-dep=<' <pkgnamequery> '>'
-                    | 'locked-dep=<' <pkgname> '>' ( ',' <hashname> )?
-pkgnamequery      ::= <pkgpath> <verrange>?
-pkgname           ::= <pkgpath> <pkgversion>?
-pkgversion        ::= '@' <valid semver>
-pkgpath           ::= <namespace> <words>
-                    | <namespace>+ <words> <projection>* 🪺
-verrange          ::= '@*'
-                    | '@{' <verlower> '}'
-                    | '@{' <verupper> '}'
-                    | '@{' <verlower> ' ' <verupper> '}'
-verlower          ::= '>=' <valid semver>
-verupper          ::= '<' <valid semver>
-urlname           ::= 'url=<' <nonbrackets> '>' (',' <hashname>)?
-nonbrackets       ::= [^<>]*
-hashname          ::= 'integrity=<' <integrity-metadata> '>'
-```
-Components provide six options for naming imports:
+```
+The syntax names of component imports and exports provide two options:
 * a **plain name** that leaves it up to the developer to "read the docs"
-  or otherwise figure out what to supply for the import;
-* an **interface name** that is assumed to uniquely identify a higher-level
-  semantic contract that the component is requesting an *unspecified* wasm
-  or native implementation of;
-* a **URL name** that the component is requesting be resolved to a *particular*
-  wasm implementation by [fetching] the URL.
-* a **hash name** containing a content-hash of the bytes of a *particular*
-  wasm implementation but not specifying location of the bytes.
-* a **locked dependency name** that the component is requesting be resolved via
-  some contextually-supplied registry to a *particular* wasm implementation
-  using the given hierarchical name and version; and
-* an **unlocked dependency name** that the component is requesting be resolved
-  via some contextually-supplied registry to *one of a set of possible* of wasm
-  implementations using the given hierarchical name and version range.
-
-Not all hosts are expected to support all six import naming options and, in
-general, build tools may need to wrap a to-be-deployed component with an outer
-component that only uses import names that are understood by the target host.
-For example:
-* an offline host may only implement a fixed set of interface names, requiring
-  a build tool to **bundle** URL, dependency and hash names (replacing the
-  imports with nested definitions);
-* browsers may only support plain and URL names (with plain names resolved via
-  import map or [JS API]), requiring the build process to publish or bundle
-  dependencies, converting dependency names into nested definitions or URL
-  names;
-* a production server environment may only allow deployment of components
-  importing from a fixed set of interface and locked dependency names, thereby
-  requiring all dependencies to be locked and deployed beforehand;
-* host embeddings without a direct developer interface (such as the JS API or
-  import maps) may reject all plain names, requiring the build process to
-  resolve these beforehand;
-* hosts without content-addressable storage may reject hash names (as they have
-  no way to locate the contents).
-
-The grammar and validation of URL names allows the embedded URLs to contain any
-sequence of UTF-8 characters (other than angle brackets, which are used to
-[delimit the URL]), leaving the well-formedness of the URL to be checked as
-part of the process of [parsing] the URL in preparation for [fetching] the URL.
-The [base URL] operand passed to the URL spec's parsing algorithm is determined
-by the host and may be absent, thereby disallowing relative URLs. Thus, the
-parsing and fetching of a URL import are host-defined operations that happen
-after the decoding and validation of a component, but before instantiation of
-that component.
-
-When a particular implementation is indicated via URL or dependency name,
-`importname` allows the component to additionally specify a cryptographic hash
-of the expected binary representation of the wasm implementation, reusing the
-[`integrity-metadata`] production defined by the W3C Subresource Integrity
-specification. When this hash is present, a component can express its intention
-to reuse another component or core module with the same degree of specificity
-as if the component or core module was nested directly, thereby allowing
-components to factor out common dependencies without compromising runtime
-behavior. When *only* the hash is present (in a `hashname`), the host must
-locate the contents using the hash (e.g., using an [OCI Registry]).
-
-The "registry" referred to by dependency names serves to map a hierarchical
-name and version to a particular module, component or exported definition. For
-example, in the full generality of nested namespaces and packages (🪺), in a
-registry name `a:b:c/d/e/f`, `a:b:c` traverses a path through namespaces `a`
-and `b` to a component `c` and `/d/e/f` traverses the exports of `c` (where `d`
-and `e` must be component exports but `f` can be anything). Given this abstract
-definition, a number of concrete data sources can be interpreted by developer
-tooling as "registries":
-* a live registry (perhaps accessed via [`wkg`] and the [WebAssembly OCI
-  Artifact Layout])
-* a local filesystem directory (perhaps containing vendored dependencies)
-* a fixed set of host-provided functionality (see also the [built-in modules] proposal)
-* a programmatically-created tree data structure (such as the `importObject`
-  parameter of [`WebAssembly.instantiate()`])
-
-The `valid semver` production is as defined by the [Semantic Versioning 2.0]
-spec and is meant to be interpreted according to that specification. The use of
-`valid semver` in `interfaceversion` is temporary for backward compatibility;
-see [Canonical interface name](#-canonical-interface-name) below (🔗). The
-`verrange` production embeds a minimal subset of the syntax for version ranges
-found in common package managers like `npm` and `cargo` and is meant to be
-interpreted with the same [semantics][SemVerRange]. (Mostly this
-interpretation is the usual SemVer-spec-defined ordering, but note the
-particular behavior of pre-release tags.)
+  or otherwise figure out what to do; and
+* an **interface name** that refers to a WIT interface that is defined in a
+  (🪺 possibly nested) package that is published in a (🪺 possibly nested)
+  namespace.
 
 The `plainname` production captures several language-neutral syntactic hints
 that allow bindings generators to produce more idiomatic bindings in their
@@ -2726,35 +2700,10 @@ annotations trigger additional type-validation rules (listed in
 * Similarly, an import or export named `[method]R.foo` must be a function whose
   first parameter must be `(param "self" (borrow $R))`.
 
-🏷️ When an instance import or export is named `L` and annotated with
-`(implements "I")`, it indicates that the instance implements interface `I` but
-is given the plain name `L`. This enables a component to import or export the
-same interface multiple times with different plain names. For example:
-
-```wat
-(component
-  (import "primary" (implements "wasi:keyvalue/store") (instance ...))
-  (import "secondary" (implements "wasi:keyvalue/store") (instance ...))
-)
-```
-
-Here, both imports implement `wasi:keyvalue/store` but have distinct plain
-names `primary` and `secondary`. Bindings generators can use the
-`implements` annotation to know which interface the instance implements,
-enabling them to share value type bindings across both imports. (Note that
-resource types defined in the interface, such as `bucket`, are treated as
-distinct for each import, since each may have a different implementation.)
-
-The `interfacename` also helps hosts and clients of a component. A host that
-sees `(implements "wasi:keyvalue/store>")` knows to supply a
-`wasi:keyvalue/store` implementation for that import, even though the import
-name is something else. Similarly, a client composing components can use the
-annotation to match compatible imports and exports across components.
-
-When a function's type is `async`, bindings generators are expected to
-emit whatever asynchronous language construct is appropriate (such as an
-`async` function in JS, Python or Rust). See the [concurrency explainer] for
-more details.
+The `valid semver` production is as defined by the [Semantic Versioning 2.0]
+spec and is meant to be interpreted according to that specification. The use of
+`valid semver` in `interfaceversion` is temporary for backward compatibility;
+see [Canonical interface name](#-canonical-interface-name) below (🔗).
 
 The `label` production used inside `plainname` as well as the labels of
 `record` and `variant` types must be [kebab case]. The reason for
@@ -2777,15 +2726,7 @@ Technically, based on the definitions given, the `fragment` `2` (and `3`) in
 `a1-2-3` is ambiguously either a `word` or an `acronym`, but the distinction
 only relates to casing and numbers aren't cased.
 
-Components provide two options for naming exports, symmetric to the first two
-options for naming imports:
-* a **plain name** that leaves it up to the developer to "read the docs"
-  or otherwise figure out what the export does and how to use it; and
-* an **interface name** that is assumed to uniquely identify a higher-level
-  semantic contract that the component is claiming to implement with the
-  given exported definition.
-
-As an example, the following component uses all 9 cases of imports and exports:
+As an example, the following component uses all 4 cases of imports and exports:
 ```wat
 (component
   (import "custom-hook" (func (param string) (result string)))
@@ -2794,11 +2735,6 @@ As an example, the following component uses all 9 cases of imports and exports:
     (export "response" (type $response (sub resource)))
     (export "handle" (func (param (own $request)) (result (own $response))))
   ))
-  (import "url=<https://mycdn.com/my-component.wasm>" (component ...))
-  (import "url=<./other-component.wasm>,integrity=<sha256-X9ArH3k...>" (component ...))
-  (import "locked-dep=<my-registry:sqlite@1.2.3>,integrity=<sha256-H8BRh8j...>" (component ...))
-  (import "unlocked-dep=<my-registry:imagemagick@{>=1.0.0}>" (instance ...))
-  (import "integrity=<sha256-Y3BsI4l...>" (component ...))
   ... impl
   (export "wasi:http/handler" (instance $http_handler_impl))
   (export "get-JSON" (func $get_json_impl))
@@ -2811,14 +2747,6 @@ allowing the component to request the ability to make outgoing HTTP requests
 (through imports) and receive incoming HTTP requests (through exports) in a way
 that can be mechanically interpreted by hosts and tooling.
 
-The remaining 4 imports show the different ways that a component can import
-external implementations. Here, the URL and locked dependency imports use
-`component` types, allowing this component to privately create and wire up
-instances using `instance` definitions. In contrast, the unlocked dependency
-import uses an `instance` type, anticipating a subsequent tooling step (likely
-the one that performs dependency resolution) to select, instantiate and provide
-the instance.
-
 Validation of `export` requires that all transitive uses of resource types in
 the types of exported functions or values refer to resources that were either
 imported or exported (concretely, via the type index introduced by an `import`
@@ -2870,15 +2798,15 @@ Note, that the `url` value definition is absent from the component type
 
 ### Name Uniqueness
 
-The goal of the `label`, `exportname` and `importname` productions defined and
-used above is to allow automated bindings generators to map these names into
-something more idiomatic to the language. For example, the `plainname`
-`[method]my-resource.my-method` might get mapped to a method named `myMethod`
-nested inside a class `MyResource`. To unburden bindings generators from having
-to consider pathological cases where two unique-in-the-component names get
-mapped to the same source-language identifier, Component Model validation
-imposes a stronger form of uniqueness than simple string equality on all the
-names that appear within the same scope.
+The goal of the `label` and `externname` productions defined and used above
+is to allow automated bindings generators to map these names into something more
+idiomatic to the language. For example, the name `[method]my-resource.my-method`
+might get mapped to a method named `myMethod` nested inside a class
+`MyResource`. To unburden bindings generators from having to consider
+pathological cases where two unique-in-the-component names get mapped to the
+same source-language identifier, Component Model validation imposes a stronger
+form of uniqueness than simple string equality on all the names that appear
+within the same scope.
 
 To determine whether two names (defined as sequences of [Unicode Scalar
 Values]) are **strongly-unique**:
@@ -3156,14 +3084,11 @@ the same places where modules can be loaded today, branching on the `layer`
 field in the binary format to determine whether to decode as a module or a
 component.
 
-For URL import names, the embedded URL would be used as the [Module Specifier].
-For plain names, the whole plain name would be used as the [Module Specifier]
-(and an import map would be needed to map the string to a URL). For locked and
-unlocked dependency names, ESM-integration would likely simply fail loading the
-module, requiring a bundler to map these registry-relative names to URLs.
-
-TODO: ESM-integration for interface imports and exports is still being
-worked out in detail.
+When present, the [`external-id`](#import-and-export-definitions) attribute of
+an `import` would be used as the [Module Specifier], thereby giving components
+the same naming expressivity as JavaScript (in particular, for importing URLs).
+In the absence of an `external-id`, the always-present, but syntactically-
+restrictive, `externname` of the import would be used instead.
 
 The main remaining question is how to deal with component imports having a
 single string as well as the new importable component, module and instance
@@ -3257,14 +3182,8 @@ For some use-case-focused, worked examples, see:
 [`func_invoke`]: https://webassembly.github.io/spec/core/appendix/embedding.html#mathrm-func-invoke-xref-exec-runtime-syntax-store-mathit-store-xref-exec-runtime-syntax-funcaddr-mathit-funcaddr-xref-exec-runtime-syntax-val-mathit-val-ast-xref-exec-runtime-syntax-store-mathit-store-xref-exec-runtime-syntax-val-mathit-val-ast-xref-appendix-embedding-embed-error-mathit-error
 [`func_alloc`]: https://webassembly.github.io/spec/core/appendix/embedding.html#mathrm-func-alloc-xref-exec-runtime-syntax-store-mathit-store-xref-syntax-types-syntax-functype-mathit-functype-xref-exec-runtime-syntax-hostfunc-mathit-hostfunc-xref-exec-runtime-syntax-store-mathit-store-xref-exec-runtime-syntax-funcaddr-mathit-funcaddr
 
-[`WebAssembly.instantiate()`]: https://developer.mozilla.org/en-US/docs/WebAssembly/JavaScript_interface/instantiate
 [`FinalizationRegistry`]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/FinalizationRegistry
-[Fetching]: https://fetch.spec.whatwg.org/
-[Parsing]: https://url.spec.whatwg.org/#url-parsing
-[Base URL]: https://url.spec.whatwg.org/#concept-base-url
-[`integrity-metadata`]: https://www.w3.org/TR/SRI/#the-integrity-attribute
 [Semantic Versioning 2.0]: https://semver.org/spec/v2.0.0.html
-[Delimit The URL]: https://www.rfc-editor.org/rfc/rfc3986#appendix-C
 
 [JS API]: https://webassembly.github.io/spec/js-api/index.html
 [*read the imports*]: https://webassembly.github.io/spec/js-api/index.html#read-the-imports
@@ -3286,7 +3205,6 @@ For some use-case-focused, worked examples, see:
 [JS Tuple]: https://github.com/tc39/proposal-record-tuple
 [JS Record]: https://github.com/tc39/proposal-record-tuple
 [Internal Slot]: https://tc39.es/ecma262/#sec-object-internal-methods-and-internal-slots
-[Built-in Modules]: https://github.com/tc39/proposal-built-in-modules
 
 [Kebab Case]: https://en.wikipedia.org/wiki/Letter_case#Kebab_case
 [De Bruijn Index]: https://en.wikipedia.org/wiki/De_Bruijn_index
@@ -3316,7 +3234,7 @@ For some use-case-focused, worked examples, see:
 [type-imports]: https://github.com/WebAssembly/proposal-type-imports/blob/master/proposals/type-imports/Overview.md
 [exception-handling]: https://github.com/WebAssembly/exception-handling/blob/main/proposals/exception-handling/Exceptions.md
 [stack-switching]: https://github.com/WebAssembly/stack-switching/blob/main/proposals/stack-switching/Explainer.md
-[esm-integration]: https://github.com/WebAssembly/esm-integration/tree/main/proposals/esm-integration
+[ESM-integration]: https://github.com/WebAssembly/esm-integration/tree/main/proposals/esm-integration
 [gc]: https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP.md
 [memory64]: https://github.com/webAssembly/memory64
 [`rectype`]: https://webassembly.github.io/gc/core/text/types.html#text-rectype
@@ -3396,10 +3314,6 @@ For some use-case-focused, worked examples, see:
 
 [Component Model Documentation]: https://component-model.bytecodealliance.org
 [`wizer`]: https://github.com/bytecodealliance/wizer
-[`wkg`]: https://github.com/bytecodealliance/wasm-pkg-tools
-[SemVerRange]: https://semver.npmjs.com/
-[OCI Registry]: https://github.com/opencontainers/distribution-spec
-[WebAssembly OCI Artifact Layout]: https://tag-runtime.cncf.io/wgs/wasm/deliverables/wasm-oci-artifact/
 
 [Scoping and Layering]: https://docs.google.com/presentation/d/1PSC3Q5oFsJEaYyV5lNJvVgh-SNxhySWUqZ6puyojMi8
 
diff --git a/design/mvp/WIT.md b/design/mvp/WIT.md
index b75defb1..587749d7 100644
--- a/design/mvp/WIT.md
+++ b/design/mvp/WIT.md
@@ -1011,6 +1011,7 @@ token ::= whitespace
         | keyword
         | integer
         | identifier
+        | string
 ```
 
 Whitespace and comments are ignored when parsing structures defined elsewhere
@@ -1107,6 +1108,14 @@ sequence of digits:
 integer ::= [0-9]+
 ```
 
+### Strings
+
+WIT string literals are double-quoted and use the same text format as the Core
+WebAssembly text format's [`string`] literal. For example `"a"`, `"☃︎"`, `"\7f"`
+and `"\u{7fff}"` are all `string` literals.
+
+[`string`]: https://webassembly.github.io/spec/core/text/values.html#text-string
+
 ## Top-level items
 
 A `wit` document is a sequence of items specified at the top level. These items
@@ -1428,19 +1437,32 @@ world-definition ::= export-item
                    | typedef-item
                    | include-item
 
-export-item ::= 'export' id ':' extern-type
+export-item ::= external-id? 'export' id ':' extern-type
               | 'export' use-path ';'
-import-item ::= 'import' id ':' extern-type
+import-item ::= external-id? 'import' id ':' extern-type
               | 'import' use-path ';'
 
+external-id ::= '@external-id' '(' string ')' 🏷️
+
 extern-type ::= func-type ';'
               | 'interface' '{' interface-items* '}'
               | use-path ';' 🏷️
 ```
 
-🏷️ The third case of `extern-type` allows a named interface to be imported or
-exported with a custom [plain name]. For example:
+🏷️ While `id`s are restricted to kebab-case (to enable idiomatic bindings for
+source-language identifiers), `external-id`s can be any Unicode string and can
+thus express any textual identifier needed by the "outside world" to satisfy an
+import or know how to call an export. For example, on the Web Platform, a
+component that wants to import `slugify` could target the following world:
+```wit
+world my-component {
+  @external-id("https://esm.unpkg.com/slugify@1.6.6")
+  import slugify: func(text: string) -> string;
+}
+```
 
+🏷️ The `use-path` case of `extern-type` allows a named interface to be imported
+or exported with a custom [plain name]. For example:
 ```wit
 world my-world {
     import primary: wasi:keyvalue/store;
@@ -1448,21 +1470,19 @@ world my-world {
     export my-handler: wasi:http/handler;
 }
 ```
-
-Here, `primary` and `secondary` are two distinct imports that both have the
-instance type of the `wasi:keyvalue/store` interface. The plain name of the
-import is the `id` before the colon (e.g., `primary`), not the interface name.
-This contrasts with `import wasi:keyvalue/store;` (without the `id :` prefix),
-which would create a single import using the full interface name
-`wasi:keyvalue/store`. Similarly, the export `my-handler` has the instance type
-of `wasi:http/handler` but uses the plain name `my-handler` instead of the full
-interface name, which is useful when a component wants to export the same
+Here, `primary` and `secondary` are two distinct imports that both have types
+based on the `wasi:keyvalue/store` interface. The plain name of the import is
+the `id` before the colon (e.g., `primary`), not the interface name. This
+contrasts with `import wasi:keyvalue/store;` (without the `id :` prefix), which
+would create a single import using the full interface name
+`wasi:keyvalue/store`. Similarly, the export `my-handler` has a type derived
+from `wasi:http/handler` but uses the plain name `my-handler` instead of the
+full interface name, which is useful when a component wants to export the same
 interface multiple times or simply use a more descriptive name.
 
 Note that the `use-path` form can have an ambiguity with the nested packages
 feature (🪺) where `a:b` could mean two things. To resolve this `a:b` is lexed
 as a single token instead of separate tokens, meaning:
-
 ```wit
 world w {
     import a:b;  // error: can't import a package
@@ -1470,10 +1490,19 @@ world w {
 }
 ```
 
-Note that worlds can import types and define their own types to be exported
-from the root of a component and used within functions imported and exported.
-The `interface` item here additionally defines the grammar for IDs used to refer
-to `interface` items.
+Using both of these features together, a component can import a
+`wasi:keyvalue/store` interface multiple times, using whatever platform-defined
+naming scheme so that the component can be deployed directly to the platform
+without separate configuration or runtime errors:
+```wit
+world my-world {
+    @external-id("user-db-prod:region-a")
+    import users: wasi:keyvalue/store;
+
+    @external-id("catalog-db-prod:region-a")
+    import catalog: wasi:keyvalue/store;
+}
+```
 
 [`componenttype`]: Explainer.md#type-definitions
 
@@ -1510,9 +1539,9 @@ interface-item ::= gate 'interface' id '{' interface-items* '}'
 
 interface-items ::= gate interface-definition
 
-interface-definition ::= typedef-item
-                       | use-item
-                       | func-item
+interface-definition ::= use-item
+                       | external-id? typedef-item
+                       | external-id? func-item
 
 typedef-item ::= resource-item
                | variant-items
@@ -1542,6 +1571,21 @@ source-language bindings (e.g., `async` functions in JS, Python, C# or Rust) if
 concurrency execution is desired. For more details, see the [concurrency
 explainer](Concurrency.md#summary).
 
+🏷️ As with `import`s and `export`s in worlds, and for the same use cases,
+interface items can be annotated with `@external-id`:
+```wit
+interface my-interface {
+  @external-id("foo/0")
+  foo: func() -> string;
+
+  @external-id("DB.Bar")
+  resource bar {
+    @external-id("baz/1")
+    baz: func(s: string) -> string;
+  }
+}
+```
+
 
 ## Item: `use`
 
@@ -1763,7 +1807,7 @@ desugar to an owned return value.
 Specifically, the syntax for a `resource` definition is:
 ```ebnf
 resource-item ::= 'resource' id ';'
-                | 'resource' id '{' resource-method* '}'
+                | 'resource' id '{' ( external-id? resource-method )* '}'
 resource-method ::= func-item
                   | id ':' 'static' func-type ';'
                   | 'constructor' param-list ';'
@@ -2173,7 +2217,10 @@ interface store {
 }
 
 world w {
+    @external-id("//One")
     import one: store;
+
+    @external-id("//Two")
     import two: store;
 }
 ```
@@ -2191,12 +2238,12 @@ is encoded as:
   ))
   (type (export "w") (component
     (export "local:demo/w" (component
-      (import "one" (implements "local:demo/store") (instance
+      (import "one" (implements "local:demo/store") (external-id "//One") (instance
         (export "bucket" (type $b (sub resource)))
         (export "[constructor]bucket" (func (param "name" string) (result (own $b))))
         (export "[method]bucket.get" (func (param "self" (borrow $b)) (param "key" string) (result (option string))))
       ))
-      (import "two" (implements "local:demo/store") (instance
+      (import "two" (implements "local:demo/store") (external-id "//Two") (instance
         (export "bucket" (type $b (sub resource)))
         (export "[constructor]bucket" (func (param "name" string) (result (own $b))))
         (export "[method]bucket.get" (func (param "self" (borrow $b)) (param "key" string) (result (option string))))

From b395e3728d306e4e0f50b80160493561aedcefd4 Mon Sep 17 00:00:00 2001
From: Luke Wagner <mail@lukewagner.name>
Date: Tue, 30 Jun 2026 16:10:15 -0500
Subject: [PATCH 2/3] Remove dangling depname/hashname references

---
 design/mvp/Linking.md | 13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/design/mvp/Linking.md b/design/mvp/Linking.md
index 527a3237..3d134cdf 100644
--- a/design/mvp/Linking.md
+++ b/design/mvp/Linking.md
@@ -48,10 +48,9 @@ children:
 * A parent component can **inline** its children, literally storing the child
   module or component binaries in a contiguous byte range inside the parent
   (via the `core:module` and `component` sections in the [binary format]).
-* A parent component can **import** its children, using the import name to
-  refer to modules or components stored in an external shared registry that is
-  mutually known to later stages in the deployment pipeline (specifically with
-  the [`depname`] case of `importname` in the text and binary format).
+* A parent component can **import** its children, using the import to
+  refer to external modules or components (e.g., via URL in the [`external-id`]
+  attribute of the import).
 
 Given this terminology, the following diagram shows how the different forms of
 linking can be used together in the context of C/C++:
@@ -95,8 +94,7 @@ note, even when modules or components are stored inline by earlier stages of the
 build pipeline, when creating an OCI Wasm Artifact, a toolchain can
 (hypothetically, existing tools don't do this yet) enable deduplication by
 content-hash of common modules or components by placing them in separate OCI
-[`layers`] which are imported via [`hashname`] by the root component stored in
-the first layer of the OCI Wasm Artifact.
+[`layers`] of the OCI Wasm Artifact.
 
 
 ## Higher-order Shared-Nothing Linking (aka "donut wrapping")
@@ -320,8 +318,7 @@ future features of WIT and the Component Model.)
 [Canonical ABI]: CanonicalABI.md
 [Binary Format]: Binary.md
 [WIT]: WIT.md
-[`depname`]: Explainer.md#import-and-export-definitions
-[`hashname`]: Explainer.md#import-and-export-definitions
+[`external-id`]: Explainer.md#import-and-export-definitions
 [Component Invariant]: Explainer.md#component-invariants
 [ESM-integration]: Explainer.md#esm-integration
 

From 13a795c8bf65ad655667241fb9b6c2c7b05962ba Mon Sep 17 00:00:00 2001
From: Luke Wagner <mail@lukewagner.name>
Date: Wed, 1 Jul 2026 16:39:14 -0500
Subject: [PATCH 3/3] Switch from <core:string> to <core:name>

---
 design/mvp/Explainer.md |  2 +-
 design/mvp/WIT.md       | 16 ++++++++++------
 2 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/design/mvp/Explainer.md b/design/mvp/Explainer.md
index b8637aaa..8cc81a3f 100644
--- a/design/mvp/Explainer.md
+++ b/design/mvp/Explainer.md
@@ -2553,7 +2553,7 @@ attribute     ::= <versionsuffix> 🔗
                 | <externalid> 🏷️
 versionsuffix ::= (versionsuffix <semversuffixstr>) 🔗
 implements    ::= (implements <interfacenamestr>) 🏷️
-externalid    ::= (external-id <string>) 🏷️
+externalid    ::= (external-id <name>) 🏷️
 ```
 Imports and exports both have a *name* (`externnamestr`) and a list of
 *attributes* (`attribute*`). Imports always include a type (`externtype`).
diff --git a/design/mvp/WIT.md b/design/mvp/WIT.md
index 587749d7..47b27a1d 100644
--- a/design/mvp/WIT.md
+++ b/design/mvp/WIT.md
@@ -1011,7 +1011,7 @@ token ::= whitespace
         | keyword
         | integer
         | identifier
-        | string
+        | string-literal
 ```
 
 Whitespace and comments are ignored when parsing structures defined elsewhere
@@ -1108,13 +1108,17 @@ sequence of digits:
 integer ::= [0-9]+
 ```
 
-### Strings
+### Strings Literals
 
 WIT string literals are double-quoted and use the same text format as the Core
-WebAssembly text format's [`string`] literal. For example `"a"`, `"☃︎"`, `"\7f"`
-and `"\u{7fff}"` are all `string` literals.
+WebAssembly text format's [`name`] literal. For example `"a"`, `"☃︎"`, `"\7f"`
+and `"\u{7fff}"` are all `name` literals.
 
-[`string`]: https://webassembly.github.io/spec/core/text/values.html#text-string
+```ebnf
+string-literal ::= <core:name>
+```
+
+[`name`]: https://webassembly.github.io/spec/core/text/values.html#text-name
 
 ## Top-level items
 
@@ -1442,7 +1446,7 @@ export-item ::= external-id? 'export' id ':' extern-type
 import-item ::= external-id? 'import' id ':' extern-type
               | 'import' use-path ';'
 
-external-id ::= '@external-id' '(' string ')' 🏷️
+external-id ::= '@external-id' '(' string-literal ')' 🏷️
 
 extern-type ::= func-type ';'
               | 'interface' '{' interface-items* '}'