[xml2rfc-dev] XML evolution (Re: v3 <seriesInfo> vs IMPNOTES vs canonical XML)

Carsten Bormann <cabo@tzi.org> Thu, 19 December 2019 17:26 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265E712089A for <xml2rfc-dev@ietfa.amsl.com>; Thu, 19 Dec 2019 09:26:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 TudBceHnh1mI for <xml2rfc-dev@ietfa.amsl.com>; Thu, 19 Dec 2019 09:26:04 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7385C1202DD for <xml2rfc-dev@ietf.org>; Thu, 19 Dec 2019 09:26:04 -0800 (PST)
Received: from [172.16.42.104] (p548DC893.dip0.t-ipconnect.de [84.141.200.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47dzLM0BG7z16Yh; Thu, 19 Dec 2019 18:26:02 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <e3e50137-0588-92bf-7b00-670588fea8e7@gmx.de>
Date: Thu, 19 Dec 2019 18:26:02 +0100
Cc: Heather Flanagan <rse@rfc-editor.org>, John R Levine <johnl@taugh.com>, XML Developer List <xml2rfc-dev@ietf.org>
X-Mao-Original-Outgoing-Id: 598469155.789414-d3f2ca70c63d92a2c18f5d148cfec84a
Content-Transfer-Encoding: quoted-printable
Message-Id: <810DB605-B5B6-4181-9BE9-83ED2BA6E849@tzi.org>
References: <dd955428-7129-c0e9-4064-ef963ada90c7@gmx.de> <159956F3-1DDA-436E-8565-689F4EA74609@rfc-editor.org> <6b631129-546a-0935-aeca-0ad31db47d62@gmx.de> <E98A6936-406B-4D65-A077-E23989CCA6B2@rfc-editor.org> <b6369b2c-61af-e948-ad87-da41bf581dbf@gmx.de> <e3e50137-0588-92bf-7b00-670588fea8e7@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/d-5qveVBPJfhKftZbLILz6nzTI4>
Subject: [xml2rfc-dev] XML evolution (Re: v3 <seriesInfo> vs IMPNOTES vs canonical XML)
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Dec 2019 17:26:06 -0000

On Dec 19, 2019, at 12:38, Julian Reschke <julian.reschke@gmx.de> wrote:
> 
> invalid

That points out a flaw of “validation thinking”:

There may be structures that are undesirable (deprecated, etc.), but should not trigger a validation failure (i.e., giving up processing).  If we want to evolve RFCXML over time, we’ll need this sooner or later.

I believe that structural immutability of published RFCs may be too high a goal; we of course want to keep a history of what has been published, but with something as complex, error-prone, and evolving (as in moving target) as RFCXML, it also may be necessary to fix bugs.

(I also think we should minimize those cases, and I’ll recognize that the current process is not conducive to minimizing them — that is a separate issue from the one I bring up here; it just makes being able to handle deprecation and fixes even more urgent.)

Grüße, Carsten