Add WASM Core 2 spec and phase 3+ WASM proposals #1190
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The list only contained Level 1 of WASM Core (see #1059). This adds Level 2. In practice, crawling will work fine for the Editor's Draft but Reffy will basically not extract anything from the /TR version of the spec because it does not follow usual patterns. That seems fine enough for now. This update also introduces missing WASM proposals as forks of the WASM Core or WASM JavaScript API specification. Most of the time, the title needs to be created because the actual specification remains that of the base spec. One difficulty is that the WebAssembly group approaches extensions proposals as generic WASM extensions, and not necessarily as WASM *Core* extensions or WASM *JS API* extensions, whereas we need to make a choice to set the `forkOf` property. Things look good for this batch of updates, because current proposals still seem to extend either of these specs. That may not always be the case though in the future! Similarly, the find-specs script assumed that proposals were always extending the Core spec. It now reports the URL of the home page, both to make it clearer that a choice needs to be made, and to avoid reporting a proposal that is already in the list as a WASM JS API fork. Via #1186.
tidoust
commented
Feb 5, 2024
| "url": "https://webassembly.github.io/content-security-policy/js-api/", | ||
| "forkOf": "wasm-js-api-2", | ||
| "title": "WebAssembly JavaScript Interface: Content Security Policy" | ||
| }, | ||
| { | ||
| "url": "https://webassembly.github.io/exception-handling/js-api/", | ||
| "forkOf": "wasm-js-api-2" |
There was a problem hiding this comment.
Note this one has a custom title, no need to set it ourselves in specs.json.
tidoust
commented
Feb 5, 2024
| "url": "https://www.w3.org/TR/wasm-core-1/", | ||
| "url": "https://www.w3.org/TR/wasm-core-2/", | ||
| "nightly": { | ||
| "url": "https://webassembly.github.io/spec/core/bikeshed/" |
There was a problem hiding this comment.
This is needed because the Editor's Draft link in the Level 2 spec does not target the Bikeshed rendition of the spec.
dontcallmedom
approved these changes
Feb 5, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The list only contained Level 1 of WASM Core (see #1059). This adds Level 2. In practice, crawling will work fine for the Editor's Draft but Reffy will basically not extract anything from the /TR version of the spec because it does not follow usual patterns. That seems fine enough for now.
This update also introduces missing WASM proposals as forks of the WASM Core or WASM JavaScript API specification. Most of the time, the title needs to be created because the actual specification remains that of the base spec.
One difficulty is that the WebAssembly group approaches extensions proposals as generic WASM extensions, and not necessarily as WASM Core extensions or WASM JS API extensions, whereas we need to make a choice to set the
forkOfproperty. Things look good for this batch of updates, because current proposals still seem to extend either of these specs. That may not always be the case though in the future!Similarly, the find-specs script assumed that proposals were always extending the Core spec. It now reports the URL of the home page, both to make it clearer that a choice needs to be made, and to avoid reporting a proposal that is already in the list as a WASM JS API fork.
Via #1186.