RE: Proposal for Publishing REC Errata

Ian and Elika

> -----Original Message-----
> From: Ian Jacobs [mailto:ij@w3.org]
> Sent: Wednesday, October 15, 2014 3:03 PM
> To: fantasai
> Cc: W3C Process Community Group
> Subject: Re: Proposal for Publishing REC Errata
> 
> Hi Fantasai,
> 
> > Proposal
> > --------
> >
> > The proposal to resolve this problem is to keep the errata inline in
> > the official REC publication. Two options make sense to me:
> >
> >  A. Write in the errata as diff marks (using <ins> and <del>) in the
> >     spec. Maintain a separate list similar to a DoC explaining
> >     the changes, and possibly also tracking the status of their tests
> >     and impls.
> >
> >  B. Fold in the errata completely into the spec text. Maintain a
> >     separate list of changes including the exact diffs from the
> >     validated REC text.
> > -------
> 
[SZ] As pointed out below, the first proposal is not very nice for accessible access (and is hard to read visually) and the second proposal makes it difficult to see the original text. Why not use a mark-up that has both the original REC text and the proposed replacement text; for example, <span class="errata"><span class="original">The REC text fragment</span><span class="replacement">The replacement text fixing the error.</span></span>. Then styling for normal access would make the "replacement" class be "display:none" and would put a yellow background (as a warning) on the "original" text. Then using either ":hover" or an explicit toggle on the "errata" <span>, the "replacement" text could be displayed to anyone that wanted to see it. This convention would, I believe, give better accessible access because instead of small fragments of insertions and deletions, the entire section that needed to be re-written would be present in two forms, either of which could be presented to the viewer.
> 
> Hi Fantasai,
> 
> I would like to see a more reader friendly approach to errata management.
> Here are a few considerations:
> 
> 1) Our process says [1], "W3C strives to make archival documents indefinitely
> available at their original address in their original form."
>     We have at least two goals:
>         a) Give readers a clear understanding of corrections.
>         b) Ensure that the original publication is still available.
> 
>    There are various ways to do that, including:
>        - Making the commit history available
>        - Using the latest version URI to get the in-place corrections, and the
> dated URI to get the original version.
> 
>  2) Wherever corrections are shown, we need to make clear (e.g., via the
> status section) that various agreements
>      (consensus process, patent policy commitments) do not extend to the
> corrections until the spec has
>      been through some formal process (whatever it is).
> 
>  3) Two more usability goals:
>      a) Make it easy to find an explanation or other information about the
> correction
>      b) Make it easy to just see the corrections (perhaps with a bit of
> surrounding context).
> 
>     Those could be satisfied in-place or by reference. One idea (I've not
> pondered deeply) is
>     an in-place solution where explanations  are made available on demand
> (hide / show explanation)
>     and where one could see the corrections without the rest of the spec.
> (There are considerations here
>     like printing and accessibility.) The in-place solution might make it easier
> to maintain the spec and its
>     corrections in one place.
> 
> There are various other details like URI-addressability of corrections,
> notification, and so on that people probably already do today with github or
> other tools.
> 
> Cheers,
> 
> Ian
> 
> [1] http://www.w3.org/2014/Process-20140801/#general-requirements
> 
> --
> Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
> Tel:                       +1 718 260 9447
> 
> 
>

Received on Thursday, 16 October 2014 00:26:54 UTC