See what changes are needed to support WASM Core Level 2 #1059
Comments
Merged
|
isn't it a matter of using https://webassembly.github.io/gc/core/bikeshed/ as crawled url? |
|
For the crawl of nightly versions, yes. However, the release version is not the Bikeshed version. I don't remember whether that creates a real problem during the crawl or just means that the release crawl creates mostly empty extracts. That's what I'd like to look into. |
tidoust
pushed a commit
that referenced
this issue
Sep 19, 2023
Will need to change forkOf link to wasm-core-2 once #1059 is addressed
tidoust
added a commit
that referenced
this issue
Feb 5, 2024
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
added a commit
that referenced
this issue
Feb 5, 2024
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Via #593 and #1058 (review)
The text was updated successfully, but these errors were encountered: