Subject: [rfc-i] <blockquote> within <dd>

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 27 Apr 2021 18:10:36 -0600

At https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/570 there's a
discussion about allowing <blockquote> within <dd>. Do folks here have
opinions on whether this is useful?

Peter

P.S. Yes, we need to perform a general cleanup of block and inline
elements, I've created an issue to track that at
https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/200
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 27 Apr 2021 18:30:19 -0700

> opinions on whether this is useful?

It would be useful for documents like RFC 8499 (terminology documents 
that quote earlier RFCs).

--Paul Hoffman

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 28 Apr 2021 04:12:54 +0200

> opinions on whether this is useful?

Trac is down right now, but somehow I don’t remember that ticket as a “discussion”.

Beyond the specific example Paul contributed, it is more generally useful to have a grammar that is not a maze of accidental omissions.

It is impossible to write tools operating on RFCXML if every single potential combination of elements is individually weighed as to their potential usefulness, and then possibly ruled out due do what can only be described as “proof by lack of imagination”.

Thanks for creating https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/200 — is that expired I-D now being revived and becoming the focal point where we collect RFCXMLv3 issues?

Grüße, Carsten

---

From: Roger Price <[email-masked]>
Date: Wed, 28 Apr 2021 11:18:57 +0200 (CEST)

>> opinions on whether this is useful?

Document grammars, like programming grammers should be simple and allow 
everything that is not harmful, as decided by the implementors.  The question is 
not "Is this useful?".  The question should be "Is this harmful?".

<blockquote> within <dd> will do no damage.

> .. it is more generally useful to have a grammar that is not a maze of 
> accidental omissions. It is impossible to write tools operating on RFCXML if 
> every single potential combination of elements is individually weighed as to 
> their potential usefulness, and then possibly ruled out due do what can only 
> be described as “proof by lack of imagination”.

It is not only easier to write tools, it is easier to markup texts.

Roger

---

From: Julian Reschke <[email-masked]>
Date: Wed, 28 Apr 2021 11:55:42 +0200

> Thanks for creating https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/200 — is that expired I-D now being revived and becoming the focal point where we collect RFCXMLv3 issues?

The purpose of the grammar is to describe what is valid. In theory, it
helps authoring tools to discover what the author can use.

If we don't want <sourcecode> in <abstract>, making that invalid is
exactly the right thing.

RFC 7991 was intended to describe a snapshot to assist in tools
development, to be quickly revised. If that had happened, we wouldn't
have this discussion.

Best regards, Julian

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Apr 2021 09:57:44 -0600

> Trac is down right now, but somehow I don’t remember that ticket as a “discussion”.

Thus the impetus to post to this list.

> Thanks for creating https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/200 — is that expired I-D now being revived and becoming the focal point where we collect RFCXMLv3 issues?

That is the plan. Currently the XML change management team is still
working through a large backlog of issues in both Trac and GitHub, but
we should be done with that soon and then can start updating 7991bis.

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 28 Apr 2021 18:07:06 +0200

> If we don't want <sourcecode> in <abstract>, making that invalid is

That depends on why "we don’t want" that.

If we just can’t imagine that being useful, that is the wrong reason (“proof by lack of imagination”).

If it is an editorial policy (RFC 7322 like) not to have source code in abstracts, then it depends on whether you consider that policy immutable or not.  Policy ≠ mechanism, enough said.  The place where policy is enforced should be a linter (idnits), not the formatter.

If we believe the structure of an abstracts needs to be simple to provide for wide interoperability, that is the basis a much better argument (e.g., because receiving systems might choke on source code).  I cannot imagine that being the case specifically for source code, but a more interesting example here might be math, which is not always treated well by bibliography systems.  (We can’t do math at this point except by translating it to text or SVG, but I’m sure that will change over time.)

Grüße, Carsten