Minutes interim-2023-rswg-03: Wed 19:00
minutes-interim-2023-rswg-03-202310181900-00

RSWG Interim 18 Oct 2023

From the list:

On the call today, we want to talk about the XML. As changes are made
to the XML schema, tools will need to be updated to keep alignment. Do
we want the RFC Editor to make changes to the XML files of already
published RFCs so that the current tools can be used to generate
publication formats? Or, do we want to keep and maintain versions of
the tools that will handle each version of the XML schema.

There a many issues in this question, and we are sure that the
discussion will tease them apart.

If we are able to reach consensus on the way forward, I strongly
suspect that there will be changes needed to rfc7990-updates to
capture that consensus.

A stretch goal is to have ready-to-approve documents coming out of the
face-to-face session in Prague.

Discussion:

Eliot: View the document positively and we should go for the stretch of
having it ready in Prague.

Jay: If we added something to an RFC (not changing), can we have
multiple XML documents without replacing? Perhaps we should allow for
additional docs.

John L: There is still disagreement about the point of XML vs. rendered
versions. In addition to additional semantic content, the real reason
for XML is so that we don't have to worry about how many different
renderings we might have. Therefore we should limit changes to XML.

Robert: John says we have have to tightly couple changing the grammar
for future rfcs vs making already published rfcs match the newly defined
grammar. I would like to see incremental improvement rather than
waterfall change.

Paul: For the people who care about XML changes, if they have an easy
way to get the new one, that would suffice.

Martin: We could make changes for future RFCs or we could backport.
John's things could be done retroactively, but we don't need to have
that be possible for all new features.

Jay: It's unsustainable to do the retroactive work. We're going to have
some RFCs in different grammars. We can't keep tools forever. We don't
need to regenerate outputs.

Eliot: If we find a bug or other reason to make a change to old things,
we can do something akin to a new print number (reprinting).

Paul: Not clear what Jay meant by changing XML in a way that doesn't
change the output.

Jay: If there is no intended change to the outputs, there's no reason to
regenerate the outputs even if the XML changes.

(Interchange regarding the idea of changing the XML without changing the
PDF.)

Pete: What do we do about new pub formats? Do we have to change XML to
regenerate old RFCs? Not generate for old RFCs?

Julian: It would be bad not to be able to regenerate. Lots of experience
with bad outcomes like this. If it changes the output, we should
regenerate and attempt to make tools that verify.

John: In the short term, we would fix some mistakes, but we might not
make changes for other sorts of mistakes; we would make only backwards
compatible extensions.

Jay: Re-rendering risk is very high. Re-publishing things that don't
change is not useful. I don't think the tools are availble to verify
(e.g.) PDF changes. We should plan for the time when we don't backport.

Eliot: Do we need to re-publish all of the re-renderings? Agree with Jay
wrt risk.

Julian: Better to expose brokenness early rather than late. Therefore we
should re-publish. Regarding non-backwards-compatible changes: Biggest
changes we have made so far were lists and tables where we brought them
closer to HTML.

Paul: Disagree that the PDF change would be big risk. Not many people
use PDF, and we don't hear complaints about the existing problems in
PDF. Impacts low. We do have tools to do the verification. (For Prague,
I would like to know whether the bis document is an updates or an
obsoletes.)

Martin: Disagree with Jay's low risk tolerance. WRT Paul's Prague
question: Prefer updates with some disagreement about how to make the
changes.

Paul: Entire rewrite is worth it. (Notetaker dropout)

Eliot: Prefer obsoletes just because spread across documents is bad.