I am +1 with the content of the PR. Two editorial comments, though:

1. We should change the WG reference in the header. It should refer to the pm wg not the epub one (or has that been done in another PR)?
2. This is a class 3 change. That means that, if accepted, the change should be part of a candidate correction of the Rec, which means that the change must be clearly annotated with <ins> and <del> elements. Once all such correction are in one document, then the CC must be submitted to the AC and, once the AC is fine with the changes, the final text can be re-published. Ie, editorially, this PR isn't well prepared for that... (@plehegar did I get this right?)

which means that the change must be clearly annotated with <ins> and <del> elements.

Does it? The section you linked to says you can annotate changes inline so you don't have to get review and have them incorporated normatively right away. Aren't we incorporating these?

Section 6.3.3 only seems to say that we:

• must publicly document if other substantive changes (class 3 changes) have been made, and should document the details of such changes.
• should publicly document if editorial changes have been made, and may document the details of such changes.

If we document the change and link to its issue so you can read the github diff, is that enough?

If we document the change and link to its issue so you can read the github diff, is that enough?

That is why I solicited the opinion of @plehegar who is the final arbiter for anything process :-) I know that we had to go through this <ins>/<del> dance in the Verifiable Credential WG in the past for a similar publication. Maybe it has been streamlined since, but I simply do not know.

I think the logic is that, formally, a candidate correction is published as a Recommendation and, as such, it is a new version of the Recommendation, though still under review. Hence it is an authoritative text but with the pending changes clearly shown.

(If we had a proper and standard Web Annotation standard, we could decide to have standard annotations instead of these element tricks on the text. Oh wait...! We do have such a standard, just browsers did not implement it...)

For a class 3 change (a correction), the Working Group needs to:

• optionally republish the Recommendation with the candidate corrections identified as "candidate corrections", without modifying the normative parts of the specification.
• republish the Recommendation with the proposed corrections. This will trigger a review period, a Call for Exclusion, and an AC review. At the end of those, you will need a W3C decision to republish the Recommendation with the proposed changes fully incorporated.

From an editor's draft point of view, you can have 2 approaches:

1. you simply modify the document without identifying the changes (in other words, you modify the normative text directly). But it means that it cannot publish as-is in /TR since it will need to restore the original normative text and identify the proposed changes. This is likely to be a manual operation unfortunately.
2. you identify the proposed changes in your editor's draft and you can still publish directly in /TR.

Is this process documented somewhere? I can lift the respec markup off other specs, but it would be nice to have the process of everything that has to be done in the document spelled out.

Is this process documented somewhere? I can lift the respec markup off other specs, but it would be nice to have the process of everything that has to be done in the document spelled out.

Process for updating Recommendation is documented in several places but you should use the guide to navigate them.

you should use the guide to navigate them.

Thanks for that link @plehegar, but is the process of adding the corrections in respec documented, or going to be documented?

I stole the text/markup/classes I could find off a change to the audiobooks specification, which I think was lifted from distributed identifiers, but none of it is currently in the respec guide.

I'm not even sure if it all applies. We added a highlighted paragraph to the status section to say it contains proposed corrections, for example, but there's now a "PER" status that makes me think it's obsolete.

is the process of adding the corrections in respec documented, or going to be documented?

That's still an open issue unfortunately.

I'm not even sure if it all applies. We added a highlighted paragraph to the status section to say it contains proposed corrections, for example, but there's now a "PER" status that makes me think it's obsolete.

Proposed Edited Recommendations were removed from the Process in 2017, so I'm not sure what you are referring to.

Proposed Edited Recommendations were removed from the Process in 2017

I found it listed as supported in the Respec documentation so assumed it was new: https://respec.org/docs/#specStatus-per

This is why it gets confusing. 😕