-
Notifications
You must be signed in to change notification settings - Fork 5
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
Add support for reporting references to discontinued specs #503
Conversation
ebc048b
to
43b362f
Compare
Dry-running it gives the following output (to be compared with w3c/webref#1096) Downloading HTML spec fragments data…
Would add issues/html-discontinuedreferences.md with Repo: 'https://github.com/whatwg/html'
|
(compared to w3c/webref#1096 the report only focuses on normative references, not links in general; I think it probably is the sufficient result for actually removing the specs from webref unless I'm mistaken, although maybe informative references should be checked as well) |
w3c/browser-specs#1143 would likely lead to having more specs identified (e.g. the ones in JSON-LD) |
I would also check informative references. I'm not sure how to define sufficient result but the motivation to keep these specs in Webref right now is that removing them would break the generation of some specs. If the outdated RFCs disappear from the list of references, that should mean that the spec no longer targets sections in them. If the outdated RFCs disappear from the list of normative references but still exist in the list of informative references, the spec may still target sections in them, and thus generation will continue to fail if the spec uses Bikeshed. |
I'm not sure I would want to have strudy automatically submit issues for informative references on an ongoing basis, since in general, there may be good reasons to refer informatively to an outdated spec. We may still want to use it to automate filing issues for this particular transition though (maybe filtering it only to bikesped specs). The list generated for informative references would be: Downloading HTML spec fragments data…
Would add issues/nav-tracking-mitigations-discontinuedreferences.md with Repo: 'https://github.com/privacycg/nav-tracking-mitigations'
|
Overall, that's fine. For the sake of documenting limits of the approach:
It would make sense to exclude DNT and other hardcoded specs that we keep crawling precisely so that people can still reference them informatively.
That's a good example of a spec for which a link-based approach would trap more problems than a reference-based approach. The spec links to RFC7231 (normatively) but does not have it in its list of references. A simple link analysis would report the missing reference... and then this analysis would report the discontinued reference. Ideally, we'd manage to combine the reports!
... but that's because they turned them into definitions. |
No description provided.