Subject: [xml2rfc] Current xml2rfc produces errors on published RFCs

From: "John R Levine" <[email-masked]>
Date: 1 Aug 2021 21:49:34 -0400

When I run rfc8799.xml or rfc9001.xml through the current version of 
xmlrfc, it says:

Error: Found no element to match the <xref> target attribute 'section-a.1'

When I look at the XML, the target is there and this presumably worked 
when the RFCs were published.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 2 Aug 2021 13:10:58 +0900

> when the RFCs were published.

I think it would be a good idea to add the above two documents to a test 
suite to avoid regressions. And use some kind of continuous integration 
testing (if that's already done, that's great).

Regards,   Martin.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 2 Aug 2021 17:10:12 +1200

From a brief experiment, the xml2rfc convertor at https://xml2rfc.tools.ietf.org/experimental.html simply can't deal with the xml files at https://www.rfc-editor.org/info/rfcXXXX, right back to RFC8650.

The specific element causing the problem appears to be pn="xxx" which is like anchor only different. The published XML is littered with pn's.

Regards
   Brian

> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc
>

---

From: Kesara Rathnayake <[email-masked]>
Date: Mon, 2 Aug 2021 17:34:14 +1200

This seems to be introduced with 
https://trac.ietf.org/trac/xml2rfc/ticket/581 by restricting section IDs 
to be in `appendix-A.1` format without a backward compatibility.

  --Kesara

-- 
Kesara Rathnayake
Senior Software Development Engineer - IETF LLC
[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Mon, 2 Aug 2021 07:39:12 +0200

> to be in `appendix-A.1` format without a backward compatibility.

AFAIU, this is because of the inlined Table Of Contents in the prepped
version...

Best regards, Julian

---

From: Brian Carpenter <[email-masked]>
Date: Mon, 2 Aug 2021 20:08:19 +1200

I think that's a red herring. The processor is not recognizing pn="xxx",
that's all.

Regards,
    Brian Carpenter
    (via tiny screen & keyboard)

---

From: Julian Reschke <[email-masked]>
Date: Mon, 2 Aug 2021 11:25:10 +0200

> I think that's a red herring. The processor is not recognizing pn="xxx",

Nope.

The issue is that the document uses xref/target to point to sections
indentified by their "pn" attribute, and that one's value is different
under the new version of xml2rfc (and gets replaced).

We wouldn't have this issue if the ToC wasn't inlined in the first
place. So a bad implementation decision now causes breakage in
"canonical XML".

This could be worked around by xml2rfc rewriting the inlined ToC as
well... (but that would be a workaround on top of a bad implementation
choice which leaked into the user-visible grammar).

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 2 Aug 2021 14:03:52 +0200

> under the new version of xml2rfc (and gets replaced).

So you need to unprep the xml before any further processing.

I’m not sure we have been told why there is a need to process the xml again; if there is authoring involved unprepping is already the right way to get rid of all that noise, so I don’t see how that is a big problem.

xml2rfc —unprep rfc8799.xml
… edit rfc8799.plain.xml
xml2rfc rfc8799.plain.xml

If this is just for generating renderings, of course xml2rfc should not second-guess the previous output of the preptool.

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Mon, 2 Aug 2021 14:13:33 +0200

> So you need to unprep the xml before any further processing.

That's possible, but I still don't get why we include the ToC.

> I’m not sure we have been told why there is a need to process the xml again; if there is authoring involved unprepping is already the right way to get rid of all that noise, so I don’t see how that…

If we need to "unprep" the published XML before doing anything with it
(like generating new HTML), the whole concept of sealing certain
auto-generated information in the published XML becomes somewhat weird.

> If this is just for generating renderings, of course xml2rfc should not second-guess the previous output of the preptool.

Which for this specific change means that the "old" documents keep their
old anchors for appendices, making them inconsistent with newer ones,
and making it impossible to compute the proper anchor without additional
information (such as reading the actual XML).

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 2 Aug 2021 16:47:56 +0200

> information (such as reading the actual XML).

Yes, which might mean that this specific change maybe wasn’t so practical.

Grüße, Carsten

---

From: "John R Levine" <[email-masked]>
Date: 2 Aug 2021 11:25:44 -0400

On Mon, 2 Aug 2021, Martin J. Dürst wrote:
>> When I look at the XML, the target is there and this presumably worked when 
>> the RFCs were published.
>

Not just those two, all of them.  I've run the entire set of published 
RFCs through xml2rfc.  It takes maybe half an hour.  We definitely should 
do that before releasing each new version.

Regards,

---

From: Julian Reschke <[email-masked]>
Date: Mon, 2 Aug 2021 18:42:13 +0200

Am 02.08.2021 um 17:25 schrieb John R Levine:
>>> When I look at the XML, the target is there and this presumably
>>> worked when the RFCs were published.
>>
>> I think it would be a good idea to add the above two documents to a
>> test suite to avoid regressions. And use some kind of continuous
>> integration testing (if that's already done, that's great).
>
> RFCs through xml2rfc.  It takes maybe half an hour.  We definitely
> should do that before releasing each new version.

So if anything breaks with published canonical XML, we can't make that
change?

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 2 Aug 2021 18:58:22 +0200

> So if anything breaks with published canonical XML, we can't make that

I’d say, if a function of xml2rfc breaks that we need to run-on published v3 RFCs (8650+), we should make a better change.

Re-rendering is certainly one such function.
What else?

Grüße, Carsten

---

From: "John Levine" <[email-masked]>
Date: 2 Aug 2021 19:57:00 -0000

>So if anything breaks with published canonical XML, we can't make that

Maybe, maybe not, but we can at least make the change knowing what the consequences will be.

This gets back to the unresolved issue of whether we're going to update the XML in published
RFCs once we agree on what v3.1 is.

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Aug 2021 08:57:48 +1200

> under the new version of xml2rfc (and gets replaced).

I'm sorry, I absolutely cannot parse that sentence. All I was saying is
that https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc-dev.cgi seems to
have trouble with "pn".

   Brian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 3 Aug 2021 09:05:28 +0200

> Maybe, maybe not, but we can at least make the change knowing what the consequences will be.

+1

> RFCs once we agree on what v3.1 is.

True. And I continue to believe that we should do that.

Best regards, Julian