[rfc-i] [Tools-discuss] Recommendation 9 from Results and analysis of the survey of I-D authors on formats and tools

[Michael Richardson]

I am agnostic about commonmark vs kramdown.
I want to address the question of accepting markdown on the DT.

There are three aspects which mis-recommends this to me:
1) DT would have to be able to communicate errors back to the submitter well.
   Running the formatting, including the xml2rfc pass locally means that
   errors are communicating locally.
   So, my opinion is that accepting kramdown does not reduce any local complexity.

2) {::include }
   One of the things I like about kramdown, is the {:include} directive.
   This lets us keep the ascii art and other example diagrams in other files.
   This significantly reduces errors in updating example content.

   If we supported upload in kramdown, then we'd have to support upload
   of entire sets of files to be useful.

3) {::include } is insufficient.
   We have a bunch of other content: code examples, yang modules,  etc.
   which have so far been rather annoying to get in, and I wrote a perl
   script to insert the right <CODE BEGINS>, <figure><artwork>, and
   also to pick the right YANG version YYYYMMDD stuff.

   I think that getting all this right in whatever markdown format would
   take several iteration of tool improvements, and we have only just
   gotten to XMLv3.
   XMLv3 gets this all 'right' now, but I think that we aren't even close
   to 100% submission as XML.

--
Michael Richardson <mcr+IETF at sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20210206/8f2dacfa/attachment.asc>