xml2rfc --v2v3 --add-xinclude strips CDATA, converts < > to &lt; &gt;

[mahoney@nostrum.com]

The command:

xml2rfc --v2v3 --add-xinclude <xmlfile>

can be used to covert "long-way" references (<reference anchor="RFC2119" ...) to xi:includes references (<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>).

However, if the document has artwork that contains CDATA, the CDATA is stripped, and any arrows (< >) in the artwork are converted to their XML entities (&lt; &gt;).

See:
​https://www.rfc-editor.org/v3test/draft-ietf-quic-tls-34.original.xml

​https://www.rfc-editor.org/v3test/draft-ietf-quic-tls-34.original.v2v3.xml

[mahoney@nostrum.com]

I am also seeing this behavior when I run an RPC spellchecker, newspell, which invokes rfclint:

newspell <inputfile> <outputfile>

When you tell newspell to correct a typo within <sourcecode>, newspell removes CDATA and replaces < > with &lt; &gt; in the output file. Other <sourcecode> blocks that do not have typos corrected are not impacted.

Perhaps the problem is in rfclint?

[henrik@levkowetz.com]

This is a side effect of the way the XML library (lxml) deals with CDATA. Certain transformations of the XML causes lxml to re-evaluate the whole xml content, with the result that CDATA blocks are converted to lxml's preferred rendering, which doesn't use CDATA. It might be possible to convince lxml to re-introduce CDATA blocks, but when I looked for such an option a couple of years ago I didn't find anything of that kind.

[mahoney@nostrum.com]

We are only seeing this when "xml2rfc --v2v3 --add-xinclude <xmlfile>" is run on a v3 file.

[krathnayake@ietf.org]

Fixed in [3981]:

Stop stripping CDATA with v2v3 option. Fixes #601. Commit ready for merge.

[rjsparks@nostrum.com]

Fixed in [3989]:

Merged in [3981] from ​krathnayake@ietf.org:\n Stop stripping CDATA with v2v3 option. Fixes #601.