My tool, RFCTool can accept input in Word, or Markdown or both. It is open source and runs on OSX, Linux and Windows.
I don't currently support diffs but I could and this is something I am planning to add at some point when I get round to the real purpose of the Mesh which is to support end-to-end secure social media (the service supporting the forums cannot read the contents of the forums).
RFCTool can generate output in any of the input formats. So it can be used to create a Markdown version of a Word document for comparison purposes. That would work in an OK way today but it could be made more robust.
Having written a dozen drafts that combine text, graphics, source code and examples, I think this approach is going to be essential in the future.
Most people in this thread seem to be asking 'how do I produce the documents I produce today in XML2RFCv3. That is the wrong question. You will quickly find you change the way you work because you want to produce different types of document.
You are not going to have a single input source file. You will have many. Some of those inputs will be generated by other tools. Consider for example, the Mesh schema draft.
The reason I can produce so many drafts by myself is that I am using a very powerful tool chain. This document actually has about 30 input files:
1) Base document (Word). This contains the bulk of the prose. Word document styles are used for paragraph, etc. markup. This provides me with spelling and grammar checking and a decent UI.
2) Examples. Data produced by running the reference implementation in a captive environment is converted to Markdown using Goedel Scripting.
3) Diagrams. These were produced using Viso but I was forced to switch to a modified version of GOAT because Viso can't produce the non standard SVG required and conversion is not viable.
4) Schema. I believe that the primary purpose of a schema language should be to document the serialization format. I use several schema languages of my own design. These also generate markdown output.
Machine generated output tends to be more consistent than human which is a major advantage when engaged in repetitive edit cycles. It is far from foolproof.
The point I am making here is that comparing diffs on the input files is really not going to be helpful when other people adopt similar approaches. The solution in my view is to create an output for the purpose of comparison.
On Thu, Nov 5, 2020 at 8:48 PM Joseph Touch <touch@xxxxxxxxxxxxxx> wrote:
On Nov 5, 2020, at 5:22 PM, Larry Masinter <LMM@xxxxxxx> wrote:Using Git to manage document edits also implies you've agreed to the input format.And that Git supports that format (e.g., text, for XML source).I don’t think Git can itself track Word diffs, e.g. If requiring Git manage edits is a criteria, you’ve walled the solution in (and it’s standing in 1970).Joe
