Subject: [xml2rfc] Embedded lists in V3 syntax

From: "David R. Oran" <[email-masked]>
Date: Mon, 26 Apr 2021 14:31:35 -0400

I was trying to get an <ol> inside a <ul> and tried the obvious approach 
of just putting the <ol> after one of the <li>’s of the <ul>.

That caused xml2rfc to barf, so I went googling around, looked at the 
FAQ and RFC7991. This would seem a common-enough situation that one 
would think it covered in the documentation, but there was nothing in 
the FAQ about multi-level lists (even to say “don’t do it”).

Then I found 
https://greenbytes.de/tech/webdav/draft-hoffman-rfcexamples-latest.html#v3-basic 
and that had a list inside a list so I thought I had found a solution.

So I tried that and of course it didn’t work. On closer examination, 
the V3 source had a naked </t> without a matching <t>, so I thought - 
this can’t be right!

So, just to be sure, I extracted the xml source from the web page myself 
and tried to compile it. D’oh…it causes xml2rfc to barf.

So, I think we have a few issues/questions this raises:

1. How the heck do you embed one list inside another?
2. If this isn’t allowed, something in the FAQ ought to warn you off
3. If it is allowed, the FAQ should show you how with one or more 
examples
4. 
https://greenbytes.de/tech/webdav/draft-hoffman-rfcexamples-latest.html#v3-basic 
ought to get fixed or deprecated somehow.

DaveO

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 26 Apr 2021 20:52:25 +0200

kdrfc -3c says:

Input:

* Outer
  * Inner

Output:

      <ul spacing="normal">
        <li>
          <t>Outer
          </t>
          <ul spacing="normal">
            <li>Inner</li>
          </ul>
        </li>
      </ul>

The »spacing=“normal”« is xml2rfc v3 conversion noise.

https://xml2rfc.tools.ietf.org/xml2rfc-doc.html#name-li-2 reveals:

Content schema:
( ( artset | artwork | blockquote | dl | figure | ol | sourcecode | t | table | ul )+ 
| ( text | bcp14 | br | cref | em | eref | iref | strong | sub | sup | tt | u | xref )+ )

So a single <li> either has text (case “Inner” above) or has a mixture of block level elements (which include <t> and <ul>, case “Outer" above).

Hope that helps.

Grüße, Carsten

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 26 Apr 2021 15:30:05 -0400

Ah, light on.
I’d advocate an example in the FAQ, as none of the list examples put a 
<t> inside an <li>.

Many thanks,

On 26 Apr 2021, at 14:52, Carsten Bormann wrote:

> So a single <li> either has text (case “Inner” above) or has a 
> mixture of block level elements (which include <t> and <ul>, case 
> “Outer" above).
>
> Hope that helps.
>
> Grüße, Carsten

DaveO

---

From: Julian Reschke <[email-masked]>
Date: Tue, 27 Apr 2021 06:16:30 +0200

> the FAQ about multi-level lists (even to say “don’t do it”).

7991 is pretty clear that <ul> can only contain <li>, but that <li> can
contain <ul>. Please go back and check again :-). See in particular
<https://greenbytes.de/tech/webdav/rfc7991.html#element.ul> and
<https://greenbytes.de/tech/webdav/rfc7991.html#element.li>.

> <https://greenbytes.de/tech/webdav/draft-hoffman-rfcexamples-latest.html#v3-basic>
> So I tried that and of course it didn’t work. On closer examination, the
> V3 source had a naked </t> without a matching <t>, so I thought - this
> can’t be right!
>
>  3. If it is allowed, the FAQ should show you how with one or more examples
>  4. https://greenbytes.de/tech/webdav/draft-hoffman-rfcexamples-latest.html#v3-basic
>     <https://greenbytes.de/tech/webdav/draft-hoffman-rfcexamples-latest.html#v3-basic>

Well, that's just a copy of the latest version of Paul's document. Even
if I deleted it on my server, there'd still tons of copies of
draft-hoffman-rfcexamples-04 (and preceding drafts) somewhere else.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 27 Apr 2021 11:58:28 +0200

On 2021-04-27, at 06:16, Julian Reschke <[email-masked]> wrote:
> 7991

RFC 7991 is an important historic document, in particular since it marks the last time we actually finished a process leading up to a specification on the emerging RFCXMLv3.

However, it is often a misleading document when discussing what RFCXMLv3 is today.

I wish people in the know would stop referring to RFC 7991 (except in that historic role), and that the documentation that is accessible to RFC authors would deemphasize RFC 7991 in favor of documents that are closer to the reality of RFCXMLv3 [1].

Grüße, Carsten

[1]: https://xml2rfc.tools.ietf.org/xml2rfc-doc.html