Triple-brace (<contact) inside <li>

[MikeBishop]

When I do the intuitive thing and have a list of contributors, where each name is triple-braced...

{:compact}
- {{{Bence Béky}}}
- {{{Daan De Meyer}}}
- {{{Martin Duke}}}
- {{{Roy Fielding}}}

...kramdown correctly produces contacts but xml2rfc chokes on it:

rfc9114.xml(3312): Error: Element li has extra content: contact, at /rfc/back/section[2]/ul/li[1]/contact rfc9114.xml(3313): Error: Element li has extra content: contact, at /rfc/back/section[2]/ul/li[2]/contact rfc9114.xml(3314): Error: Element li has extra content: contact, at /rfc/back/section[2]/ul/li[3]/contact rfc9114.xml(3315): Error: Element li has extra content: contact, at /rfc/back/section[2]/ul/li[4]/contact

It looks like xml2rfc is expecting <t> around anything that's not simple text within the <li>. But if I "fix" the issue by putting <t> around each contact...

{:compact}
- <t>{{{Bence Béky}}}</t>
- <t>{{{Daan De Meyer}}}</t>
- <t>{{{Martin Duke}}}</t>
- <t>{{{Roy Fielding}}}</t>

...the braces don't get turned into contacts:

  <ul spacing="compact">
    <li>{{{Bence Beky}}}</li>
    <li>{{{Daan De Meyer}}}</li>
    <li>{{{Martin Duke}}}</li>
    <li>{{{Roy Fielding}}}</li>

The RFC Editor fixed this up for me in RFC 9114, and I didn't even notice until I was diffing my fix-up branch against the final RFC.

[cabo]

When I do the intuitive thing and have a list of contributors, where each name is triple-braced...

{:compact}
- {{{Bence Béky}}}
- {{{Daan De Meyer}}}
- {{{Martin Duke}}}
- {{{Roy Fielding}}}

...kramdown correctly produces contacts but xml2rfc chokes on it:

rfc9114.xml(3312): Error: Element li has extra content: contact, at /rfc/back/section[2]/ul/li[1]/contact rfc9114.xml(3313): Error: Element li has extra content: contact, at /rfc/back/section[2]/ul/li[2]/contact rfc9114.xml(3314): Error: Element li has extra content: contact, at /rfc/back/section[2]/ul/li[3]/contact rfc9114.xml(3315): Error: Element li has extra content: contact, at /rfc/back/section[2]/ul/li[4]/contact

It looks like xml2rfc is expecting <t> around anything that's not simple text within the <li>.

RFCXMLv3 has a grammar that replicates the information for what are block and span level elements throughout the grammar. This replication is hard to maintain and therefore has a number of inconsistencies, which are not being fixed as these mistakes are in RFC 7991 which is supposed to guide RFCXMLv3 development.

When <contact was added to xml2rfc's vocabulary going beyond RFC 7991, the addition was done in a particularly haphazard way, which means it is allowed as a span-level element only in <t (plus as a block-level element in <section). I made a fixup kit in https://tzi.org/~cabo/contact-hack.sh, but that of course only helps with your local xml2rfc. Not sure when we will be able to start fixing xml2rfc in earnest.

But if I "fix" the issue by putting <t> around each contact...

{:compact}
- <t>{{{Bence Béky}}}</t>
- <t>{{{Daan De Meyer}}}</t>
- <t>{{{Martin Duke}}}</t>
- <t>{{{Roy Fielding}}}</t>

...the braces don't get turned into contacts:

Of course not. Once you have entered XML land in a markdown file, there is no markdown parsing any more for the inside of the XML (which, among other things, would turn < into <).

Fixed workaround should be:

{:compact}
- <t markdown="span">{{{Bence Béky}}}</t>
- <t markdown="span">{{{Daan De Meyer}}}</t>
- <t markdown="span">{{{Martin Duke}}}</t>
- <t markdown="span">{{{Roy Fielding}}}</t>

But now we run into a peculiarity of xml2rfc's v2 to v3 converter which is still employed by kramdown-rfc: xml2rfc seems to delete the <t decoration in an <li (after all, this should be redundant, and would be if the RFCXMLv3 syntax were sane!), so it still throws the same error. Not sure that this peculiarity, which turns into a bug only with the above mentioned grammar bug, will ever be fixed.

I could tinker with the kramdown-rfc output until it survives the v2v3 peculiarity. I could also, when generating a <contact, check whether the context is a <t, and, if not, generate one.

Congratulations to finally shipping RFC 9114, by the way!

[cabo]

The bug that prevented the workaround from working is now fixed in https://github.com/ietf-tools/xml2rfc/releases/tag/v3.18.1

The bug in the grammar that creates the need for the workaround is unchanged though.

[cabo]

Oh.
The workaround actually is no longer needed, as v2v3 now spits out RFCXML that is conforming to the (unfixed) v3 syntax. This now works:

{:compact}
- {{{Bence Béky}}}
- {{{Daan De Meyer}}}
- {{{Martin Duke}}}
- {{{Roy Fielding}}}

Another reason why it makes a lot of sense to leave the generation of proper v3 RFCXML to xml2rfc's v2v3 converter. Wonderful; closing this issue now.