Punchline: variants and processor (text/markdown)

[Fletcher T. Penney]

On 7/15/14, 9:26 AM, Sean Leonard wrote:
 >> What is the goal here? Is the goal to have most Markdown documents on
 >> the internet be annotated in this way so some browser software can
 >> pick automatically a sort-of compatible implementation for a given
 >> document? Or is it a way to have inside a given system (a CMS for
 >> instance) a way to annotate which Markdown implementation to use
 >> internally to parse a specific document?
 >
 > Definitely the latter--for a system like a CMS to store the Markdown
 > content with metadata, so that it can parse a specific document in a
 > specific way. Perhaps more importantly than storage, it is meant for
 > interchange--like when you export content from one CMS to another CMS.
 > Presumably, most CMSes will use one parser for its (public)-facing
 > implementation. In that case the parameters are implied. But when you
 > export data from that CMS (and import it into another CMS), it would be
 > very useful to record what Markdown features were used, so that the new
 > CMS can interpret the data the ways in which the original users intended
 > for it to be understood.
 >


It seems, then, that the place to focus effort is to create a CMS that 
is "multilingual" when it comes to Markdown variants.

My suspicion is that no current CMS developer is going to go out of 
their way to modify their system so that it can automatically support 
multiple flavors of Markdown.  Nor do I think that is a particularly 
useful thing for them to do.

Instead, a good CMS should allow the administrator to change which 
processor is used to convert raw text into HTML.  When I experimented 
with Moveable Type, I had to create a tool to allow me to use 
MultiMarkdown (for obvious reasons that is my preferred variant...).  It 
was important to me, so I did it.  The only thing I felt that MT was 
"responsible" for was to allow me to customize this.

I'm left to believe that if you want such a CMS, it will be up to you to 
create it, or to modify an existing CMS to support this.  You could 
presumably create a MT plugin that reads a central preference, and 
"calls out" to the specified Markdown processor of your choice to handle 
formatting.

I don't think it's realistic to expect that all, or even a significant 
minority, of available CMS packages are going to support this.  Your 
best bet is to implement this "bottom-up" by creating plugins to manage 
this on your own.  I don't see where any sort of an internet "standard" 
is necessary.



IMHO, a much more useful standardization effort is to continue to 
develop test suites with as many edge cases as possible to help with 
consistency in how the various flavors handle "standard" Markdown syntax 
structures.  As I've suggested in the past, I think it would be useful 
for there to be agreement on:

* "Standard" Markdown -- the features in Markdown.pl, with appropriate 
bug fixes

* "Common extended" Markdown (or whatever it would have to be called) -- 
features that are commonly added that are easily standardized (e.g. 
footnotes, not using underscores in the middle of words, whatever).  The 
list of features in this category should be quite short.

* Everything else --- you want a symbol for inserting pink bunnies?  Go 
for it.  But no one else is likely to follow suit.

This would allow users to know whether a given flavor passes either the 
"standard certification" or "extended certification" (change the 
terminology as you see fit).

MultiMarkdown, for example, has a test suite that continues to grow as 
various edge cases are discovered -- I test both the Markdown 
compatibility mode, and the full MultiMarkdown feature set.  Karl posted 
about his [test suite][1] on github, and I patched MMD to pass the one 
test in his suite that it failed.


I suspect most users would be fine using any flavor of Markdown that 
passed the "standard" compatibility.  The majority of the remainder 
would be happy with any flavor passing "extended" compatibility.  Any 
one else is going to understand enough about Markdown to pick their own 
flavor and handle any issues that come up.


FTP


[1]: https://github.com/karlcow/markdown-testsuite




-- 
Fletcher T. Penney
fletcher at fletcherpenney.net