Re: [Rfc-markdown] [xml2rfc] [xml2rfc-dev] <br> is back, was: New xml2rfc release: v2.32.0

[Julian Reschke <[e-mail]>]

On 04.10.2019 21:00, Sandy Ginoza wrote:
> ... > I believe the editor used U+2028 here to avoid additional blank lines
within the quote.  This is what we get when we use <t> tags.
>
>    |  The packet PW appears as a single point-to-point link to the
>    |  client layer.  Network-layer adjacency formation and maintenance
>    |  between the client equipments will follow the normal practice
>    |  needed to support the required relationship in the client layer.
>    |
>    |  ...
>    |
>    |  This packet pseudowire is used to transport all of the required
>    |  layer 2 and layer 3 protocols between LSR1 and LSR2.
>
>
> I don’t think &br; is needed here, but see the examples below.

My first reaction was that if the citation skips a paragraph, then
having the dots on a separate line would be the right thing.
Alternatively, if text inside a paragraph was skipped, I'd use inline "
... " or " (...) ".

So I checked the source of the citation and found that the first part is
from <https://tools.ietf.org/html/rfc6658#section-3>, while the second
part is extracted from the previous section. So I would argue that this
is a strange use of <blockquote>. These should be *two* <blockquote>s.

 > ...
> a) This issue has come up quite a bit when we were trying to update lists/sublists where the authors want no whitespace between the indented items (no bullets; just a line break).  For example, RFC 8668 (v3 files not yet posted) contains the following in the v2 text:
>
>        L2 Bundle Member Attributes
>
>           Type:  25
>           Length:  Number of octets to follow
>
>        Parent L3 Neighbor Descriptor
>
>           L3 Neighbor System ID + pseudonode ID (7 octets)
>           Flags: 1-octet field of the following flags:
>
> We were able to replicate this spacing with the following XML, which seems bad because we have empty <dd/> to get the right spacing.  If there is a better way to do this, please let us know.
>
> <ul empty="true">
> <li>
> <dl spacing="compact"><dt>L3 Neighbor System ID + pseudonode ID (7 octets)
> </dt><dd></dd>
> <dt>Flags: 1-octet field of the following flags:</dt><dd></dd>
> </dl>

Well, the obvious answer is: don't. If it's not a definition list, don't
use <dl>.

In general, we really need to stop to focus on the TXT output. Bending
the vocabulary to get precisely a certain text output is the wrong path.
What's really relevant is getting proper *HTML* output.

I have my doubts that an extra blank line here is really a problem.

> b) A similar example about trying to force a line break: Is there a better way to do this?
>
> section 3 of https://www.rfc-editor.org/v3test/rfc8668_AR2.txt
> https://www.rfc-editor.org/v3test/rfc8668_AR2.xml
>
> Desired output:
>
>           L2 Bundle Member Link Local Identifiers
>           (4 * Number of L2 Bundle Member Descriptors octets)
>
> How we forced the break in XML:
>
>      <t>L2 Bundle Member Link Local Identifiers (4&nbsp;*&nbsp;Number&nbsp;of&nb\
> sp;L2&nbsp;Bundle&nbsp;Member&nbsp;Descriptors&nbsp;octets)</t>
>
> text output is good enough:
>           L2 Bundle Member Link Local Identifiers
>              (4 * Number of L2 Bundle Member Descriptors octets)

But HTML will put it onto one line is the viewport is wide enough.

> ----
> same thing as above, but with a different use of <ol>:
>
> section 3 of https://www.rfc-editor.org/v3test/rfc8668_AR4.txt
> https://www.rfc-editor.org/v3test/rfc8668_AR4.xml
>
> text output:
>        -  L2 Bundle Member Link Local Identifiers
>           (4 * Number of L2 Bundle Member Descriptors octets)

I believe the answer is the same as above. Don't. Please really consider
whether this is worth the effort. In any case: do not try to add
workarounds to get a certain plain text output. Plain text is a
secondary output format.

The point of the xml2rfc vocabulary is to markup things based on their
semantics, not based on a certain desired plain text output.

If we can't get acceptable *HTML* output, let's consider the use case
and come up with a proper solution (which might be <br/>).

> c) Re: https://www.rfc-editor.org/authors/rfc8652.html#section-5
>
> Uused two <artwork>s to get
>
> Under /rt:routing/rt:control-plane-protocols
> /rt:control-plane-protocol/igmp-mld:igmp,
>
> and
>
> Under /rt:routing/rt:control-plane-protocols
> /rt:control-plane-protocol/igmp-mld:mld,
>
> to appear w/ the (seemingly) desired line break. If it were considered running text, then <t> would be right, but there's no <br>.
> (Guess we could use <t> and a bunch of &nbsp; and &wj to prevent each 2nd line from breaking, but that seems not ideal.)

Why do these need to be on separate lines? (I don't understand the
context yet...)

> d) The most recent issue has been resolved by the adjustment of font size in the PDF, but the title of the RFC 8658 (also not yet posted) appeared ok in the .html and .txt files, but the PDF was breaking as follows:
>
> RADIUS Attributes for Softwire
> Mechanisms Based on Address plus Port (A
> +P)

If it breaks inside "A+P" instead of using the whitespace two characters
before than this looks like a bug in the formatter to me.

> It has been a struggle to convert some of these files and Henrik has been kind enough to review cases and provide input.

Understood.

I just don't think that re-introducing line breaks through the back door
is the right thing here. If they are needed, let's discuss them as as
part of the vocabulary.

(And yes, there was ample time to have this dicussion; RFC 7991 finished
three years ago).

Best regards, Julian