Bug in the online XML2RFC HTML output

[hassanakbar4]

component_Version 2 cli resolution_overtaken by events type_defect | by worley@ariadne.com

---

I have an XML2RFC XML file which produces incorrect HTML using the online XML2RFC tool.

To reproduce it:

1. Create an empty directory.
2. In that directory, obtain these files from a Subversion repository: $ svn co -r 5437 http://svn.resiprocate.org/rep/ietf-drafts/worley or, obtain the attached file.
3. Put worley/draft-worley-alert-info-fsm-02.xml through http://xml2rfc.tools.ietf.org/ to generate draft-worley-alert-info-fsm-02.{txt,html} (replacing the files that you have checked out)

Examine section 2 of draft-worley-alert-info-fsm-02.txt: It shows text properly interspersed with a sequence of figures. Examine section 2 of draft-worley-alert-info-fsm-02.html: The text is not properly interspersed with the figures.

---

Issue migrated from trac:318 at 2021-10-20 18:23:01 +0500

[hassanakbar4]

@{"email"=>"worley@ariadne.com", "name"=>nil, "username"=>nil} uploaded file draft-worley-alert-info-fsm-02.xml (68.2 KiB)

Input to XML2RFC.

[hassanakbar4]

@{"email"=>"worley@ariadne.com", "name"=>nil, "username"=>nil} commented

---

Here's another instance of the problem: The third paragraph of section 4 of the HTML output generated for https://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-dual-stack-08.xml

It appears that the error works in this way: When the paragraph has this structure:

  <t>For example, consider a server with DNS name example.com, with TCP
  transport specified.  The relevant SRV records for example.com are:
  <list style="empty"><t>
  [items]
  </t></list>
  The processing of <xref target="RFC2782"/> results in this
  ordered list of target domain names:
  <list style="empty"><t>
  [items]
  </t></list>
  The address records for sip-1.example.com, as ordered by <xref target="RFC6724"/>, are
  <list style="empty"><t>
  [items]
  </t></list>
  and the address records for sip-2.example.com, as ordered by
  <xref target="RFC6724"/>, are:
  </t>

the text output is correct. But the HTML structure is incorrect; it has the correct sequence of running text sections and lists, but the running text is placed into the running text sections incorrectly. Each of the latter running text sections is broken into two parts, where the part before the element is placed correctly, but the and the following text is appended to the first running text section. The output has this structure:

  <t>For example, consider a server with DNS name example.com, with TCP
  transport specified.  The relevant SRV records for example.com are:
  [RFC2782] results in this ordered list of target domain names:
  [RFC6724], are [RFC6724], are:

  [items]

  The processing of

  [items]

  The address records for sip-1.example.com, as ordered by

  [items]

  and the address records for sip-2.example.com, as ordered by

[hassanakbar4]

@{"email"=>"worley@ariadne.com", "name"=>nil, "username"=>nil} commented

---

It looks like this is the fix:

diff -u xml2rfc/writers/html.py.orig xml2rfc/writers/html.py
--- xml2rfc/writers/html.py.orig    2015-05-18 14:13:43.000000000 -0400
+++ xml2rfc/writers/html.py 2016-08-24 06:31:04.235958917 -0400
@@ -412,8 +412,12 @@
                     br.tail = child.tail
             elif child.tag == 'list':
                 self.write_list(child, parent, level=level)
+                # Having appended child(ren) to the parent, we must append a new
+                # E.P() child in which to place any further text in the <t>.
+                current = E.P()
+                parent.append(current)
                 if child.tail:
-                    parent.append(E.P(child.tail))
+                    current.text = child.tail
             elif child.tag == 'figure':
                 # Callback to base writer method
                 self.write_figure(child)

This could create empty E.P() elements where there weren't any before. (I.e., after a in a , which is not followed by further running text.) I haven't checked into the consequences of this, though I can guess at three solutions:

1) It's the user's problem. The user created a within a , and can expect formatting anomalies. The previous code could create an empty E.P() before the if there is no running text in the before the . OTOH, that case is uncommon, whereas the case of no running text after in is more common.

2) If an empty E.P() generates "

", assume that the browser will treat it as a no-op.

3) Have the serialization process ("self.buf.append(self._flush_temp_div())") explicitly ignore empty E.P() elements. It may already do this; I haven't checked.