OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

 View Only
Expand all | Collapse all

RE: [tosca] Using Markdown for collaborating on the TOSCA 2.0 spec

  • 1.  RE: [tosca] Using Markdown for collaborating on the TOSCA 2.0 spec

    Posted 02-24-2020 20:14




    Hi TOSCA-teers,
     
    Briefly, as you know, the OASIS TOSCA system-of-record is the OASIS document site, email reflector, etc. Your chairs could also easily request a closed TC Github from OASIS staff that would limit contributions
    to just TC members, as well.
     
    Naturally, Technical contributions should ONLY come from OASIS TOSCA TC members who have the right to make that contribution. That does not preclude small groups of TC member collaborators working on specific
    tasks from working offline using tools like Google Docs, of course.
     
    That said; in my personal experience, the collective cycles lost in the rathole of evaluation and discussion, consensus, then conversion and integration of the different tools in a fashion that is agreeable to
    the consortium, the TC process (and the TC members themselves) are often never fully recovered.
     
    For these reasons and more, there is a certain value in sticking with MS Word supported file formats, not least that MS Word is already understood and used for complex documents such as specifications (and even
    1,000+ page novels) by millions of people around the world; also making it easy for newcomers to dive right in.

     
    Regards,
    Paul
     
     
     
     
     
     
     
     
    From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org>
    On Behalf Of Tal Liron
    Sent: Sunday, February 23, 2020 5:49 PM
    To: tosca@lists.oasis-open.org
    Subject: [tosca] Using Markdown for collaborating on the TOSCA 2.0 spec
     


    The best option I've found is
    StackEdit .


     


    The learning curve was gentle and it seems to be able to do almost everything we need, though there are a few gotchas. (There are a lot of gotchas with the Word document, too, of course!)


     


    For our Tuesday ad-hoc meeting I can do a demo of it. We can discuss all these details here or in the meeting:


     




    It's entirely offline browser-based (and
    open source ), so anyone should be able to use it. Actually, the entire workspace is stored locally and can include many Markdown files organized in folders, including previous revisions and comments.
    The commenting system is quite nice, in some ways easier to use than in Word. Any comment starts a "conversation" that anyone can respond to. It works by storing the conversation as extra data embedded in a comment within the Markdown file.
    There's even a built-in diff tool, so if you look at one of the older revisions in the history and quickly see what has changed between that and the current revision.
    It can synchronize your local workspace with Google Drive, Dropbox, CouchDB, and GitHub. I could not get it to work with my GitHub, but Google Drive seemed extremely easy to use, and it depends on Google Drive permissions, so it's easy to allow anyone to view
    but only grant some people an edit permission. All the files sit in the drive and are pretty much standard Markdown, so that they can be downloaded, rendered into HTML/PDF/Word, published on a web site, etc.
    Converting the current spec to Markdown would be fairly easy. I simply opened the docx file in LibreOffice and copied-and-pasted into StackEdit. Much of the formatting was automatically converted to Markdown. Tables are a bit trickier, but also not hard to
    manage. I converted Chapters 1 to 3 with little trouble.
    Cross-reference links are a bit tricky. The best method I think is to create anchors using some kind of convention, e.g. "section-1.2.1.1". Of course if the sections are moved around the references would have to be updated. But, since these are simple text
    files, it wouldn't be hard to create a custom tool (in Python?) to search-and-replace. (By the way, the Word doc right now has a few orphaned references. Our Python tool could find such orphans and warn us about them.)
    Including images is on the one hand awkward, but on the other hand straightforward. You can use any image URL in Markdown, but that means we will need to serve them from somewhere. One possibility is to use our TC GitHub repos, which can be easily made to host
    publicly (via GitHub Pages). If we can get StakEdit to work with GitHub then it would be especially easy.

     









  • 2.  Re: [tosca] Using Markdown for collaborating on the TOSCA 2.0 spec

    Posted 02-24-2020 21:49
      |   view attached
    On Mon, Feb 24, 2020 at 2:13 PM Paul L. < paul.lipton@live.com > wrote: Naturally, Technical contributions should ONLY come from OASIS TOSCA TC members who have the right to make that contribution. That does not preclude small groups of TC member collaborators working on specific tasks from working offline using tools like Google Docs, of course. That is exactly what is being discussed: an offline tool to improve collaboration. The tool can export a very clean Word document (and a PDF, and an HTML page) that can become the statement of record. I am attaching an example of such an output. For these reasons and more, there is a certain value in sticking with MS Word supported file formats, not least that MS Word is already understood and used for complex documents such as specifications (and even 1,000+ page novels) by millions of people around the world; also making it easy for newcomers to dive right in. Text files, I would argue, are even more readily understood, and definitely easier to process by tooling. Our situation is that we have just a handful of contributors working on one big, extremely unwieldy Word document. The process has not produced great results: the spec is riddled with errors and inconsistent formatting. This is a serious problem not just for the English text, but also for the embedded TOSCA and YAML code. The only way we can do quality control currently is by manually copying YAML back and forth to other tools. There are likely various reasons for all these problems, but I can say that from my perspective the huge Word document is a source of dread and an obstacle to improving TOSCA. I'm certain that working with text files will allow us to put together a much better final result. Please also note that some of us work for open source companies (me!) and do not have access to Microsoft Word. And Word itself is not free: it is in fact quite expensive. The current process is immediately discriminatory. Attachment: 3. TOSCA definitions in YAML.docx Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document

    Attachment(s)