Subject: [xml2rfc-dev] <contact> element in <t>

From: "Martin Thomson" <[email-masked]>
Date: Wed, 11 Dec 2019 12:13:20 +1100

Hi Henrik,

I just tested this new element out in xml2rfc 2.37.0.  I think that there are some bugs to work out.

I have the following input (in reduced form):

<t>The following people helped:
... (ascii names) ...,
<contact fullname="Mirja Kühlewind"/>,
...
<contact asciiFullname="Kazuho Oku" fullname="?"/>,
...
</t>

I don't have Kazuho's real name just yet, so I just added "?" for the moment.

What I have observed is that the output includes many additional line breaks.  If I get this right, this is producing a new paragraph break for the name included in <contact>.  That's not expected.

It also appears to remove the "?" I'm using as a placeholder in this example.  I can put some Unicode in fullname (for instance, "øøø" works fine), but the Japanese text I copied from somewhere failed.

fullname="投稿者" causes xml2rfc to choke:

  File "/home/martin/bin/xml2rfc", line 11, in <module>
    load_entry_point('xml2rfc==2.37.0', 'console_scripts', 'xml2rfc')()
  File "/home/martin/.local/lib/python3.8/site-packages/xml2rfc/run.py", line 590, in main
    writer.write(filename)
  File "/home/martin/.local/lib/python3.8/site-packages/xml2rfc/writers/text.py", line 274, in write
    lines = self.paginate(lines)
  File "/home/martin/.local/lib/python3.8/site-packages/xml2rfc/writers/text.py", line 412, in paginate
    paginated[i].elem.page = page
AttributeError: 'lxml.etree._Element' object has no attribute 'page'

I thought that that specific error might be due to placement, but moving the text around didn't help.

Cheers,
Martin

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 11 Dec 2019 02:39:10 +0100

Hi Martin,

On 2019-12-11 02:13, Martin Thomson wrote:
> What I have observed is that the output includes many additional line
> breaks. If I get this right, this is producing a new paragraph break
> for the name included in <contact>. That's not expected.

No, and I haven't seen this here in my tests.  Could you send your XML?

> It also appears to remove the "?" I'm using as a placeholder in this
> example. I can put some Unicode in fullname (for instance, "øøø"
> works fine), but the Japanese text I copied from somewhere failed.
> 

Interesting.  I haven't seen this in my tests either.  I used Georgian
Mkhedruli though, not Japanese Kanji.  I'll try that tomorrow, fix, and do a
bugfix release.  I see this is related to pagination, so again your XML file
might help debug this.

	Henrik

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 11 Dec 2019 13:16:32 +1100

The XML in question is produced from kramdown, but you can see the input here:

https://github.com/quicwg/base-drafts/compare/contributors?expand=1

This expands into pretty much what you see below.

On Wed, Dec 11, 2019, at 12:39, Henrik Levkowetz wrote:
> Attachments:
> * signature.asc

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 11 Dec 2019 08:17:57 +0100

Hi Martin,

> This expands into pretty much what you see below.

I'm afraid that's not too helpful -- it really would make a difference
if you could pull out the XML file which exhibits the problem and send
it to me.

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Dec 2019 08:33:10 +0100

I did some tests too, and have a few suggestions/questions/issues...

1) I believe that when <contact> appears at block level, it should be
counted as paragraph (so it would affect internal numbering), and
probably also get a "self" link.

2) For similar reasons, it should support @anchor.

3) It should be clarified what can be used in phrase level, and how the
name that is displayed is computed.

3a) What combinations of fullname, initials, and surname are allowed?
The current validation appears to use the same rules as for the
block-level case, but that's incorrect as long as <orgnization> is ignored.

3b) Should <organization> be used (I believe it should, but currently
it's not)

3c) Should presence of ignored child elements (<address>) lead to a
warning (I believe it should).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Dec 2019 08:40:04 +0100

> if you could pull out the XML file which exhibits the problem and send

I just did that (see off-list mail).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Dec 2019 08:43:16 +0100

I just had a look, and the MD expands to:

>
> <t>The original design and rationale behind this protocol draw significantly from
> work by Jim Roskind <xref target="EARLY-DESIGN"/>.</t>
>
> <t>The IETF QUIC Working Group received an enormous amount of support from many
> people. The following people provided substantive contributions:
> Alessandro Ghedini,
> Alyssa Wilk,
> Antoine Delignat-Lavaud,
> Brian Trammell,
> Christian Huitema,
> Colin Perkins,
> David Schinazi,
> Dmitri Tikhonov,
> Eric Kinnear,
> Eric Rescorla,
> Gorry Fairhurst,
> Ian Swett,
> Igor Lubashev,</t>
> <contact asciiFullname="Kazuho Oku" fullname="Kazuho's real name" />
> <t>,
> Lucas Pardue,
> Magnus Westerlund,
> Marten Seemann,
> Martin Duke,
> Mike Bishop,</t>
> <contact fullname="Mikkel Fahnøe Jørgensen" />
> <t>,</t>
> <contact fullname="Mirja Kühlewind" />
> <t>,
> Nick Banks,
> Nick Harper,
> Patrick McManus,
> Roberto Peon,
> Ryan Hamilton,
> Subodh Iyengar,</t>
> <contact asciiFullname="Tatsuhiro Tsujikawa" fullname="xxx" />
> <t>,
> Ted Hardie,
> Tom Jones,
> and Victor Vasiliev.</t>
>
> </section>

So <contact> appears as block level element, and xml2rfc indeed works as
intended.

Best regards, Julian

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 11 Dec 2019 19:24:32 +1100

> I just had a look, and the MD expands to:
[...]
> > <contact asciiFullname="Tatsuhiro Tsujikawa" fullname="xxx" />

Huh.  That's kramdown-rfc2629 doing that.  It didn't do the same to <u>, so I expected it to handle this the same way...  Odd.

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 11 Dec 2019 19:34:18 +1100

On Wed, Dec 11, 2019, at 19:24, Martin Thomson wrote:
> Huh.  That's kramdown-rfc2629 doing that.  It didn't do the same to 
> <u>, so I expected it to handle this the same way...  Odd.

OK, I looked into this.  kramdown itself understands <u> to be an inline element (despite it not being an HTML element).  The way that works is that it lists inline elements and block elements by name.

So having <contact> as both a block-level and inline-level element would complicate implementation of this for kramdown-rfc2629.  I'm sure that Carsten is smarter than me about this sort of thing, so there might be a solution, but I would suggest looking for a simpler solution.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Dec 2019 09:54:47 +0100

On Dec 11, 2019, at 09:34, Martin Thomson <[email-masked]> wrote:
> 
> I'm sure that Carsten is smarter than me about this sort of thing

Not sure about that :-), but a quick workaround is to not start the <contact> in column 1:

Ian Swett,
Igor Lubashev, <contact asciiFullname="Kazuho Oku" fullname="Kazuho's real name"/>,
Lucas Pardue,

I’m currently at a loss why <u> does not need this workaround.

Grüße, Carsten

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 11 Dec 2019 20:09:01 +1100

> I’m currently at a loss why <u> does not need this workaround.

I was wrong before, <u> is an inline element: https://html.spec.whatwg.org/#the-u-element

kramdown understands that via Kramdown::Parser::Html::Constants::HTML_SPAN_ELEMENTS.

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 11 Dec 2019 20:14:34 +1100

> Not sure about that :-), but a quick workaround is to not start the 

Yuck, but that fixes the kramdown issue.  Now back to the xml2rfc issue.

After doing that, I get this in the text output:

   [...]
   Schinazi, Dmitri Tikhonov, Eric Kinnear, Eric Rescorla, Gorry
   Fairhurst, Ian Swett, Igor Lubashev, Kazuho's real nameMikkel Fahnøe
   JørgensenMirja Kühlewindxxx

Note that the special elements get stuck at the end.  The commas also disappear.  Despite the XML now being correct, the extra comma after each <contact> seems to have gone missing too.  All undifferentiated text after the first <contact> disappears.  (That's the last content from that paragraph.)

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 11 Dec 2019 10:41:56 +0100

Hi Martin,

On 2019-12-11 10:14, Martin Thomson wrote:
> Note that the special elements get stuck at the end.  The commas also
> disappear.  Despite the XML now being correct, the extra comma after
> each <contact> seems to have gone missing too.  All undifferentiated
> text after the first <contact> disappears.  (That's the last content
> from that paragraph.)

Yes.  I found that yesterday evening, shortly after the release, fixed
it, and got ready to do a bugfix release today.  If there's still an
exception related to pagination in connextion with <contact> I'd like to
fix that at the same time, though.

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Dec 2019 11:30:13 +0100

> fix that at the same time, though.

Before doing a new release, by all means please have a look at the
feedback I sent earlier today.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 13 Dec 2019 09:47:26 +0100

> feedback I sent earlier today.

Raised <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/471> for
the bit about <organization>.

Best regards, Julian