[rfc-i] draft-iab-xml2rfc-02 - alignment of sourcecode

Paul Hoffman paul.hoffman at vpnc.org
Thu Feb 4 13:04:49 PST 2016


Thanks for the example! (PaulK, I assume that your ideas might match 
Tony's.) However, I disagree with the utility. See below.

On 4 Feb 2016, at 12:42, HANSEN, TONY L wrote:

> Without control of indentation, this would be rendered something like, 
> adding some verticalness within the paragraph to make them look 
> longer:
>
> 	The algorithm is blah blah blah. . . . It could be expressed
> 	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> 	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> 	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
>
>
> 	in python, up to the point where we decide on blah, as:
>
> 		def func(. . .):
> 		    Lots of
> 		    Code goes
> 		    Here.
> 		    if some weird blah:
>
> 	We’re now faced with what to do as blah, so we want to do such
> 	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> 	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> 	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> 	and such and yada yada yada. In python, it would look like:
>
> 			Here goes the
> 			Yada yada yada
> 			Code
>
> 	But what happens if we don’t decide on blah, then we need to
> 	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> 	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> 	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> 	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> 	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> 	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> 	consider blither and blather. In python, it would look like:
>
>
> 		    else:
> 			Blither
> 			Blather
> 			And yon
>
>
>
> In my mind, that indentation of the second block looks rather weird.

And our minds definitely differ. If someone is reading the RFC and see 
the proper indentation, they would assume that the second block is at 
the same level as the first block. For my eyes, your example is exactly 
why we *don't* want to let authors move their <sourcecode> horizontally 
in the output.

> Even better would be if we had a way to hide a <sourcecode> block. If 
> so, I could stuff the “scaffolding” code with the “else” into 
> the XML but not have it display. Then the code in the else block would 
> be displayed outdented even more. Similarly, you could hide all of the 
> “import” statements and other scaffolding that are normally needed 
> as part of source code, but it would show up within the extracted 
> code.

Let me rephrase your proposal: You want canonical RFCs with hidden 
semantic content. I would prefer that not happen.

> When I wrote one of my books many years ago, I used tricks like this 
> to have code that printed in the book well, but was also extractable 
> and directly compilable. That way every bit of code I had was fully 
> compiled and tested. I’m extrapolating from that experience into 
> xml2rfc.

And that's exactly what we have with the current draft of the v3 format.

--Paul Hoffman


More information about the rfc-interest mailing list