Optional syntax

Spec
5

One way to structure different editions of CommonMark is this:

Specification Levels:

CommomMark Barebone, Core, and Extended comes as both a specification and an implementation. Only CommonMark draft comes as a specification sheet only (as a wiki?). Anything written in a lower number specification can be rendered in a higher number.

  1. CommonMark Barebone := The most minimalistic specification. Designed to be most computationally efficient. Uses only the most commonly used markups. E.g. Here is a tiny implementation of markdown: micromarkdown

  2. CommonMark Core := Is considered the base standard. This will cover 80% of all use cases. If an extension is used in too many CommonMark Extended package editions, then it should probably be in core.

  3. CommonMark Extended := Most complete officially implemented specifications theoretically. It is a set of packages, aimed at different audiences with a mix of extensions relevant to a field. Examples shown below:

  • Scholar :~ Supports extensions often requested in academia like Figure tags
  • Film Script :~ Stuff useful for those storybording or film scripting
  • Coder :~ Stuff useful for programmers documentation
  • Etc… you get the point.
  1. CommonMark Draft := This specs is like the ‘w3 draft specification’ sheets. It is not implemented anywhere, but is there to be revised over and over again by the community (via a wiki?) until it is ready to be implemented in CommonMark Extended. (But at the very least, it will lets other implementers know ahead of time how to write their semi-fork. E.g. the moz- prefix for HTML/CSS specification drafts in firefox)
  • Perhaps every month, the wiki is generated as a pdf and stamped with a version number, so that people can say they are compliant to CommonMark Draft V2.XX etc… for non officially supported implementation.

Fail Gracefully

In html specification. A key philosophy is to fail gracefully. So for CommonMark, if you render using a lower implementation, it should still come out as legible writing. This comes though writing higher order syntaxes carefully in such a way that it can fall back into other forms of rendering in lower levels, that will come out as aesthetically and contently pleasing enough.

e.g. !youtube[Cat Video](https://www.youtube.com/watch?v=dQw4w9WgXcQ) will gracefully die like this " !youtubeCat Video ". Where the older parser will still parse []()