Re: [Rfced-future] Welcome to the RFC Editor Future Development Program

[John C Klensin <[e-mail]>]

--On Saturday, April 4, 2020 09:32 +1300 Brian E Carpenter
<[e-mail]> wrote:

> Julian,
> On 03-Apr-20 19:59, Julian Reschke wrote:
>> On 03.04.2020 07:25, Carsten Bormann wrote:
>>> On 2020-04-03, at 06:46, Julian Reschke
>>> <[e-mail]> wrote:
>>>> 
>>>> On 03.04.2020 05:07, John R. Levine wrote:
>>>>>> During the AUTH48 period, whoever is reviewing the
>>>>>> document needs to check ALL of the formats, especially
>>>>>> around examples and figures and any non-ascii text.
>>>>> 
>>>>> Currently the RPC people are proofreading all of the
>>>>> output formats, which takes a lot of work.  I hope authors
>>>>> are also, but that's up to them. ...
>>>> 
>>>> That sounds like a bug in the process to me. And it won't
>>>> scale if we add ePub.
>>>> 
>>>> There should be *one* format that is to be proofread, HTML.
>>>> If the other output formats have an issue, that's a tooling
>>>> problem that needs to be solved, and the other formats can
>>>> be regenerated.
>>> 
>>> This doesn't work too well in an environment where the
>>> tooling is fluid, and in fact the format that the tooling
>>> works from and its interpretation is fluid as well.
>> 
>> If the tooling is that fluid (is it for HTML?), that shows
>> that we shouldn't have started the switch yet...
> 
> But we did, so that ship has sailed.
>  
>>> When the tooling has a bug (read: it uses the interpretation
>>> of 2020-04-02), and the XML is adapted to work around this
>>> bug, and the tooling is then fixed (read: it now uses the
>>> interpretation of 2020-04-03), the new output may be
>>> erroneous.
>> 
>> The (canonical, published) XML never ever should be adjusted
>> to work around a bug. Is this happening?
>  
> <heresyAlert>It should be happening. For the period during
> which v3 is in flux, we should indeed update already-published
> v3 XML files, not constantly, but on some sort of snapshot or
> checkpoint basis. Obviously we must not update the substantive
> content, and we should have an audit trail, but only by doing
> such updates can we have a reasonable situation at the end.
> 
> If there isn't a v3.n sub-version number in the XML files
> today, there certainly should be.</heresyAlert>

Agreed.  A bad solution but, given that we made the switch
while, at least retrospectively, in experimental mode, almost
certainly less bad than others.

<probably-worseHeresyAlert>
I know it is widely believed that HTML is so important in the
world and so widely used that it will survive in its current
form for centuries if not millennia, however, it is almost
certainly the least stable of the three output  forms for at
least two reasons.  First, in the circa 30 years since it
appeared, the community has already gone through five versions
and is working on a sixth (or, if you prefer, tuning the 5th).
Even more extremely, normally-sensible people are claiming that
HTML has outlived its usefulness and should be replaced by
something they (or their colleagues) have invented.  AFAICT,
none of those have gotten significant traction for more than
specific applications, but there is certainly no way to
guarantee that state will continue forever, i.e., that nothing
will come along that is actually sufficiently better that it
becomes the norm and HTML a historical legacy and artifact.   It
seems hard to be certain that whatever we do now will be easily
and compatibly rendered by whatever passes for a browser in even
75 or 100 years.  The biggest advantage of using HTML as one of
the standard output formats -- that it can be interpreted and
rendered passably well on a variety of different devices with
appropriate style sheets -- is also a risk if we consider it the
"real" format (e.g., the only one that is subject to final
("AUTH48" or whatever we call it) review, at last as long as we
care at all about presentation. It is a specification format,
not a presentation format and, even as a specification format,
it is not self-contained, depending instead on style sheets and
local conventions to precise specify presentation.   If one is
working with a document, trying to create new versions, etc.,
XML as the official/archival form is probably ok and most of us
might prefer to work with HTML or even plain text.  But, if one
is concerned about archival availability of a presentation
format, it is either the PDF/A for which proofreading and
layout-checking is important or we need to be checking all three
formats to be sure they yield plausible results.
</probably-worseHeresyAlert>