Re: [Tools-discuss] Why post text and not XML? (was: I-D statistics)

Toerless Eckert <tte@cs.fau.de> Sat, 16 March 2024 21:57 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9EBC14F619 for <tools-discuss@ietfa.amsl.com>; Sat, 16 Mar 2024 14:57:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.658
X-Spam-Level:
X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8bLC_znH1Lf for <tools-discuss@ietfa.amsl.com>; Sat, 16 Mar 2024 14:57:43 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75054C14F618 for <tools-discuss@ietf.org>; Sat, 16 Mar 2024 14:57:43 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 4Txw2q5X5JznkQS; Sat, 16 Mar 2024 22:57:39 +0100 (CET)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4Txw2q4jctzkn7G; Sat, 16 Mar 2024 22:57:39 +0100 (CET)
Date: Sat, 16 Mar 2024 22:57:39 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Carsten Bormann <cabo@tzi.org>
Cc: Eric Rescorla <ekr@rtfm.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Michael Richardson <mcr+ietf@sandelman.ca>, tools-discuss <tools-discuss@ietf.org>
Message-ID: <ZfYV05Ij_PPbJTS_@faui48e.informatik.uni-erlangen.de>
References: <1952067F-6467-4BEC-9CA5-BB8B16FA662B@tzi.org> <14807.1709682543@obiwan.sandelman.ca> <effb521c-1e20-cff8-acd3-17212a6b3fb9@gmail.com> <447A96F55A3D36851570B3B6@PSB> <60f18950-a2e0-16be-3a05-33f9a637062d@gmail.com> <CABcZeBPzYvscB3yeaRYQg6waR1BvqQMhJ+GpoKAZThoDvREs+w@mail.gmail.com> <ZfYOMEGdrGaz3BXB@faui48e.informatik.uni-erlangen.de> <512D8379-8E25-4FA6-B533-B872003126C2@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <512D8379-8E25-4FA6-B533-B872003126C2@tzi.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/vOYWrao45lm8gZxm1MLnARy0Lgc>
Subject: Re: [Tools-discuss] Why post text and not XML? (was: I-D statistics)
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-discuss/>
List-Post: <mailto:tools-discuss@ietf.org>
List-Help: <mailto:tools-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Mar 2024 21:57:47 -0000

On Sun, Mar 17, 2024 at 07:33:57AM +1000, Carsten Bormann wrote:
> Toerless,
> 
> we do have crefs in RFCXML for exactly this purpose: editors' comments, properly highlighted as such (and switchable with comments=no, although the anti-PI crusade may have made this harder in RFCXMLv3; I haven’t tried this in RFCXMLv3 yet).

How do i create such 'crefs' from markdown ?

> The purpose of an issue tracker is to make the submission of comments and their discussion available to people beyond the authors.  Yes, you tie yourself to the git forge that you are using, which doesn’t need to be GitHub, although that happens to be awfully convenient.

A github issue or pull discuss is a process. The result of this
could/should be an inline comment, maybe even with backreference to the issue/pull.
Aka: both have different purpose and could well co-exist/help each other and
improve the creation/tracking process.

> It’s 2024, get WiFi for your flight.

I had a perfect flight getting at midnight into a plane in SFO, sleeping for
6 hours, having a meal and a movie for 2 hours, sleeping for another 6 hours
and arriving at 6:30 AM in Brisbane. I only got to do work whole at the beach
later ;-))

(i was just was checking those terrible flight routes/times from Europe after all the
 horror stories i heard yesterday at the hackathon).

> (And maybe we should be investing on the tool that makes issue backups today; but the point is that you really want to be able to join the discussion of each issue, not just read only.)

I very much like github process. I struggle figuring out, how to best
keep discussions on WG mailing list and github in-sync. I think/fear
that we would have to provide drops from github to mailing list upon
closure of pull/issues, so instead of that the comment in the document itself
might be another way to keep track of such "WG work" that happened on github
instead of the mailing list. Thats why i started to get interested in this thread.

Cheers
    Toerless

> Grüße, Carsten
> 
> 
> > On 17. Mar 2024, at 07:25, Toerless Eckert <tte@cs.fau.de> wrote:
> > 
> > How do you make offline copies of github issues to read while
> > flying to Australia or preparing for Microsoft to disband github ?
> > 
> > To me this is like buying an eBook from Amazon just to know that Amazon
> > will at some point in time delete it from my (Amazon) eReader for whatever reason.
> > 
> > I would rather prefer if there was a way if our tool chain to render output
> > with or without comments included and being able to express that in markup. I for once
> > would like to be done with touching XML myself (read or write).o
> > 
> > Cheers
> > Toerless
> > 
> > On Sat, Mar 16, 2024 at 01:50:50PM -0700, Eric Rescorla wrote:
> >> On Sat, Mar 16, 2024 at 1:36 PM Brian E Carpenter <
> >> brian.e.carpenter@gmail.com> wrote:
> >> 
> >>> John,
> >>> 
> >>> Thanks for explaining.
> >>> 
> >>> In line...
> >>> 
> >>> 
> >>> On 17-Mar-24 07:51, John C Klensin wrote:
> >>>> 
> >>>> 
> >>>> --On Saturday, March 16, 2024 17:13 +1300 Brian E Carpenter
> >>>> <brian.e.carpenter@gmail.com> wrote:
> >>> 
> >>>>  =================
> >>>> 
> >>>> For anyone interested and in the hope of not having to repeat
> >>>> this again...
> >>>> 
> >>>> Especially for long, complex, and long-lived documents,
> >>>> especially those that are replacements, significant updates for
> >>>> earlier documents, or merges of others, I use extensive comments
> >>>> in the XML to track changes and decisions.   Other comments are
> >>>> used to provide information to, or prepare for discussions with,
> >>>> the RPC about why particular text phrasing and constructions or
> >>>> document organizations were chosen, etc.  With one current
> >>>> document, those comments add up to more that 30% of the size of
> >>>> the XML file.  Some of those comments are over 20 years old and
> >>>> have been carried forward from xml2rfc v1 files associated with
> >>>> previous documents.
> >>> 
> >>> Understood. The "modern" approach is of course to embed such
> >>> comments in GitHub issues, which tends to lead to self-censorship
> >>> of any "unkind" comments, and then the nit-picking takes place
> >>> on GitHub too.
> >>> 
> >> 
> >> I don't much care about the comments, but I would observe that a
> >> consequence of having the XML kept private like this is to make it
> >> more difficult for others to work on the documents, either by submitting
> >> diffs to the text or by forking them and making their own documents.
> >> 
> >> So in that respect, I think the "modern" approach truly is superior,
> >> though of course it's not the only way to obtain those benefits.
> >> 
> >> -Ekr
> > 
> >> ___________________________________________________________
> >> Tools-discuss mailing list - Tools-discuss@ietf.org - https://www.ietf.org/mailman/listinfo/tools-discuss
> > 

-- 
---
tte@cs.fau.de