Could MultiMarkdown replace Word for lawyers?

An example of a cross-reference

I have a largely unpleasant history with MS Word. I avoid using it as much as I can (and when I do use it, I use it primarily because other lawyers we deal with are using it and I pause my resistance when it can cost me excessive time and money). It is, however, the staple in the legal industry and because LibreOffice is not quite as stable as I’d like it to be, I will continue to have MS Word installed on my laptop for a while still. That said, I am actively exploring alternatives to Word, primarily for document creation on my side and, lately, I am exploring the feasibility of switching my document creation process to plain text with MultiMarkdown syntax. I’m just not sure MMD can do what it would need to do to be a feasible option.

Why MultiMarkdown?

Word will still have a role when it comes to reviewing and commenting on documents exchanged with other lawyers. It has all the markup options and commenting features typically used by lawyers. I wrote previously about using Scrivener for my document creation and that remains one of the better options, just after LibreOffice and, possibly, Pages. The reason I am really interested in MMD as an option is that it is entirely platform and OS neutral. If the syntax to support the document complexity we require in many legal documents is possible in MMD, it becomes possible to create legal documents on any device that supports plain text. That is appealing for a number of reasons:

  1. It means that the cost of a “word processor” to do legal work drops to almost zero;
  2. It means that if you sync your documents to a location that can be shared between devices, you become truly platform agnostic; and
  3. Your risk of documents becoming unreadable over time drops to almost zero because plain text should always be readable and you may just need some sort of interface to translate the syntax.

What are the challenges?

Although the last stages of a document’s preparation and implementation will likely require Word-level reviewing and commenting tools (well, probably), legal documents can be created with just about any text editor or word processor that supports paragraph numbering and formatting, can be translated into a Word format (.doc or .docx) or even a PDF with commenting and markup features enabled (which opens the field a bit) and can handle a couple more complex functions which have become a pre-requisite for legal professionals.

It largely comes down to multi-level paragraph numbering and how referencing works in many legal documents. The starting point is a paper paradigm where legal documents are created with the intention that they are going to be printed out and still need to be functional. Because these documents often include internal references between paragraphs (usually this involves referring to one paragraph from another) and those references need to remain intelligible when printed out, the convention that has emerged is the one illustrated in the image with this post.

If documents were never going to be printed and could remain digital, then this referencing system could be replaced with internal hyperlinks which don’t need to be attached to dynamic paragraph references. In the current model it is important to be able to not only create a reference in one paragraph to another but to have that reference link capable of being dynamically updated as the paragraph being referenced changes position in the document. So, for example, in the image above, paragraph 2.1 includes a reference to paragraph 3.1. The reference in 2.1 can change if paragraph 3.1 is, say, moved lower down in the document to 4.1. When the document is refreshed, the reference in paragraph 2.1 will be changed to 4.1 and the link will remain effective (clicking on that link in 2.1 will take you to the paragraph it references).

The first question is whether it is possible to emulate this referencing model using MMD? It is obviously possible to create internal links in a document using Markdown and it’s forks but I tend to see those internal links being to paragraph headings more often than not. I saw something about internal links to specially tagged sections of the text (you can create footnote links in MMD, for example,), I’m just not sure if you can do something similar between sections of text.

The next challenge is extending the paragraph numbering syntax to accommodate multi-level numbering. Multi-level numbering can be painful if the structure becomes too complex (imagine a clause that extends down to 14.3.2.1.1) but it remains a common method of applying a hierarchical structure to legal documents with headings, sub-headings, paragraphs below each heading level and numbered lists thrown in for good measure. The numbering syntax in MMD seems to be fairly flat and goes up to 2 levels with bullets (not sure about numbered lists) but it would, ideally, need to be able to accommodate more complex paragraph numbering for legal documents. Well, I say that but I have also been thinking about changing that structural model and simplifying the numbered paragraphs somehow. Certainly, when it comes to Web-based documents, multi-level numbering just doesn’t work so I structure my documents using different heading levels, ordinary paragraphs and lists for the Web. If I didn’t have to cater for documents being printed, it would probably be feasible to move more towards a Web model but we are not quite there yet.

So the second question is whether MMD currently or could eventually accommodate this sort of multi-level hierarchy? I suppose a related question is just how much we need such a complex multi-level hierarchy in the first place, aside from being a sort of habit lawyers draw comfort from?

There are some moves in this direction, at least ones I have seen. One example I came across tonight is this tweet by Mike Linksvayer linking to something called Critic Markup which introduces a sort of annotation markup to plain text documents. It looks like this is already being integrated into MMD environments with support in MultiMarkdown Composer 2.1 beta.

MMDC Beta Demo Video from CriticMarkup on Vimeo.

Its still pretty rough but its in the right direction. So what I am researching is whether MMD could become a viable alternative, even if it is just to create the documents in the first place? Any thoughts?

Comments

7 responses to “Could MultiMarkdown replace Word for lawyers?

  1. Jenty avatar

    The first year I did the 365, I did it with a P&S. It worked just perfectly for me then, and allowed me to hone my composition etc without worrying too much about the settings.
    You should do the 365, it's fun!

  2. Mike Linksvayer (@mlinksva) avatar

    Hi Paul,

    I’d add to your list of advantages of a plain text format: it makes use with generic revision control systems (git & co) much more useful.

    Futuristic tangent: I wonder how a move to a plain text format might help or hinder “machine-readability” of legal documents? Not just their structure, but some amount of self-description through semantic annotation. I imagine that it might help, as high value documents could be annotated after their creation, or during their creation by dedicated experts, with firm checks on document integrity (see revision control).

    Retro tangent: I’m not sure what all is captured by “stable” re LibreOffice, but as a technically literate user I hope you report bugs when you find them. 🙂 I don’t think LibreOffice has ever crashed on me (narrow definition of “stable”), but it isn’t perfect regarding import and export of .docx, which I imagine would be a huge problem within the legal profession … but LO 4.0 is much closer to perfect than ever before, in particular adding support for comments on spans of text rather than just insert points (lack of such could make interpreting comments originally made on spans of text in MS Word difficult).

    1. Paul avatar
      Paul

      Hi Mike

      Thanks for your feedback. I think plain text should be more useful in the context of machine readable code. It’s lightweight, the format for code anyway (at least as far as the format for capturing code is concerned) and is probably the most future-proof.

      As for LibreOffice, I have attempted to log bugs once or twice in the past and I remember it being a pain and I gave up. I reverted to 3.6.5 and will probably return to 4.x when it is updated further.

    2. Paul avatar
      Paul

      Hi Mike, quick update that might interest you. I’ve just been talking to @nuclearpengy about GitHub today and that could prove to be an awesome way of achieving some of the things I want to do with our docs. I’ve started thinking about a LaTeX component for paper-based documents that look awesome and like paper docs but working primarily in MultiMarkdown through something like GitHub (or using Git in some other form).

  3. Tom avatar
    Tom

    Hi Mike,

    you should have a look at TextMaker, the word processor from SoftMaker Office. It has all the markup options and commenting features you need, and is seamlessly compatible to Microsoft Word formats of all kind. I don’t have any problem going back and forth. Interface is similar/familiar to that of MS Office 2003 (no ribbons), so there’s not too much of a learning curve. Coding is tight, and program is small and runs fast. Price is very reasonable (SoftMaker Office costs $69 for including three Licenses).

    Best reagrds

    Tom

  4. Jason avatar

    Hey Paul, if you like MMD but want more control over document formatting, check out RestructuredText (reST). It’s a lightweight markup language somewhat similar to Markdown, used mainly by Python developers for documentation. There’s a free open source editor called ReText that can handle Markdown (including MMD if I’m not mistaken) as well as reST.

    Here’s a link to a review of ReText: https://www.fossmint.com/retext-a-powerful-text-editor-for-markdown-and-restructuredtext/

    …and here’s a link to a comparison of Markdown and restructuredtext: https://www.jungledisk.com/blog/2017/01/20/restructuredtext-vs-markdown/

    To your original post, reST allows various levels of outlining, including Roman numerals. For lawyers (I’m an estate planning lawyer), reST shines if you like using templates. The reST standard syntax includes a replace function, so you can set up a template document with variable placeholders, write the replacement value strings once with the replace tag, and then when the document is rendered (all the pandoc formats — PDF, HTML, ODT, etc.), the variables are filled in. I hope this information helps.

    1. Paul avatar
      Paul

      Hi Jason, thank you for your recommendations! I use a number of apps that are focused on Markdown currently, although I’m interested in the differences between the two syntaxes.

What do you think?

This site uses Akismet to reduce spam. Learn how your comment data is processed.