Subject: [Rfc-markdown] empty include files

From: Michael Richardson <[email-masked]>
Date: Sun, 12 Dec 2021 16:38:42 -0500

While working on RFC8791 (sx:structure) updates to RFC8366bis, I would up
producing a zero length file which was then included. (Why the file is zero
is yet to be determined)

When this happens, I get:

xml2rfc -q -s 'Setting consensus="true" for IETF STD document' --rfc-base-url https://www.rfc-editor.org/rfc/ --id-base-url https://datatracker.ietf.org/doc/html/ --cache=/home/mcr/.cache/xml2rfc --css=lib/v3.css --metadata-js-url=/dev/null draft-richardson-anima-rfc8366bis.xml -o draft-richardson-anima-rfc8366bis.html --html
/corp/ietf/lwork/anima/voucher/draft-richardson-anima-rfc8366bis.xml(351): Error: Expected ascii-art artwork for <artwork type="">, but found b'<artwork xmlns:xi="http://www.w3.org/2001/XInclude" name="" type="" align="left" alt="" pn="section-5.1-2">\n</artwork>\n      '...

Line 351 says:
        <artwork name="" type="" align="left" alt=""><![CDATA[
]]></artwork>

As a result of:
~~~~
{::include yang/ietf-voucher-tree-latest.txt}
~~~~

Putting some content ("HELLO") into yang/ietf-voucher-tree-latest.txt makes
xml2rfc happy.

This feels like an XML2RFC bug in that it can't cope with an empty artwork.
The diagnostics from xml2rfc seems off too, since the input doesn't have what
was provided.

But, maybe kramdown-rfc2629 is at fault for daring to include no content.

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 12 Dec 2021 22:56:30 +0100

Hi Michael.

> {::include yang/ietf-voucher-tree-latest.txt}

The kramdown-rfc part of this works as designed.

> But, maybe kramdown-rfc2629 is at fault for daring to include no content.

First of all, there is nothing wrong with the {::include} mechanism here.

Without any use of {::include}, an empty code block as in...

~~~
~~~

…will give you…

<figure><artwork><![CDATA[
]]></artwork></figure>

(Note that kramdown-rfc prepends a newline to every piece of artwork that doesn’t already start with a newline because of earlier xml2rfc idiosyncrasies; I don’t know if this is strictly necessary any more.)

Second, the definition of <artwork> [1] does not contain any text that would declare empty artwork undesirable.  It should probably rule out blank (not just empty) artwork, but it doesn’t.  In any case, kramdown-rfc gave xml2rfc what you specified it should.

Yes, there is xml2rfc behavior here that could be called a bug, but then if it silently took blank artwork that wouldn’t be too helpful either.  Kramdown-rfc does not attempt to mirror all the “helpfulness” of xml2rfc, so there you are.

Grüße, Carsten

[1]: https://xml2rfc.tools.ietf.org/xml2rfc-doc.html#name-artwork-2