(Originally brought up by @guybedford in #67.) In [the reference implementation so far](https://github.com/domenic/import-maps/blob/e4dd5e3b070ca5bd56bf65bfa01085045207a52c/reference-implementation/lib/import-maps.js) (see also [tests](https://github.com/domenic/import-maps/tree/master/reference-implementation/__tests__)), parsing is forgiving in several cases: 1. Top-level entries besides `"imports"` or `"scopes"` are ignored. 2. Addresses that are not strings, null, or an array cause the corresponding map entry to be ignored. 3. Empty string specifier keys cause the corresponding map entry to be ignored. 4. If an address is an array, members that are not strings are ignored. 5. String addresses that are not absolute URLs with fetch schemes, relative-URL-like, or built-in module specifiers are ignored. 6. Unparseable scope prefix URLs, or scope prefix URLs with non-fetch schemes, are ignored. Note that "ignored" does not preclude "shows a warning in the developer console"; it just means "does not cause the entire map to be rejected". Should we turn any of these cases into hard failures, that cause the entire map to be rejected? My reasoning is that soft failures are more future-extensible. For example, if we introduce a new top-level key for some optional nice feature, it would be unfortunate if using it caused your import map to be completely rejected in browsers that haven't yet implemented that feature. Similarly if we introduce an address format that's an object, or we introduce a new URL scheme, or we start allowing non-built-in module specifiers as addresses. Does anyone want to make an argument for hard failure, in any of those six cases? If so, let's discuss. If not, we can consider this issue closed when I've added committed documentation with reasoning and plausible example cases for each of the above soft failures. Eventually that documentation would go into the spec.