[rfc-i] Adding line breaks to v3 [from xml2rfc]

Julian Reschke julian.reschke at gmx.de
Mon Jun 30 12:23:04 PDT 2014


On 2014-06-30 21:06, Sean Leonard wrote:
> On 6/30/2014 11:46 AM, Julian Reschke wrote:
>> On 2014-06-30 20:30, Sean Leonard wrote:
>>> Hello, I got a request from Paul Hoffman to discuss this proposal on
>>> rfc-interest. This proposal was posted on the xml2rfc mailing list.
>>>
>>> ************************
>>>
>>>  From my experience with the current xml2rfc, there is no way (other
>>> than <vspace>) to break a line with <t> or <list> elements, such that
>>> there are no blank spaces between the resulting text blocks.
>>
>> Why is this even desirable inside paragraphs or list items?
>>
>> Can you give an example?
>> [...]
>> The HTML5 even says:
>>
>>> br elements must be used only for line breaks that are actually part
>>> of the content, as in poems or addresses.
>> Do you have any use cases like that in xml2rfc?
>
> Line breaks are an integral part of the content, as are paragraphs. They
> are ways to delimit information in a way that is stronger than a space,
> but less strong than a full paragraph break. It is like saying that
> spaces or tabs are "formatting" and not "content". Something can have

Exactly, that's what I'm saying ;-)

> formatting qualities, but still be content. Sometimes xml2rfc generates
> two spaces after a period; other times it only generates one. This is a

I'd be happy if we could get rid of this.

> formatting difference that is also an integral part of the content: two
> spaces separate sentences; one space separates things like abbreviated
> words in the same sentence (e.g., "i.e.", "etc.", etc.).
>
> You just gave two examples: poems and addresses. Poems occasionally show
> up in RFCs (sometimes they do-- RFC 1121, RFC 527--and although these
> examples may be humorous they are still part of IETF culture and ought

That sounds a bit far fetched. You could format them as artwork.

> to be respected). Addresses occur more often. Sometimes addresses are
> necessary outside of the prescribed template locations.

Which is something we should address in the vocabulary.

> The use case that motivated me to work on this was
> draft-seantek-certspec
> <https://tools.ietf.org/html/draft-seantek-certspec-03>, where I wanted
> to include multiple protocol strings in table cells, where each protocol
> string was distinct and differentiable. The cells in the left column
> have a single protocol element--thus there is a 1-to-many association. I
> suppose I could have formatted it as a list, such as:
>
> ***
> 1. 2.5.4.3
>    a. cn (CN)
>    b. commonName
> 2. 2.5.4.7
>    a. l (L)
>    b. localityName
> ***
>
> but, that would make the data run on for many pages, reducing its
> effectiveness. Additionally, it would be difficult or confusing for a
> reader to distinguish between the numbered list content and the list
> numbering at first glance. The current output of xml2rfc makes it worse:

Well, it doesn't need to be a *numbered* list...

> ***
> 1. 2.5.4.3
>
>    a. cn (CN)
>
>    b. commonName
>
> 2. 2.5.4.7
>
>    a. l (L)
>
>    b. localityName
>
> ***
>
> In contrast, a compact table can relate the same information in 4
> content lines, instead of 12:
> +----------------------------+-------------------------------+------+
>     | OID                        | Names                         | RFC  |
> +----------------------------+-------------------------------+------+
>     | 2.5.4.3                    | cn (CN)                       | 4514 |
>     |                            | commonName |      |
>     | 2.5.4.7                    | l (L)                         | 4514 |
>     |                            | localityName |      |
>
> This is a 3x savings.

I'm not convinced that saving vertical white space is a goal.

That being said, I do agree that this is an interesting table use case.

HTML tables do allow multiple <p> elements inside <tr>, so I'd expect us 
to do something similar; we'll just need to figure whether and how to 
control the amount of vertical space.

Best regards, Julian



More information about the rfc-interest mailing list