Skip to content
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

Open
hober opened this issue May 6, 2020 · 2 comments
Open

Export terms #137

hober opened this issue May 6, 2020 · 2 comments
Assignees

Comments

@hober
Copy link
Member

hober commented May 6, 2020

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.

@tidoust
Copy link
Member

tidoust commented May 6, 2020

I believe that the problem is not with the spec itself: all IDL terms are now exported by default by ReSpec (the RemotePlayback definition in the Editor's Draft does have a data-export attribute in particular), but the TR version was published too long ago to have the appropriate attributes.

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).

@tabatkins
Copy link
Member

Ah yeah, those definitions are real wrong. The source does contain some data-dfn-type attributes, but they're wrong - RemotePlayback, for example, is marked as "dfn" type, which means you wouldn't be able to link it with {{RemotePlayback}} or have your IDL automatically link to it. (See line 1620.)

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. ^_^

tidoust added a commit to tidoust/remote-playback that referenced this issue Apr 15, 2022
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.
tidoust added a commit that referenced this issue Apr 22, 2022
* 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.
@markafoltz markafoltz self-assigned this Sep 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants