-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Export terms #137
Comments
I believe that the problem is not with the spec itself: all IDL terms are now exported by default by ReSpec (the Bikeshed does not have definitions from the RemotePlayback API in its database because that spec is not in Shepherd yet, which Bikeshed uses to build its database of terms. The current solution is to "contact the project maintainer and ask them to register your spec in Shepherd, so its definitions will be available to everyone else" (extract from Bikeshed's documentation). I'll raise that there. I'm not entirely sure that Shepherd can extract terms from an ED that uses Respec though (because it parses the source, not the processed document). |
Ah yeah, those definitions are real wrong. The source does contain some And the ED doesn't appear to have dfn attributes in the source at all. When the spec looks like it's approximately correct, I'll be happy to link it in; until then it'll just make things more confusing. ^_^ |
This update enables auto-publication of the spec as Candidate Recommendation Draft to /TR, as agreed by the working group. It leverages the [spec-prod action](https://github.com/w3c/spec-prod/) to do that. This update also adjusts the workflow for the Editor's Draft itself. The source spec is now to be found in the `main` branch, and instead of publishing the source spec to GitHub Pages directly, the spec-prod action will rather deploy the generated spec. Among other things, this makes it possible to integrate the spec in Bikeshed's database for cross-referencing purpose (fixing w3c#137). The spec-prod action also takes care of running ReSpec on pull requests to validate changes from an editorial perspective. Note the `ECHIDNA_TOKEN` was added as secret to the repository.
* Enable auto-publication of the spec to /TR This update enables auto-publication of the spec as Candidate Recommendation Draft to /TR, as agreed by the working group. It leverages the [spec-prod action](https://github.com/w3c/spec-prod/) to do that. This update also adjusts the workflow for the Editor's Draft itself. The source spec is now to be found in the `main` branch, and instead of publishing the source spec to GitHub Pages directly, the spec-prod action will rather deploy the generated spec. Among other things, this makes it possible to integrate the spec in Bikeshed's database for cross-referencing purpose (fixing #137). The spec-prod action also takes care of running ReSpec on pull requests to validate changes from an editorial perspective. Note the `ECHIDNA_TOKEN` was added as secret to the repository. * Add crEnd date to please ReSpec ReSpec requires a `crEnd` date when the spec's status is CR or CRD. It makes sense for CR (the date appears in the Status of this Document section). It does not really make sense for CRD (the date does not appear anywhere). Anyway, adding the parameter to please the ReSpec and make the auto-publication process succeed. * Fix HTML markup A `<dl>` cannot be used without `<dt>`. Switching to `<ul>` instead to contain the list of conditions. Needed to enable auto-publication since the spec-prod action validates the HTML.
I tried to autolink the RemotePlayback interface by typing
{{RemotePlayback}}
in Bikeshed, but this interface is not exported from this spec.Please consider exporting it, and the other bits of exposed API surface in the spec.
The text was updated successfully, but these errors were encountered: