[rfc-i] draft-iab-xml2rfc-02 - alignment of sourcecode
paul.hoffman at vpnc.org (Paul Hoffman) Thu, 04 February 2016 21:04 UTC
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Thu, 04 Feb 2016 13:04:49 -0800
Subject: [rfc-i] draft-iab-xml2rfc-02 - alignment of sourcecode
In-Reply-To: <5A5CD370-0B7A-46F5-B0B3-13E43C85D797@att.com>
References: <56ABB36D.6030500@alum.mit.edu>
<6A914091-5ADA-4B52-B622-BF76BCC9E6FA@vpnc.org> <56B0F23B.20106@alum.mit.edu>
<6A1935EE-73F3-4F93-896B-EC86934E9863@vpnc.org> <56B12AEB.7080902@gmx.de>
<3FD398C6-A52F-4742-A819-1413B7D63809@cisco.com>
<7F501E45-8DBC-4E7A-B4AC-1F483150D5AB@att.com>
<E083E5C7-85B6-4CB5-A6DF-D30128CE05EE@vpnc.org>
<5A5CD370-0B7A-46F5-B0B3-13E43C85D797@att.com>
Message-ID: <E3670443-FCDB-412E-BD6D-618484BF4537@vpnc.org>
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
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… Paul Kyzivat
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… Paul Hoffman
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… Paul Kyzivat
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… Julian Reschke
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… HANSEN, TONY L
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… Julian Reschke
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… Paul Hoffman
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… Julian Reschke
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… Paul Kyzivat
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… Joe Hildebrand jhildebr
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… HANSEN, TONY L
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… Paul Kyzivat
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… Julian Reschke
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… Paul Hoffman
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… Paul Hoffman
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… Paul Kyzivat
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… Joe Hildebrand jhildebr
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… HANSEN, TONY L
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… Carsten Bormann
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… Paul Hoffman
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… Paul Kyzivat
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… Martin J. Dürst
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… Paul Kyzivat
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… Martin J. Dürst
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… Joe Hildebrand jhildebr
- [rfc-i] draft-iab-xml2rfc-02 - alignment of sourc… Paul Kyzivat