Exit criteria for a hardened specification

[littledan]

For our goals (#22), I see three independent work streams which do not need to block each other: Hardening the specification can take place in parallel with adding features to improve naming and association of source files, though the latter will benefit from the solid framework of the former.

In this issue, let's discuss what sorts of things we'd want to see from a specification before we can tell the community, "look over here, this is now the 'real' source map specification". I believe this depends on "hardening" and not on addition of features (but we can still work on both at the same time).

What I'd consider hard requirements:

• Unambiguous specification text which clarifies the questions that have been raised so far in the repository, e.g., what do columns mean, how are the URLs interpreted, etc.
• Some kind of shared tests for both source map generators and consumers
• A license ensuring that it's safe to implement and use the source maps specification
• The specification matches implementations generally, modulo bugs, and we're confident that it will make sense to report any deviations from the specification to tools authors as bugs that they should fix.

My preferences that we also get the following in place, but I don't think that these necessarily block us telling the community that they should refer to our specification:

• An inclusive process for making changes and additions going forward, on an ongoing basis, as needed
• A home in a standards body (probably TC39, or else WHATWG or W3C) which will provide backing over time for both the IPR license and the inclusive evolution process
  • I don't think going through all of the motions of full formal standardization should be a precondition to advising the community to reference our definition of source maps.