- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sun, 7 Nov 2021 19:40:32 -0500
- To: spec-prod@w3.org
On 11/7/21 6:48 PM, Marcos Caceres wrote: > Very few of us have had the opportunity to update a REC, but it's > something that will become increasingly common (i.e., few of us have > experience with this so a lot of us a fumbling our way through it). Since sending that email, I believe I've successfully been able to put something together that's going to be published on Nov 9th 2021 as an REC with Proposed Corrections. It was hella-painful to put together... 12 hours of manual copy-pasting between an htmldiff to the old rec, creating custom anchors, batching changesets together, and other manual markup. It took three entire attempts just to understand what the Team wanted (through no fault of theirs) because the process was so foreign from what existed before. Some more thoughts below... > On the ReSpec side, we only have a bug filed: > https://github.com/w3c/respec/issues/3809 Ok, I'll take the conversation there, thanks. My biggest concern is that I don't know how to get Editors out of the critical path for marking up candidate corrections/candidate additions/proposed corrections/proposed additions. During Verifiable Credentials v1.1, the WG members provided multiple proposed corrections. None of us knew at the time that we needed to mark these up in any special way, and so two years of these built up. Luckily, that only resulted in like 3 proposed corrections... but one of them was a change from RFC3339 datetime to XMLSCHEMA11-2 datetime, which rippled throughout the entire spec. Again, that wasn't /that/ bad... but woe to the WG that needs to search/replace a normative dependency throughout the specification. We did end up marking all of those PRs with "substantive" github labels, so perhaps Editors just need to be put on notice that any block-level element that contains changes needs to be expanded to contain the old text and the new text? If that's done, then ReSpec can generate the diff between the old text and the new text... and once the corrections are out, the Editors have to go back through the document and delete all the old text? Feels error prone... to the point where it might just be better to do a full diff of the file. I get that people want to get fancy, but the burden on the Editors is high and the possibility of error (when doing the cleanup) is pretty high as well. I'll put these thoughts in the issue. -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. News: Digital Bazaar Announces New Case Studies (2021) https://www.digitalbazaar.com/
Received on Monday, 8 November 2021 00:40:49 UTC