[rfc-i] Containment considered harmful

Iljitsch van Beijnum iljitsch at muada.com
Sat May 26 01:42:47 PDT 2012


On 25 May 2012, at 17:51 , Joe Touch wrote:

>> Not sure what "containment" means.

> It's the difference between:

> <h2>Heading 2</H2>
> <p>This is one paragraph</p>
> <p>This is another</p>

> and

> <section>
> <h2>Heading 2</H2>
> <p>This is one paragraph</p>
> <p>This is another</p>
> </section>

Right.

I've seen a bunch of messages explaining how nice it is to have containment because that makes it easier to do certain things in code. If you write a parser from scratch, it seems plenty easy to me to find all the text between a <h2> and the next <h2> or <h1>. But that's not really all that important.

The issue is that having nested <section> and <t> elements like in XML2RFC imposes keeping track of this nesting on the author of the file. This is very hard to do for authors writing the file by hand, because people tend to forget to close a tag once in a while, which then leads to a broken document with no feedback on where in the document the problem is. This requirement also disqualifies tools that can't generate containment, which I assume will be the vast majority of word processors and HTML editors. This means one of the goals of a new format, making it easier to write drafts and RFCs, will not be met for the foreseeable future.

So: there MUST NOT be a containment requirement in the I-D / RFC submission format. If people find it useful to have containment in RFCs, then this should be added during the publication process, but not before. (This means that tools making use of this would work on RFCs but not drafts.) Containment also MUST NOT be optional in I-Ds, because that way, re-editing a draft will still lead to brokennes.


More information about the rfc-interest mailing list