Expose TR/ED URLs #11
Milestone
Comments
tidoust
added a commit
to tidoust/browser-specs
that referenced
this issue
Mar 31, 2020
This update adds the logic needed to complete specification metadata with the spec's title (w3c#10) and the TR/ED URLs (w3c#11). This additional information gets fetched from the W3C API when possible, from Specref when the W3C API does not know anything about the spec, or from the spec itself when neither the W3C API nor Specref knows anything about the spec. Fetching logic is in `src/fetch-info.js`. By definition, fetching this information requires sending network requests and, as such, cannot be done in realtime on hundreds of specs. Instead, the commit adds a GitHub action set to run every 6 hours to fetch the information and update the `specs-info.json` file. In turn, this file is imported by the `index.js` script, which now also returns the information. New properties returned for each specification are: - `title`: the title of the spec - `trUrl`: the URL of the TR document for specs published in TR space - `edUrl`: the URL of the latest Editor's Draft when known - `source`: one of `w3c`, `specref`, or `spec` to give the source of the info Other updates: - Refactored JSON schemas in a schema folder with a common `dfns.json` file to avoid duplicating type definitions. - Extended the filtering logic in `index.js` to also look for titles, source, and URLs. Note that the code and the tests now expect to find a `config.json` file in the root folder that contains an object with a `w3cApiKey` property set to a valid W3C API key (this file is *not* part of the commit). Also note that tests current fail if one tries to add a new spec to `specs.json` and does not run `npm run fetch-info`, because the new spec won't have a `title` property, which is defined as `required` in the JSON schema. This means that updates to `specs-info.json` need to be part of pull requests on the repo. Depending on the envisioned workflow for updates (and packaging), we might want to relax that rule later on.
tidoust
added a commit
that referenced
this issue
Apr 1, 2020
This update adds the logic needed to complete specification metadata with the spec's title (#10) and the TR/ED URLs (#11). This additional information gets fetched from the W3C API when possible, from Specref when the W3C API does not know anything about the spec, or from the spec itself when neither the W3C API nor Specref knows anything about the spec. Fetching logic is in `src/fetch-info.js`. By definition, fetching this information requires sending network requests and, as such, cannot be done in realtime on hundreds of specs. Instead, the commit adds a GitHub action set to run every 6 hours to fetch the information and update the `specs-info.json` file. In turn, this file is imported by the `index.js` script, which now also returns the information. New properties returned for each specification are: - `title`: the title of the spec - `trUrl`: the URL of the TR document for specs published in TR space - `edUrl`: the URL of the latest Editor's Draft when known - `source`: one of `w3c`, `specref`, or `spec` to give the source of the info Other updates: - Refactored JSON schemas in a schema folder with a common `definitions.json` file to avoid duplicating type definitions. - Extended the filtering logic in `index.js` to also look for titles, source, and URLs. Also note that tests current fail if one tries to add a new spec to `specs.json` and does not run `npm run fetch-info`, because the new spec won't have a `title` property, which is defined as `required` in the JSON schema. This means that updates to `specs-info.json` need to be part of pull requests on the repo. Depending on the envisioned workflow for updates (and packaging), we might want to relax that rule later on. Note that the code and the tests now expect to find a `config.json` file in the root folder that contains an object with a `w3cApiKey` property set to a valid W3C API key (this file is *not* part of the commit). Tests that require an API key are separate from tests that don't require one, and not automatically run on pull requests (which may come from forks and which do not have access to repo secrets).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Most specs that are not "living standards" come into two variants: a spec in TR, and an Editor's Draft. Both are useful to track.
The TR URL should be the starting point for all specs that are published as TR documents.
Rules to determine the URL of an Editor's Draft:
Alternatively, we could perhaps start from the
nameof a spec and look it up in the W3C API, then in Specref. Problem is we would still have to use the URL for new specs that these systems won't know anything about.The text was updated successfully, but these errors were encountered: