Subject: [rfc-i] inline elements

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 15 Mar 2022 08:26:50 -0600

Last year I promised [1] to look into some consistency issues in the v3 
XML vocabulary (with reference to RFC 7991 and draft-iab-rfc7991bis). 
I've finally found time to do so and will divide my report into several 
threads.

For the first thread, there's the relatively simple matter of the 
"inline elements" that are used within textual elements such as <li> or 
<t> alongside running text. As far as I can see, these inline elements 
are [2] as follows:

<bcp14>
<contact> (new in 7991bis, see [3])
<cref>
<em>
<eref>
<iref>
<relref>
<strong>
<sub>
<sup>
<tt>
<u> (new in 7991bis, I can't find a good pointer for it but it's 
documented in xml2rfc and will be in the next version of 7991bis)
<xref>

Also as far as I can see, all of these inline elements can be included 
as children of the following elements (with no recursion, e.g., it's not 
allowed to include <sub> directly within <sub>):

<annotation>
<blockquote>
<cref> (see below)
<dd>
<dt>
<em>
<li>
<name>
<refcontent> (see below)
<strong>
<sub> (see below)
<sup> (see below)
<t>
<td>
<th>

There are a few anomalies:

- <cref> does not allow <bcp14> or <iref> but this might not matter 
because <cref> is intended for comments only in work-in-progress documents

- <refcontent> does not allow <cref>, <eref>, <iref>, <relref>, or 
<xref> but I suppose this makes sense because there's already a 
reference involved

- <strong> (and perhaps other elements?) does not allow <u> [4]

- <sub> does not allow <sup> and <sup> does not allow <sub> but this 
will be fixed in 7991bis [5]

The descriptive text and the Relax NG schema in 7991bis might need to be 
modified to reflect the foregoing state of things, although John Levine 
has been working on 7991bis [6] so perhaps he's ahead of us.

Corrections are welcome.

Peter

[1] https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/200

[2] The v2 vocabulary also defined <br>, <spanx>, and <vspace> but I 
believe those elements have been deprecated.

[3] https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/185

[4] https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/205

[5] https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/193

[6] https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 15 Mar 2022 15:51:22 +0100

> <relref>

This is deprecated as it has been subsumed by xref.
(There is plenty of weirdness about xref, but that is maybe for another thread; we don’t need to increase the weirdness by treating the relref subclass of xref differently.)

>  (with no recursion, e.g., it's not allowed to include <sub> directly within <sub>):

That restriction actually does not make sense at all.

Generally, I think that coming up with restrictions on the nesting based on proof by lack of imagination is not worth the confusion that this creates.

> - <cref> does not allow <bcp14> or <iref> but this might not matter because <cref> is intended for comments only in work-in-progress documents

Why make this complicated?
Just allow it.

> - <refcontent> does not allow <cref>, <eref>, <iref>, <relref>, or <xref> but I suppose this makes sense because there's already a reference involved

Not sure I follow this argument.

RFC 8949: ….  Updated, Internet Standard version of {{RFC7049}}. …

Just allow it.

> - <strong> (and perhaps other elements?) does not allow <u> [4]

Clearly a bug.

> - <sub> does not allow <sup> and <sup> does not allow <sub> but this will be fixed in 7991bis [5]

A bug as is no <sub> in <sub>.

You didn’t mention the <contact> bugs, so I didn’t even start to check for completeness of these observations.
But it is easier to fix this than to enumerate all ways in which the current behavior is a bug.

Grüße, Carsten