Subject: Re: [Rfced-future] My hard constraints

From: John C Klensin <[email-masked]>
Date: Tue, 01 Sep 2020 16:08:01 -0400

--On Friday, August 28, 2020 17:34 -0700 Joseph Touch
<[email-masked]> wrote:

> 
> 
>> On Aug 28, 2020, at 4:03 PM, John R Levine <[email-masked]>
>> wrote:
>> 
>> To perhaps clarify, I think that xml2rfc is an OK publication
>> format because of all the semantic tagging, but it's a
>> terrible authoring format. If it were up to me (and I had
>> 20/20 hindsight) I would put more effort into thinking about
>> the entire document creation process and better tools to let
>> people use the editing tools they use for other stuff.
> 
> That's why I support the Word format, FWIW.
> 
> I understand the back-end pubs process is harder when it goes
> to RFC, but that's a 1x investment. Word (or word-like, e.g.
> OpenOffice) makes it impossible to generate "non-compiling
> XML" that can't easily be untangled.

I think I've already commented on a different aspect of this and
am still trying to sort out how to explain what I think is an
even more basic problem, but...

The big advantage of Word and its ilk is that it is more or less
WYSIWYG.  Many of us who dislike Word dislike it because it
tries to infer what you want to see, sometimes gets that wrong,
but is unwilling to be overridden about it, at least in any
obvious way.  Vint has referred to some such systems as
"WYGIWYIG" (what you get is what you get).  And, because one is
editing both text and page layout at the same time, sometimes
going to a different format works well and sometimes it doesn't.
So-called generic markup systems, going back to GML and SGML,
are intended to take page layout and similar decisions out of
the hands of authors and move them to experts on those subjects
(plus or minus so-called style sheets, which are also things
that experts should probably be designing.  And, again,
switching styles in Word for different presentation arrangements
sometimes works... and sometimes doesn't, perhaps depending on
understanding them and their implications much more deeply than
seems typical of Word users.

And, while Word can export something XML-ish (and, with some
versions, that is the default) that will never be as
satisfactory as true generic markup because, at best, it is
using more or less complicated, and more or less accurate,
heuristics to get from a presentation form (e.g., a string in
italics) to information about what it actually is (a book title?
a string in a different language that one wants to set of?  A
form of emphasis?  In the most general of cases, only the author
knows what was intended.  In that sense, the long-ago choice of
ASCII text was about stability by deciding on certain types of
layout (US-format pages, although some special decisions were
made to accommodate A4).  A decision to go with PDF/A is a
similar sort of decision -- very specific layout.  HTML does not
avoid forcing us into a box; it is just a different box and on
for which, maybe, more kinds of devices have been optimized and
more people have gotten used to the rough edges.   And, in an
ideal or even reasonable world, one does not try to author
documents in either.  When we decided we wanted to be able to
display output reasonably well on other types of devices --very
different ones-- then generic markup, with either
author-specified elements or some person iterating on element
definitions with the author, is a necessity [1].  And, of
course, it is possible to design editing tools that are far more
friendly to, e.g., XML with a particular schema than either
generic XML editing tools, my emacs/epsilon macros, or just
writing markup in an ordinary text editor.

For those who like Word (or anything similar), it seems
perfectly reasonable (if we are willing to incur the costs
which, so far, we've said we are) to use it to generate
plausible output files, hand those output files over to the RPC,
and have them convert those files to acceptable XML2RFC format,
with or without the aid of markdown and asking the author
questions if needed.  That is more or less what publishers who
accept typescript (or Word) have been doing since many of them
shifted to SGML three decades ago as part of the process leading
to page layout.  But let's be clear that is what we are doing
and talking about.  Otherwise, it a choice between discussing
how to find or make better tools for creating and editing the
specific XML2RFC schema or abandoning the idea of
multiple-format output. 

Finally, to predict part of the explanation I'm having trouble
putting together without a message longer than anyone will read,
I assume that everyone reading this knows all of the above
already, can discuss the tradeoffs between XML and other SGML
dialects for publications, has an in-depth understanding of the
difference between format and generic markup and the tradeoffs
involved, etc.

    best,
     john

[1] Markdown is a different way to get there, but with far more
knowledge of how to derive XML from RFC formats than is possibly
with a generic tool like Word)

---

From: "John R Levine" <[email-masked]>
Date: 1 Sep 2020 16:56:21 -0400

On Tue, 1 Sep 2020, John C Klensin wrote:
> a string in a different language that one wants to set of? ...

Word has a very powerful stylesheet feature so you can define styles for 
semantic tags for titles of code or whatever, and they're visible to 
export tools.  At least 20 years ago the publisher wanted to put a CD in 
one of my books which had all of the contents and screen shots as HTML 
pages.  The text was all written in Word, a file per chapter, so I 
exported the Word files as RTF (this was back when Word's native format 
was undocumented tokens), and wrote some perl scripts that read the RTF 
and turn it into HTML files with suitable links and tags and so forth. 
It worked because it was my own Word, edited by editors who understood 
that the style tags needed to be there and the figure links needed to be 
in a fixed format, but it was extremely fragile.

The problem with this approach is that very few Word users actually use 
styles beyond section headers to get the TOC and I doubt we can change 
that.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: John C Klensin <[email-masked]>
Date: Tue, 01 Sep 2020 19:38:56 -0400

--On Tuesday, September 1, 2020 16:56 -0400 John R Levine
<[email-masked]> wrote:

>> italics) to information about what it actually is (a book
>> title? a string in a different language that one wants to set
>> of? ...
> 
> Word has a very powerful stylesheet feature so you can define
> styles for semantic tags for titles of code or whatever, and
> they're visible to export tools.  At least 20 years ago the
> publisher wanted to put a CD in one of my books which had all
> of the contents and screen shots as HTML pages.  The text was
> all written in Word, a file per chapter, so I exported the
> Word files as RTF (this was back when Word's native format was
> undocumented tokens), and wrote some perl scripts that read
> the RTF and turn it into HTML files with suitable links and
> tags and so forth. It worked because it was my own Word,
> edited by editors who understood that the style tags needed to
> be there and the figure links needed to be in a fixed format,
> but it was extremely fragile.
> 
> The problem with this approach is that very few Word users
> actually use styles beyond section headers to get the TOC and
> I doubt we can change that.

John,

Thanks.  That is consistent with what I was trying to say; the
details are appreciated.  Having tried to do some things with
RTF many years ago and trying unsuccessfully to adapt styles to
things I needed (yes, beyond a TOC) more recently, you have my
admiration as well.

    john