Standardization Woes

For many people, Markdown is the front and center of their textual workflows, and rightfully so.

Comes Jeff Atwood and says that Markdown needs standardization to become even more useful because, come standardization, 15 Markdown processors wouldn’t create 22 different results of the same source (or maybe it was the other way round).

This has caused a lot of discussion, mostly around the naming of the standardization project, less so about the question whether it really makes sense to standardize in the first place.

Personally, I’m not so much interested in trademark discussions. My primary interest is the standardization goal as such. In other words, is there really a point for a standardization effort, given that the tool landscape for Markdown-related tools is arguably thriving.

So, what is the use case for the standardization, what comes out at the other end that substantially benefits the users of Markdown? Or else, could it be that the standardization effort is not so much aimed at the benefit of the users but at the convenience of the creators of Markdown tools?

Dunno, the participation of John MacFarlane (who is the original author and maintainer of pandoc) in the standardization initiative may be an indication that the latter question could be key to understanding the motivations behind the project.

In this article, I’m trying to identify the potential use cases that may be taken as a motivation for a standardization effort.

So, here is a list of use cases that may benefit from the existence of a standardized Markdown along with some personal comments.

Markdown files are exchanged between several users

This case describes a scenario where Markdown sources are shared, or exchanged between a group of authors. I would assume that, in the absence of a standard, it seems totally feasible to agree on a commonly agreed toolchain for the processing of the sources.

To some extent, this is similar to the creation of a software project in C. Especially when it comes to the deployment to an embedded platform it is necessary to come to agreements about the applicable tool chain, whether the underlying language is standardized or not.

For practical purposes, a standard would be nice but far from being indispensible.

Same source is processed in different toolchain for different purposes

Again, I’m not sure.

Granted, I (for example) use different tools that may or may not produce the same output on the same piece of Markdown source. But the thing is that these tools cover different areas and therefore the situation that they would all be taken to process one specific piece of Markdown is not very realistic.

One example for this is the usage of tables. These may (for example) be relevant for creating a blog post or a scientific paper. But, on the other hand, for keeping a daily journal of your activities a table is probably of secondary interest.

Don’t want to remember which markup flavor to use in which tool chain

This is basically the opposite situation to the first use case where many authors work in one tool chain. Here, one author works with multiple tool chains.

In this situation, people may not like the idea to distinctively consider which specific style of markup to use in different authoring tools and post-processing toolchains executed for the different purposes of their writing.

Admittedly, this concern may hit home, or some kind of home. On the other hand, the same situation comes up if you (have to) work in two different flavors of the same programming language, like Python 2.x vs Python 3.x.

And if you like it or not, the existing chasm between different flavors of Python (or Ruby, for that matter) is the result of moving a living standard forward. This may come with breaking changes.

Let’s assume that a standard definition of Markdown exists and that, after some time, this definition needs to go forward to meet future requirements. Then, the probability of Markdown creators ending up in pretty much the same situation as today is certainly non-negligible.


To summarize, after considering these cases I’m personally still fine with the current situation and the tools available for various purposes. I guess we’ll see what comes out at the other end of this “standardization” effort and whether there’s any benefit for the rest of us.