Re: [rfc-i] t with indent

Am 29.12.2020 um 20:08 schrieb Eric Rescorla:
> Hi folks,
>
> In doing Auth48 for RFC8844 I noticed that each <t> block in the final
> XML seems too contain an "indent" attribute, as in:
>
>     <t indent="0" pn="section-2-5">
>
> While I see that the current v3 grammar seems to allow "indent" under
> <t>, this doesn't seem to be in draft-iab-rfc7991bis, so it's not
> quite clear what purpose it's intended for. This seems to raise two
> questions:

FWIW, it seems to be a fairly recent addition
(<https://github.com/mnot/v3grammar/commit/20ccb12dc9d4b308f025c17aa3c8dcf8dbfb0ab2>).

> First, do we really want this kind of layout-specific markup rather
> than semantic markup? Searching for <t> with indent != 0 in the
> published RFCs, I see the following cases:
>
> - RFC 8907, S. 6.2 -- a definition list nested in another definition list
>
> - RFC 8916, S. 5 -- a definition list indented under a hed (arguably
>                      another nested definition list)
>
> - RFC 8919 S 7.3 -- a set of Note: values introduced by a sentence
>                      ending in a colon
>
> - RFC 8934 S 4.2.2 -- an equation
>
> - RFC 8949 S 8 -- an equation
>
> It seems like we might be better served here by introducing some new
> semantic constructs. Both nested definition lists and equations are
> natural structures that would benefit from consistent layout (note:
> it's possible that nested definition lists already exist; it wasn't
> quite clear to me from the grammar). RFC 8919 is kind of an edge:

<dt> can contain <dl>, so yes, a definition inside a definition list can
contain another definition list.

AFAIC, the desire to tune horizonal whitespace likely comes from people
trying to optimize the text output. Something we explicitly should *not*
encourage (IMHO).

> one could probably model it as a definition list or one could just
> live with the Notes not being indented.

The example IMHO clearly should be a <blockquote> (which will get
indentation), as it cites text from the IANA registry:

>   IANA has also added the following notes to this registry:
>
>       Note: For future codepoints, in cases where the document that
>       defines the encoding is different from the document that assigns
>       the codepoint, the encoding reference MUST be to the document that
>       defines the encoding.
>
>       Note: If a link attribute can be advertised both as a sub-TLV of
>       TLVs 22, 23, 25, 141, 222, and 223 and as a sub-sub-TLV of the
>       Application-Specific Link Attributes sub-TLV defined in RFC 8919,
>       then the same numerical code should be assigned to the link
>       attribute whenever possible.

It's frustrating that the RPC did not get this right. But, IMHO, a very
good example why we should be open to fix the XML even after publication.

> Second, even assuming that <t indent=...> is a good thing, it seems
> suboptimal to have it attached to every paragraph in the XML. Is
> there a reason why it can't simply be omitted when it is set to
> the modal value of "0"?
> ...

That's a requirement for the preptool, see
<https://greenbytes.de/tech/webdav/rfc7998.html#attribute-default-value-insertion>:

"Fill in any default values for attributes on elements, except
"keepWithNext" and "keepWithPrevious" of <t>, and "toc" of <section>.
Some default values can be found in the RELAX NG schema, while others
can be found in the prose describing the elements in [RFC7991]."

(FWIW, I disagreed with that requirement)

Best regards, Julian
_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest