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.