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

Hi Carsten,

>> 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.

But I think it does (see below)

> 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.

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 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.

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>.

> 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.

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