Re: [xml2rfc] can xref section= reference an anchor?

Julian Reschke <julian.reschke@gmx.de> Mon, 16 December 2019 18:04 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 2B73B120048 for <xml2rfc@ietfa.amsl.com>; Mon, 16 Dec 2019 10:04:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-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 qTMIdGq_Cw28 for <xml2rfc@ietfa.amsl.com>; Mon, 16 Dec 2019 10:04:32 -0800 (PST)
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 E3B4912001A for <xml2rfc@ietf.org>; Mon, 16 Dec 2019 10:04:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576519456; bh=142ZOMaeuS86mb2Ih2eSAZwhIigKEZYuq4kPWh8KjRY=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=NUXcdGxOV51znN9sqIuo0Ds3wCyB3XubY0/pE46eKSodH9T2QGnlHhIb6bQcnSyIa j67rfFphBPyNPVFd1RPVE+gbY6Yg7Nm9YxwxVtive6okt5yrfKykxmx87zx14y7g36 fMCwscJT9wyqB9epBxxYF+e56CL0gZXpWWzCYMus=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([91.61.56.199]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MiaYJ-1i1GSN2YPH-00fkJL; Mon, 16 Dec 2019 19:04:16 +0100
To: Carsten Bormann <cabo@tzi.org>, Robert Moskowitz <rgm@htt-consult.com>
Cc: "xml2rfc@ietf.org" <xml2rfc@ietf.org>
References: <5d192de5-c6ca-aa1f-b7e0-0500704e491a@htt-consult.com> <C8AF4E96-E5BB-4232-B58C-A617E404DFF4@tzi.org>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <78372dfd-39ff-183f-4f51-0b2c7e8d73d0@gmx.de>
Date: Mon, 16 Dec 2019 19:04:16 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <C8AF4E96-E5BB-4232-B58C-A617E404DFF4@tzi.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:S/8heFpKFlzoQuGYNKuk+bCv2p/7pBFIgn4oeNBTNeMAFImP+mn rh/0I8CLYn7SqIAfGztlMNioiUxTushSPl4+ab+oSq5NA6jo0GkujOzrOvPnZfp6rB7tEN3 fLOIqKP2IJQdX76QkA3t0cvLmOodQuLAfHu3TsGPgUB9VTeB17DaoEcDxOnar+ABt3fvl3+ ka/IsRWNtZv+vQ5gM07Zw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:ZLuhSwTCN0A=:4Oc2gbNZhSHnEglFpkNmbV IUGO2wIrtnd9FfJ+cLwe3DHbG0jqdrxvDo2XWsCVQkoo+bdD+Cwgkp4GiEsHvbAUJAQNvEsIb jg3x43qPjPRCeifeqnlWa3+cPaBcSGgWdfKsHOyYCbJ6ztDpFU6xhrIp6CjceiwvY8ryaj/MX jCgxvz0RP6KxqWTuBwfGSyu+0YpneK+symq1wiKorhuk0uGBcUbsGgjmfXffShKtkpwh5aRaK +JbBtacGWmOuO3mF5bXFKESceaTvrHJ8JhH3iVOkpWUiw0wKfs0L/SycUNm/znbqVwqnHOAjU 9Yo/IcDlsbqT0UQ5HpEbjBfOeGeUTOJ6qcwUjbRKNqPATn57yJsargGATHL56tOmsrmxSLUxR j35EEq09FT0rgN7LxBHoQrsbLuph75GgvvNib4OmkRbAtHq37GdmvegXITijmMjMrc55yPibZ U21FbctbkLpfJYmcGq4MI+KPqqZqQZQG3ZubFiNlJwiesIPfcVpCxrFQNaKzKyJ8SpdhQG0AV 08EkH9XYzjG8CAldb9hrNtWCE1NyfOxbmHxz2QuwFNbqgD48GgEEiSGA7ZaCSWKgLZ7CR4HU0 IToOrQcVP7nWLpldaVsgxSuZ/64GVfqvc0/atagYZHM+3mKvS1cv1cmHePB8UhBqjQCGorWbI wSVPVIGuhj0FByytIEmhSjvJx//pS5fAEeu/3sF8OgMUAUXQonEuhkodslQI1NkTdk5iiMIkT aaUS+2eYLN4qmSMGKFnz/cs3yxVCwo+us8re0eCRCX4GE5K1wjVbrKwNe+cIrg16xvrkYiv8U t8KTtjJPLc3v9ekEM96tfZ1U4veJMHFWUiC48vexZEyvP+/o8kdJSa0eV0GeP2X1yKAHQmfZ6 ZuFi57aybmLBubBvV5hCx0Pb7OWbgCynS69Q5Nm0SJeQKpx7fgJA0zl3WM0HGr4uocGaW4chT cIIRJj+tw9yF564ey4XrFRwJ7mGAYAdUjXgUOhWXkglxwnNzhIxPdpPr56C7yMa4E+H44Jf87 WNRP6+Fx4H9oXbAmUnccdKkTZ7qTIyGUSwfANwvXgVVvEiBg5vXsh+6A5Zh59IyY5q33MKB2C x6lw9kmZm0vV9HLGpLMBKt5bw/0txp0q1ENaXQbYmgV7xHInXyPnMsZAPNssih8K4MRaNmS1T QSnk10OTJ3fXh7QxlQESmB1K1rdbEI1l2mF9ou8Z+jxUQRblUAiOk/pY2hvNor67h8JOLtVsg evtm5D7mmR3P+5/FBpIJy0rWkzqFO3w4rAPN/HYvegyLmJ1t2ZlCCDGcxYqM=
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/ggfRAMGA363JTnFXsjJdCOajQU8>
Subject: Re: [xml2rfc] can xref section= reference an anchor?
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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, 16 Dec 2019 18:04:34 -0000

On 16.12.2019 18:53, Carsten Bormann wrote:
> On Dec 16, 2019, at 17:47, Robert Moskowitz <rgm@htt-consult.com> wrote:
>>
>> I see examples of section=5 for RFCs, but for IDs, the section number will tend to be version specific.
>>
>> Is there a way to reference the anchor label for the desired section?
>
> To translate the anchor label into a section number (or a section title), the referencing spec would need access to the referenced spec.  To generate a standalone document, this could be implemented by including the referenced spec into the referencing document, or more reasonably just an abstraction of it that leaves only the information needed for that translation (a “side file” in traditional formatter jargon).
>
> I believe the best way to handle this would be to keep extracted “side files” of this kind for all specs (drafts and RFCs), ready for inclusion just like we include the extracted reference information itself into a referencing spec.  This does not just require changes to xml2rfc and related tools, but also to the infrastructure we use to keep copies of specs and their reference extractions.
> ...

That wouldn't work well for specs that are revised and published in sync
(such as QUIC and http-core).

The simplest possible approach for *that* use case is an extension of
<reference> that provides the location of the XML source; the formatter
can then read the source and derive the section number.

Best regards, Julian