Re: Managing candidate/proposed amendments

On 3/2/23 16:28, Dominique Hazael-Massieux wrote:
> ...
> There remain a some limitations with the system:
> * The markup and JSON changes that editors have to manage aren't always as 
> straightforward as I would want
> * The resulting diff aren't as granular as a word-for-word diff would be, and 
> in some cases can end up being pretty large, e.g.:
> 
> https://www.w3.org/TR/2023/REC-webrtc-20230301/#dictionary-rtcconfiguration-members
>    But since these diffs are completed by links with the underlying pull 
> requests, which themselves have in general a useful description of the change, 
> I think that's probably a manageable outcome.

I think this technically satisfies the requirements of the Process? Although 
indeed the "replace this block with this other block" approach does sometimes 
result in some rather large block replacements for small changes that make it 
*possible* but definitely not *easy* to understand what actually changed. :)

A few comments:
1. Use <ins> and <del> to mark up what is inserted or removed. <section> with 
id/class markup might be easy enough for the JS to understand, but it's not 
really the right markup representation.

2. Would be helpful to more clearly associate the diffs with the corrections 
they represent. There was examples of that in
   https://www.w3.org/StyleSheets/TR/2021/README#amendment
but they seem to be broken because fixup.js is returning a 404. :( :( :(

~fantasai

Received on Friday, 3 March 2023 21:10:12 UTC