specification
specification copied to clipboard
solid
TR/2022/wac-20220705
The #change-log section includes a summary of all changes.
The key change from the previous version is that the acl link relation definition is updated based on the IANA process for registering a link relation type ( https://github.com/protocol-registries/link-relations/issues/32 ).
This PR follows based on agreement by the Editor's Team:
- https://github.com/solid/specification/blob/main/meetings/2022-03-30.md#add-solid-oidc-draft-specification-and-primer-to-solid-project
- https://github.com/solid/specification/blob/main/meetings/2022-04-27.md#solid-oidc-and-solid-oidc-primer
There is a change log as well as a link to the diff service. Commit history for a publication where the source is maintained in its own repository need not carry over to this repository IMO. I think for some contributions, that may not even be possible without reproducing revision history (possibly even across different version control systems). As you know, the source's commit history is available: https://github.com/solid/web-access-control-spec/commits/main if you want to get down to the weeds. I've considered linking to each commit in the change log but that may have been overkill or unnecessarily verbose. Figured a summary of the key changes will do, and it is common in other W3C reports. As for whether to have a single or multiple PRs for each release of a report that's maintained in another repository, I'd be in favour of keeping the process simple by not setting a requirement. I'd suspect that a single PR will suffice for most contributions while still allowing multiple PRs, e.g., there may be no changes to text content or corrections that do not affect conformance ( https://www.w3.org/2021/Process-20211102/#correction-classes ), or publication will be take place once all planned PRs are approved.
Every spec needs a version number. So that comparability future versions can be tracked. Whatever the maturity of the document. Yes it could have been a separate Pr. But I would have wanted it before this one.
@csarven :
There is a change log as well as a link to the diff service.
Ah, yes, I didn't click on that and indeed, that would have made the release so much easier!
@timbl :
Every spec needs a version number.
Absolutely! So, the semver version number can be 1.0.0-cr.1, stylized in the header as "1.0.0 Candidate Recommendation". That would be my preference.
