Re: [Tools-arch] Recommendation 6: Architectural model for clients

[John Levine <[e-mail]>]

It appears that Martin Thomson  <[e-mail]> said:
>On Wed, Apr 28, 2021, at 07:50, John R Levine wrote:
>> tool failure.  The authors I've talked to feel rather strongly that they 
>> like Word and are not interested in switching.
>
>That's a failure on our part then.  That process is not a good result for anyone involved.
>
>It is relatively easy to use word to drive a process that produces XML.  The one I used recently involves all the same
>command-line tools, but with a step that converts the word into markdown.

In principle, it's straightfoward to translate Word files into other
formats. (The file format is ISO/IEC 29500, a bunch of XML files in a
zip archive. The bad news is that the spec is over 5,000 pages.)
We could build tools to turn Word files into our dialect of
markdown or XML, give or take some negotiations about stylesheets
and markup conventions.

On the other hand, I expect that people who don't want to write
documents in markdown wouldn't be too enthusiastic about reviewing
them in markdown, so before setting off on a project like this I would
want to understand what's going to work for our Word users for the
entire document production process. Maybe it's two way Word <->
markdown, maybe something else. We have a fair number of markdown
users, so if we're building tools that deal with markdown, it would be
nice if they found them useful, too.

This is why I like Jay's approach of trying to figure out what our I-D
authors actually do from writing to editing to AUTH48 to RFC, and see
what the gaps are before trying to guess what tools to update or
create. Also, how are people are likely to use them, e.g., do we want
stuff that runs on our own PCs, or on a web site, or maybe build them
with an API that can be driven either through the web or a command-line
stub.

R's,
John

> I just got an XML diff from the RPC in AUTH48.

Are you sure it wasn't a text diff of the XML?  That works OK if the
incoming XML is in a format close to what the RPC uses, not so great
otherwise.