kramdown-rfc

kramdown-rfc copied to clipboard

The RPC seems to be adding the following attributes:

• On section - numbered="true" toc="default"
• On xref - format="default"

Could these be added in v3 output (once again, to reduce diffs)?

Ideally after the anchor in each

I'm not sure I understand the process here. kramdown-rfc produces a v2/v3 mongrel RFCXML. Either the author or the RFC editor runs this through xml2rfc --v2v3 to obtain the processable ("unprepped") RFCXML for editing. The bug that creates these default-valued attributes should be present on both sides, so I'm not sure kramdown-rfc needs to emulate it. Do you run your diff before --v2v3?

It’s necessary to run —2to3 even when kramdown-rfc2629 ia run with —v3?

With --v3 (which is now default), kramdown-rfc generates mongrel XML that is converted to proper v3 by xml2rfc. Martin Thomson's pipeline does that for you, so you may not have noticed.

Ah, I didn't see that -- yes, it is.

Nevertheless, I'm not seeing these attributes in the XML produced by kramdown-rfc2629 --v3 | xml2rfc --v2v3, whereas they are in the RPC's copy.

I've updated to latest xml2rfc, i-d-template, and kramdown-rfc2629.

Hmm, I see them. We must be doing something different. Do you have a sample I could try?

in httpwg/http-extensions, make draft-ietf-httpbis-bcp56bis.xml, and compare to https://www.rfc-editor.org/authors/rfc9209.xml

(happy to supply a file for the former via e-mail if you don't want to go to the trouble)

No problem. Indeed, the redundant attributes are gone. Need to examine more closely.

Seems to have happened between xml2rfc 3.11.1 and xml2rfc 3.12.1. The commit messages aren't very useful, looking at the code now.

Hmm. I tried downgrading to 3.9.1 -- the same version used by the RPC for my draft -- and it still happened.

"it happened"?

The fix might actually be in lxml or some such.

the XML produced by kramdown + v2v3 didn't have those default attributes.

The v2v3 output sure did for 3.11.1; I can't easily make a controlled experiment here.

3.11.1 does not produce those attributes for me, when called from @martinthomson's template.

The work happens In

        text = lxml.etree.tostring(self.root.getroottree(), 
                                   encoding='unicode',
                                   doctype=doctype_string,
                                   pretty_print=True)

So this might really be an lxml fix.

I know very little about the xml2rfc codebase, but surely it can control what attributes appear on an element?

This is really weird. I have instances up to 3.11.1 that have both numbered=true and toc=default. I also have 3.11.1 instances that are toc=default only. I cannot find instances beyond 3.11.1 that have redundant attributes on <section.

I'd guess this will have solved itself as soon as the RFC editor updates their tools.

OK. I might write a little XSLT for diff purposes in the meantime... thanks.

I think you could also ask the RFC-editor to delete the spurious redundant attributes.

I did; they declined.

For reference: https://gist.github.com/mnot/a2c4e370ed90cc75eb2cf5ad2a19f8cb

I did; they declined.

Whoa. Is this documented somewhere (outside an AUTH48 exchange)? Did they give a reason?

Don't think so. To be fair, I asked but said not to do it if it's a lot of trouble. I could be more insistent.

Maybe they are doing this for some internal tool.

-- mode: grep; default-directory: "~/std/rfc/authors/" -- Grep started at Sun Feb 27 01:28:40

The below was a bit shocking for me... 3.5.0 was 2020-11-18, 3.1.1 was 2020-09-14. But maybe these all are submitter-converted, with whatever these had at hand...

grep --color=auto -nH --null -e "xml2rfc v2v3 conversion 3" rfc9???.xml
rfc9003.xml�9:  <!-- xml2rfc v2v3 conversion 3.5.0 -->
rfc9004.xml�12:  <!-- xml2rfc v2v3 conversion 3.5.0 -->
rfc9006.xml�8:  <!-- xml2rfc v2v3 conversion 3.5.0 -->
rfc9007.xml�7:  <!-- xml2rfc v2v3 conversion 3.5.0 -->
rfc9008.xml�5:<!-- xml2rfc v2v3 conversion 3.5.0 -->
rfc9012.xml�7:  <!-- xml2rfc v2v3 conversion 3.5.0 -->
rfc9015.xml�12:  <!-- xml2rfc v2v3 conversion 3.1.1 -->
rfc9016.xml�7:  <!-- xml2rfc v2v3 conversion 3.5.0 -->
rfc9017.xml�9:  <!-- xml2rfc v2v3 conversion 3.5.0 -->
rfc9020.xml�5:  <!-- xml2rfc v2v3 conversion 3.5.0 -->
rfc9022.xml�8:  <!-- xml2rfc v2v3 conversion 3.5.0 -->
rfc9027.xml�7:  <!-- xml2rfc v2v3 conversion 3.5.0 -->
rfc9029.xml�6:  <!-- xml2rfc v2v3 conversion 3.6.0 -->
rfc9037.xml�10:  <!-- xml2rfc v2v3 conversion 3.5.0 -->
rfc9039.xml�6:  <!-- xml2rfc v2v3 conversion 3.5.0 -->
rfc9046.xml�6:  <!-- xml2rfc v2v3 conversion 3.5.0 -->
rfc9048.xml�7:  <!-- xml2rfc v2v3 conversion 3.8.0 -->
rfc9050.xml�5:  <!-- xml2rfc v2v3 conversion 3.5.0 -->
rfc9051.xml�6:  <!-- xml2rfc v2v3 conversion 3.5.0 -->
rfc9057.xml�5:  <!-- xml2rfc v2v3 conversion 3.7.0 -->
rfc9059.xml�7:  <!-- xml2rfc v2v3 conversion 3.5.0 -->
rfc9061.xml�5:  <!-- xml2rfc v2v3 conversion 3.7.0 -->
rfc9065.xml�6:  <!-- xml2rfc v2v3 conversion 3.7.0 -->
rfc9067.xml�12:  <!-- xml2rfc v2v3 conversion 3.9.1 -->
rfc9069.xml�12:  <!-- xml2rfc v2v3 conversion 3.3.0 -->
rfc9072.xml�9:  <!-- xml2rfc v2v3 conversion 3.7.0 -->
rfc9075.xml�10:  <!-- xml2rfc v2v3 conversion 3.7.0 -->
rfc9078.xml�5:  <!-- xml2rfc v2v3 conversion 3.7.0 -->
rfc9080.xml�21:  <!-- xml2rfc v2v3 conversion 3.2.1 -->
rfc9081.xml�7:  <!-- xml2rfc v2v3 conversion 3.8.0 -->
rfc9090.xml�8:<!-- xml2rfc v2v3 conversion 3.7.0 -->
rfc9093.xml�6:  <!-- xml2rfc v2v3 conversion 3.7.0 -->
rfc9094.xml�8:  <!-- xml2rfc v2v3 conversion 3.7.0 -->
rfc9095.xml�7:  <!-- xml2rfc v2v3 conversion 3.8.0 -->
rfc9097.xml�10:  <!-- xml2rfc v2v3 conversion 3.8.0 -->
rfc9098.xml�7:  <!-- xml2rfc v2v3 conversion 3.8.0 -->
rfc9099.xml�6:  <!-- xml2rfc v2v3 conversion 3.7.0 -->
rfc9104.xml�7:  <!-- xml2rfc v2v3 conversion 3.8.0 -->
rfc9106.xml�7:  <!-- xml2rfc v2v3 conversion 3.8.0 -->
rfc9107.xml�6:  <!-- xml2rfc v2v3 conversion 3.8.0 -->
rfc9109.xml�7:  <!-- xml2rfc v2v3 conversion 3.9.1 -->
rfc9113.xml�15:  <!-- xml2rfc v2v3 conversion 3.5.0 -->
rfc9114.xml�15:  <!-- xml2rfc v2v3 conversion 3.5.0 -->
rfc9115.xml�4:  <!-- xml2rfc v2v3 conversion 3.4.0 -->
rfc9118.xml�12:  <!-- xml2rfc v2v3 conversion 3.9.1 -->
rfc9119.xml�13:   <!-- xml2rfc v2v3 conversion 3.9.1 -->
rfc9120.xml�12:  <!-- xml2rfc v2v3 conversion 3.9.1 -->
rfc9124.xml�16:  <!-- xml2rfc v2v3 conversion 3.9.1 -->
rfc9132.xml�6:  <!-- xml2rfc v2v3 conversion 3.8.0 -->
rfc9135.xml�12:  <!-- xml2rfc v2v3 conversion 3.9.1 -->
rfc9137.xml�12:<!-- xml2rfc v2v3 conversion 3.9.1 -->
rfc9138.xml�12:  <!-- xml2rfc v2v3 conversion 3.9.1 -->
rfc9139.xml�11:  <!-- xml2rfc v2v3 conversion 3.9.1 -->
rfc9141.xml�12:  <!-- xml2rfc v2v3 conversion 3.10.0 -->
rfc9146.xml�14:  <!-- xml2rfc v2v3 conversion 3.8.0 -->
rfc9147.xml�16:  <!-- xml2rfc v2v3 conversion 3.5.0 -->
rfc9150.xml�12:  <!-- xml2rfc v2v3 conversion 3.8.0 -->
rfc9152.xml�7:  <!-- xml2rfc v2v3 conversion 3.5.0 -->
rfc9155.xml�14:  <!-- xml2rfc v2v3 conversion 3.10.0 -->
rfc9156.xml�11:  <!-- xml2rfc v2v3 conversion 3.9.1 -->
rfc9159.xml�11:  <!-- xml2rfc v2v3 conversion 3.9.1 -->
rfc9160.xml�12:  <!-- xml2rfc v2v3 conversion 3.10.0 -->
rfc9162.xml�12:  <!-- xml2rfc v2v3 conversion 3.9.1 -->
rfc9171.xml�15:  <!-- xml2rfc v2v3 conversion 3.7.0 -->
rfc9173.xml�12:  <!-- xml2rfc v2v3 conversion 3.9.0 -->
rfc9177.xml�12:  <!-- xml2rfc v2v3 conversion 3.8.0 -->
rfc9178.xml�13:  <!-- xml2rfc v2v3 conversion 3.1.1 -->
rfc9181.xml�12:  <!-- xml2rfc v2v3 conversion 3.10.0 -->
rfc9182.xml�12:  <!-- xml2rfc v2v3 conversion 3.10.0 -->
rfc9187.xml�10:  <!-- xml2rfc v2v3 conversion 3.12.0 -->
rfc9189.xml�14:  <!-- xml2rfc v2v3 conversion 3.11.1 -->
rfc9192.xml�12:  <!-- xml2rfc v2v3 conversion 3.12.0 -->
rfc9193.xml�14:  <!-- xml2rfc v2v3 conversion 3.9.1 -->
rfc9199.xml�14:  <!-- xml2rfc v2v3 conversion 3.12.0 -->
rfc9204.xml�14:  <!-- xml2rfc v2v3 conversion 3.5.0 -->
rfc9205.xml�16:  <!-- xml2rfc v2v3 conversion 3.9.1 -->
rfc9208.xml�12:  <!-- xml2rfc v2v3 conversion 3.11.1 -->
rfc9209.xml�15:  <!-- xml2rfc v2v3 conversion 3.10.0 -->

Grep finished with 78 matches found at Sun Feb 27 01:28:41

See also https://github.com/ietf-tools/xml2rfc/issues/632

See also https://notes.ietf.org/tools-team-20220308#XML2RFC---Kesara I don't expect quick progress -- there are some 135 tickets, and three are scheduled now... So let's see what we can do on the authoring side.

@mnot You should be able to emulate previous behaviour to reduce diffs by using kramdown-rfc2629 -2 option. This adds SYSTEM "rfc2629.dtd" doctype reference. xml2rfc adds those default values when that doctype reference is present.

Note that this will not work with kramdown-rfc command because of #164.

@mnot You should be able to emulate previous behaviour to reduce diffs by using kramdown-rfc2629 -2 option.

Thanks for finding the reason...

Well, the workaround to go to -2 also turns off v3 processing. But a simple sed script could add back the SYSTEM "rfc2629.dtd" (before feeding into --v2v3).