Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

v3 default attributes #162

Open
mnot opened this issue Feb 26, 2022 · 30 comments
Open

v3 default attributes #162

mnot opened this issue Feb 26, 2022 · 30 comments

Comments

@mnot
Copy link

mnot commented Feb 26, 2022

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)?
@mnot
Copy link
Author

mnot commented Feb 26, 2022

Ideally after the anchor in each

@cabo
Copy link
Owner

cabo commented Feb 26, 2022

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?

@mnot
Copy link
Author

mnot commented Feb 26, 2022

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

@cabo
Copy link
Owner

cabo commented Feb 26, 2022 •
edited

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.

@mnot
Copy link
Author

mnot commented Feb 26, 2022

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.

@cabo
Copy link
Owner

cabo commented Feb 26, 2022

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

@mnot
Copy link
Author

mnot commented Feb 26, 2022

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

@mnot
Copy link
Author

mnot commented Feb 26, 2022

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

@cabo
Copy link
Owner

cabo commented Feb 26, 2022

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

@cabo
Copy link
Owner

cabo commented Feb 26, 2022

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.

@mnot
Copy link
Author

mnot commented Feb 26, 2022

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

@cabo
Copy link
Owner

cabo commented Feb 26, 2022

"it happened"?

@cabo
Copy link
Owner

cabo commented Feb 26, 2022

The fix might actually be in lxml or some such.

@mnot
Copy link
Author

mnot commented Feb 26, 2022

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

@cabo
Copy link
Owner

cabo commented Feb 26, 2022

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

@mnot
Copy link
Author

mnot commented Feb 26, 2022

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

@cabo
Copy link
Owner

cabo commented Feb 26, 2022

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.

@mnot
Copy link
Author

mnot commented Feb 26, 2022

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

@cabo
Copy link
Owner

cabo commented Feb 26, 2022

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.

@mnot
Copy link
Author

mnot commented Feb 26, 2022

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

@cabo
Copy link
Owner

cabo commented Feb 26, 2022

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

@mnot
Copy link
Author

mnot commented Feb 26, 2022

I did; they declined.

@mnot
Copy link
Author

mnot commented Feb 26, 2022

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

@cabo
Copy link
Owner

cabo commented Feb 27, 2022

I did; they declined.

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

@mnot
Copy link
Author

mnot commented Feb 27, 2022

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.

@cabo
Copy link
Owner

cabo commented Feb 27, 2022

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

@mnot
Copy link
Author

mnot commented Mar 6, 2022

See also ietf-tools/xml2rfc#632

@cabo
Copy link
Owner

cabo commented Mar 6, 2022

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.

@kesara
Copy link

kesara commented Mar 7, 2022

@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.

@cabo
Copy link
Owner

cabo commented Apr 21, 2022

@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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@cabo @mnot @kesara