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

Julian Reschke <julian.reschke@gmx.de> Mon, 02 August 2021 12:13 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDF73A1AC9 for <xml2rfc@ietfa.amsl.com>; Mon, 2 Aug 2021 05:13:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZfBdGAPxS0C for <xml2rfc@ietfa.amsl.com>; Mon, 2 Aug 2021 05:13:52 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AA053A1AC8 for <xml2rfc@ietf.org>; Mon, 2 Aug 2021 05:13:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1627906416; bh=OMP9dTXnYNbVnXw0mknD4G/QZbUYRWIOzcw+A41R1dM=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=A5qyuB40Gl0Esar+A3weo0kZbsHIlgx3Y0mGM8mvGebbAmt1MZoQRjER7WE2K+O9x WH72F8xsIk8aHts/H7v8ujTDJ5ep/oU9/8eAhhnyxru0w1uZLSQJpxtYIU8nuxAUeX ZYxJXJILcF8sIs5eEIUYcUcL12jAXodOrMRNiHck=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [172.16.1.70] ([212.205.152.82]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MkHQX-1muHpR0Qsj-00khtL; Mon, 02 Aug 2021 14:13:36 +0200
To: Carsten Bormann <cabo@tzi.org>
Cc: Brian Carpenter <brian.e.carpenter@gmail.com>, xml2rfc <xml2rfc@ietf.org>
References: <69176971-843c-5e59-b45b-18398bd41d38@taugh.com> <61145c89-4c93-13ab-6430-e87afcf17efe@it.aoyama.ac.jp> <5cd2807f-397c-b098-f91f-a8e84a6b4510@gmail.com> <94576ea4-d3ab-2aa3-c43b-8771b1f9e043@ietf.org> <e28ed04b-8d51-089b-3ea5-aae139d371be@gmx.de> <CANMZLAa=TYEhv+-6ZHJBmeGDHee__knTgEu7E8eZjV_UitMhsQ@mail.gmail.com> <431c2076-46b8-c71f-86ea-4186dffeff7e@gmx.de> <9B968E22-B4BC-47AF-9A4C-53015726CD2F@tzi.org>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <ea1a79db-8538-2f56-dc6c-ec1ab2fd2832@gmx.de>
Date: Mon, 02 Aug 2021 14:13:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <9B968E22-B4BC-47AF-9A4C-53015726CD2F@tzi.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:pY5eMXpGzxUwjJJLQkbNHA40M9+FU0EB0pGX/pp0qsxTVKOcRne hbwBDjk6ZQrSEPIbov+tQ7Da4LEiYiOattfZC2zV2dnUoJUUZ9wTY0/y/sKWWZQ2/z5PDEK uoSicSTXF3PU2EeZsdlSop29qJs5P/1P28Qg+PcBf4up+/MgDCnUCltBCI8QDgC6yZyMbiW fbeHSyosOvVDZVp+RyKwg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:jxICtTA00UE=:Zj5gOR/wb/P0mDLr3gFsQ3 ASnWfX8NZ8avpM11zudgbdL9i+dO2s6QE0JPuOjEsGps6rGbDCL1Jrd5Pkwf9esGakSESZfhX 6aKLN8f5uMkST4b5UYY/ibMtd7xRpFDi8lSx55h2+RNrwR2Wd1o3IpGNiRIPx9F2qM7hPgLua 4sQngmAhZAxeMNPtTJTipGE8ec05fPAR/7URCVpdIGFCG1TTvfFqwTsb21zrBr9Sa3gkDr3YU gJHLseHGopjJHknaVOLo3ZDCZu8Zfl2f2+AmX+5/zVPlbYgXwcJeBmw5dQ2ULvRJHKOTPsUsa AVuhVhSy4fASGDLFuyiFR2Nn/v4tyRYJVmhsHNp3h3tlvaFDmQ0fqM+6pLpU4BNIGmnT0GFrh BXCcJNSX8gt1q7h7t4MasktujcKQwHgZTxQ8JW8uuMqUU47ss0ETF0uzvIrfk/HSPHnlIrP5c uJkzOElGJ8i9vOBF1CPRe+bW7MBwi1xz6C/L1QW0VwE54zKV+dSPpwRj2XWd/wxanRDtnw78v RyQl4U+MUVaNvMNQXmOfNDJky3s3B09WGevJNt4AcS707KffDMv9zXRKjmSJRleD08VY32lU7 37O3SYYOmcFcLZUhE0xYi8F8AYRzWdDfibNHA91m8qxNoy6BDd9b9ftPKwKknLTdGoSZR7ZVR z5y2LrMQuPzgVdhxItRHL0ydqHcHzKapgCcCfsjI1nI4emCWY4IwV7umbljPCg17yUA7DfBQ6 zntnE6wTJHwy082ph1GIMytQ1YsLFnsH5XL6v0pARXLVdl2tmIXhQgUxIMeTrtsi+w/5T2sut voJVS5jJmVhhh//5/DSGDBvPYqah773F6AKhN4ikWo1T+4QSKjxU32g0JNaYJ7BSqKfbHe5q1 9XZlx2tYkHroAvs+CIFK1koMBPZoBa0PIKl38zHhrlMOQEb/tiWOgmZKxjSDMMwRFfH5cac+o CRXE0UzavZLjdZB6+zLhwGlamaWkiYyLvCrbfORQX6ZNlJcvVHlLDdmdN/daYAtZ4WzhElI3M L7REMUg01jU0/w73Ge6f0BV5N8qtlKD4/xdOPdv7Xg0DuZ+o01nGo7Tczb9P6FG50SJ0YTnSG wH9xsmIGC/ztEHZNx/jygCMe1pDdDuqufjCUZzXIJkQTpcPOvi/1suN3g==
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/kSoLYKr9shHvPxTc8j2M-0W_KBw>
Subject: Re: [xml2rfc] Current xml2rfc produces errors on published RFCs
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: XML2RFC discussion list <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Aug 2021 12:13:57 -0000

Am 02.08.2021 um 14:03 schrieb Carsten Bormann:
> On 2021-08-02, at 11:25, Julian Reschke <julian.reschke@gmx.de> wrote:
>>
>> 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).
>
> 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 is a big problem.

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.

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

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