Agreed. @codinghorror - let’s think about how this could be rewritten. “Implementation” isn’t really right. “Strongly specified specification” wouldn’t make much sense. I’m also not sure about “highly compatible.” Compatible with what, exactly?
I’m not sure what “strongly defined” is supposed to mean – but I guess “precise specification” or “unambiguous specification” would express a very similar intent.
And does a “strongly defined specification” implies “strict syntax rules set down in a strongly defined specification”? Kidding aside: a specification could be clear, or unambiguous, or precise, or loose, or simple, or formal, or inconsistent, but I see no point in postulating a specification to be “strongly defined”.
Furthermore, the thing that is supposed to be “compatible” is probably not the specification, but what the specification does specify: in our case, a syntax (or a language) and its semantics (or interpretation).
Since every input text is supposed to be accepted by a “traditional” Markdown implementation as well as a “modern” Commonmark implementation (there are no “invalid” input texts, or “syntax errors”): it is obviously not the specified language itself which is or is not “compatible”, but the interpretation of the input document.
So my “mission statement” proposal would be something like this:
A clear, precise specification of
the input syntax rules (by which the “structure” of the input text is recognized),
the content model of the “output document” (equivalent to @jgm’s “AST”),
the transformation rules by which the “output document” (ie, an instance of the content model) is derived from the “structured” (or “parsed”) input text,
which together produce the same (or very similar) output as would a “traditional” Markdown processor according to the “official” (ie: Gruber’s) syntax description – at least in “most practical cases” …
I would leave implicit the goals that the specification
should be abstract in the sense “free of unnecessary details and constraints”: for example, the content model should not be simply a subset of the HTML content model (for example given as the XML Information Set of XHTML document instances) – while it certainly and easily can be mapped into it and into a variety of other document types (like LaTeX or DocBook articles or reports etc).
should be loose in the sense “allowing implementation choices”: for example, the character set and encoding scheme (like “UTF-16LE”, or “ISO 646 IRV”) and the “line breaking convention” (DOS-like “CR,LF” , or UNIX-like “LF”, or Unicode Standard Annex #14 etc) supported and usable in the input text should be the choice of an implementation.
Kidding aside: a specification could be clear, or unambiguous, or precise, or loose, or simple, or formal, or inconsistent, but I see no point in postulating a specification to be “strongly defined”.