Re: Too many tools, was Things that used to be clear

John C Klensin <john@jck.com> Sat, 13 July 2019 03:25 UTC

Return-Path: <john@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7872120086 for <ietf@ietfa.amsl.com>; Fri, 12 Jul 2019 20:25:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 bLR7TW-geoRb for <ietf@ietfa.amsl.com>; Fri, 12 Jul 2019 20:25:57 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F450120075 for <ietf@ietf.org>; Fri, 12 Jul 2019 20:25:57 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john@jck.com>) id 1hm8fb-00058Q-Hb; Fri, 12 Jul 2019 23:25:55 -0400
Date: Fri, 12 Jul 2019 23:25:50 -0400
From: John C Klensin <john@jck.com>
To: John Levine <johnl@taugh.com>, ietf@ietf.org
Subject: Re: Too many tools, was Things that used to be clear
Message-ID: <E966B6C1DB5ECABA0BDFF946@PSB>
In-Reply-To: <20190713014652.B9DE64A57BC@ary.local>
References: <20190713014652.B9DE64A57BC@ary.local>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/tEDNqG0qRN3YbWPiHOghZJYXBiI>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Jul 2019 03:26:00 -0000


--On Friday, July 12, 2019 21:46 -0400 John Levine
<johnl@taugh.com> wrote:

> In article <20190710190507.GI3215@localhost> you write:
>> Yeah, it does seem lik the XML hate is mostly just that, but
>> that our use of XML is not really a blocker.  But these are
>> feelings we're talking about -- all subjective.
> 
> I think the practical difference is between a toolset that is
> unique to the IETF and one that is more widely used.
> 
> It is utterly unclear to me whether better bridge tools would
> help.  I am pretty sure that with enough effort I could write
> a two-way converter between xml2rfc and a Microsoft Word file
> with suitable stylesheets and macros.  (It'd be a lot harder
> than what Joe has done.)  So you could edit stuff in Word, and
> revise by importing xml2rfc into Word and then exporting when
> you're done.  But would anyone use it?

The answer to the specific question is probably a subset, maybe
a large subset, of those who are using Joe's tool.  I don't have
a clue as to how many people it would attract from markdown.

But it seems to me that there is a generic problem in much of
this discussion.  The original motivation for xml2rfc (see the
introduction to RFC 2629) was to allow enough descriptive markup
to facilitate RFC production and permit element identification
for other purposes.  If one generalizes a bit from that, one
gets to the motivation for SGML itself: allowing authors to
describe the elements of a document well enough that someone or
something else can deal with formatting, page layout, and a
variety of stylistic issues in a way that produces reasonable
results. As an aside, at least some SGML purists argued that
giving authors control at the formatting level was not only a
poor use of their time but that it encouraged evil behavior.
That particular approach is particularly important if one wants
to produce a variety of different output formats from a single
source document, something that was definitely not part of the
program for RFC 2629 but is critical for the new format setup
and xmlrfc v3.

Perhaps unfortunately, most of us at one time or another want to
mess with formatting and layout. Carl and Marshall were quite
careful about that, introducing some elements that were clearly
about low-level formatting but being rather clear that most of
them were kludges and they knew it.  Whatever the other
strengths and weaknesses of v3, elements like <strong> and <sub>
are format markup.  Go very far in that direction (and I'm
trying to remain agnostic about whether the right choices were
made) and one ends up back to nroff.

Where this relates to the above is that formatting engines, even
those with style sheets, don't provide, other than
heuristically, anything other than format-level behavior and
markup.  Relative to the expectations of identifying material by
its nature and application of generic markup, there isn't a lot
of difference among Word, nroff, TeX and LaTex, etc.  Getting
from generic markup to one of them as an intermediate step to
layout and formatting is fairly straightforward.  The historical
RFC Editor path of xml2rfc input -> nroff -> final documents is
a rather good example.   But getting from final documents for
format/layout material back to generic markup is a dicey
business that is going to fall into the "sometimes it works and
sometimes it doesn't" category.

How important that is depends on what one wants and expects.

   john