Re: [Rfc-markdown] Carsten: Re: [rfc-i] summary of Removing postal information from RFCs

[Carsten Bormann <[e-mail]>]

Hi Jay,


>> Any mistake I make there in kramdown-rfc leads to a show-stopper for an author, and that is exactly what kramdown-rfc is trying never to create.
> 
> I’m confused.  How is this different from the pre-v3 situation where kramdown-rfc was producing v2 and that could be rejected by xml2rfc if there was a mistake in it?

Beautiful question.

If this were steady-state situation, I could only point out that xml2rfcv1 was extremely permissive and xml2rfcv2 tried to accommodate as many of these idiosyncrasies as possible.  So writing for xml2rfcv2 was much easier to get right than for xml2rfcv3.

But that is the less interesting part of the answer.  The more interesting one is that kramdown-rfc was written at a time when RFCXML was pretty much stable.  Kramdown-rfc had a few years with a small number of users to get the bugs sorted out, including the bugs that only matter to the users.  Documents that can be processed with the 2012 version still process with the 2021 version.  That is an important characteristic that I think should be (and is!) maintained across the v2v3 transition.
Much of that transition is busywork — rewriting stuff to get the same functionality we already had.  Just with new risks.
Since xml2rfc already has a conversion mechanism that works incredibly well, it would have been less than bright not to use that mechanism instead of redoing all that work in kramdown-rfc.

Couple that with weird stuff like ascii attributes (23 of them) popping up on all kinds of elements with text content, or the rather broken content model of <li>, the <dl> regression etc. — this increases the busywork and also makes it more likely that v3 will again and again change in subtle ways to fix these rough patches.
It’s not that I didn’t start attempts to do wholesale conversions, but each time I did, I ran into one of these subtle things.  These have (mostly) been solved in --v2v3, so why not use that?

Much of the parts of v3 that aren’t just gratuitously different (or, “cleaned up”, depending on perspective) but provide new functions were easy to integrate.
Who ever uses these knows they will be get shot full of arrows (think “referencegroup”, or “svg”), so we can do some experimentation.

My objective with writing kramdown-rfc was to free myself from XML.
My objective with publishing it was to allow others to free themselves from XML.
But in both cases, we need to take co-authors with us that may not all be in “now I hate it every time I need to use XML again” territory yet.
Actually, many long-time RFC writers have serious Stockholm syndrome, and more than one collaboration that I tried to start didn’t work because of that.
So it is even more important not to create show-stoppers, because a single one of those can cause hostages to pack up and go back into the bank.

Grüße, Carsten