Subject: Re: [xml2rfc] #318 (Version 2 cli): Bug in the online XML2RFC HTML output

From: "xml2rfc issue tracker" <[email-masked]>
Date: Mon, 22 Aug 2016 20:23:19 -0000

#318: Bug in the online XML2RFC HTML output

Comment (by [email-masked]):

 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 <xref> element is placed correctly, but the <xref> 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

-- 
---------------------------------+----------------------------------
  Reporter:  [email-masked]  |      Owner:  [email-masked]
      Type:  defect              |     Status:  new
  Priority:  medium              |  Milestone:
 Component:  Version 2 cli       |    Version:  2.5.x
Resolution:                      |   Keywords:
---------------------------------+----------------------------------

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/318#comment:1>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 22 Aug 2016 16:49:27 -0400

Is there any hope I can get someone to look at issue 318 fairly soon?
We have a draft in IESG review that trips this bug (bad HTML output) and
I'd like to have it fixed in time for its publication.

I've managed to characterize the problem fairly closely; see the latest
comment on the issue.

Thanks,

Dale

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 22 Aug 2016 23:12:15 +0200

Hi Dale,

> I've managed to characterize the problem fairly closely; see the latest

I should be able to work on this end of next week.  There are a few other
important fixes needed for xml2rfc, too.  So say I'd say there's hope for
a fix in about 2 weeks.

Best regards,

	Henrik

---

From: Jim Schaad <[email-masked]>
Date: Mon, 22 Aug 2016 14:13:53 -0700

I have started looking at these issues and expect to have fixes for review
in the next month or so.

Jim

> -----Original Message-----
> From: xml2rfc [mailto:[email-masked]] On Behalf Of Dale R.
Worley
> Sent: Monday, August 22, 2016 1:49 PM
> To: [email-masked]
> Subject: [xml2rfc] XML2RFC issue #318
> 
I'd like
> to have it fixed in time for its publication.
> 
comment
> on the issue.
> 
> Thanks,
> 
> Dale
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc

---

From: Julian Reschke <[email-masked]>
Date: Tue, 23 Aug 2016 12:06:23 +0200

> I've managed to characterize the problem fairly closely; see the latest

You can always choose a different tool to produce the HTML 
(https://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html).

Best regards, Julian

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 23 Aug 2016 12:00:15 -0400

> important fixes needed for xml2rfc, too.  So say I'd say there's hope for

Ah, that would be great!

Dale

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Wed, 24 Aug 2016 10:40:58 -0000

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 <list> in a <t>, 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 <list> within a <t>, and
 can expect formatting anomalies.  The previous code could create an empty
 E.P() before the <list> if there is no running text in the <t> before the
 <list>.  OTOH, that case is uncommon, whereas the case of no running text
 after <list> in <t> is more common.

 2) If an empty E.P() generates "<p></p>", 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.

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/318#comment:2>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>