Subject: Re: [Ietf-and-github] [rfc-i] New Version Notification for draft-kwatsen-git-xiax-automation-00.txt

From: Kent Watsen <[email-masked]>
Date: Fri, 8 Mar 2019 20:39:03 +0000

Hi All,

I hope that this work seems interesting to you.   I don't actually know, as there have been no comments to the effect yet.   Maybe folks are reserving comments for a presentation in Prague, but unfortunately I won't be able to make Thursday's WG session.

Assuming this work is interesting, is this the right forum for it?   I think this work is covered by the "git" charter (tooling, automation, best practices, etc.), and it has high-potential for affecting the xml2rfc format, but maybe there's a better home?

Lastly, what steps need to be taken to have a solution everyone is happy with?   I'm assuming standard RFC publication process, but are there any special considerations that need to be observed given that it's a tool for the community?

Regards,
Kent

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 8 Mar 2019 22:08:35 +0100

Hi Kent,

On Mar 8, 2019, at 21:39, Kent Watsen <[email-masked]> wrote:
> 
> I hope that this work seems interesting to you.   I don’t actually know, as there have been no comments to the effect yet.  

I now remember why I immediately forgot about xiax after having seen it:
It just does not apply to my workflow.

I do work in a strictly functional way.  There is a number of source files, and there is a Makefile (and possibly other configuration documents), which all are in version control and edited by humans (“precious”). The Makefile employs various tools to build (expendable) intermediates, run tests on them etc., and then finally the .txt file for submission.
The .xml file of course is also built as an intermediate (and will become more important in v3), but really the point is that I would never edit it; it is the result of a functional process.

The process as described has the disadvantage that it is more applicable to people who do software development (which, if somewhat state of the art, generally happens in the same way).  There might very well people who are comfortable with a mutating approach to draft generation (and, backed up with version control, that is probably quite workable).  It’s just not something I can very well comment on.

Being able to extract embedded code from an XML file is indeed important for me; please see Section 1.3 of RFC 8152 for an example of how this can be done with widely deployed tools.
I expect the RFC repository will at some point provide online versions of such tools.

Grüße, Carsten

---

From: Kent Watsen <[email-masked]>
Date: Sat, 9 Mar 2019 17:48:57 +0000

Hi Carsten,

> It just does not apply to my workflow.

But I think it does (see below)

> The .xml file of course is also built as an intermediate (and will become more important in v3), but really the point is that I would never edit it; it is the result of a functional process.

My workflow is the same as yours.   This proposal represents my 3rd generation of tooling to solve this problem, but it's taking it to the next level now.  Not only does this proposal support automated construction (what you describe), but it also supports automated verification, which I know doctors, shepherds, and copy editors have been pining for.

> The process as described has the disadvantage that it is more applicable to people who do software development (which, if somewhat state of the art, generally happens in the same way).  There might…

You may have misunderstood the proposal.  Here's the link again: https://tools.ietf.org/html/draft-kwatsen-git-xiax-automation-00 <https://tools.ietf.org/html/draft-kwatsen-git-xiax-automation-00>.

> I expect the RFC repository will at some point provide online versions of such tools.

Feeding XPaths into extraction tools just scratches the surface of what's needed for a formal reviews.  This proposal not only extracts the inclusions, but also the unit-tests created by the authors for testing the inclusions.  This approach has the advantage of enabling reviewers to just review the correctness of the provided unit tests (and their output), rather than writing testing code from scratch, assuming they're able to, which is unlikely for copy editors, who would undoubtedly be thrilled to programmatically verify changes made during AUTH48.

> Grüße, Carsten

Thanks,
Kent