Currently there are only C and Javacript implementations of CommonMark. Obviously there are a lot of people that want to have (and/or write) an implementation in their own favorite language. Are there any plans to expand the “official” implementations and include more languages (and can I contribute? )? Or is there at least going to be some site with links to “certified” implementations?
I really think that it would be good if CommonMark also coordinated implementations in other languages so that there aren’t a zillion competing implementations of varying quality, but rather a few implementations of good quality. Also, a standardized API in all languages would be interesting, although with different paradigms (OOP, imperative, functional, etc) it can get somewhat tricky.
I think any implementation that passes the tests embedded in the spec is “certified” CommonMark compatible.
It’s simply a matter of making the tests fully complete. What we have now is good, but it can always be improved!
I think there are two ways of looking at this.
One of them is compatibility of the conversion – given the same Markdown, the implementation produces the same HTML as the reference implementation(s). In the optimal case, this is equivalent to “the implementation matches the spec” and “the implementation passes all the tests”.
If this is the case, then by all means the implementation should be considered compatible, as @codinghorror says.
The second view is a similarity in how it’s implemented compared to the reference implementation. For example, you could probably create a CommonMark-compatible converter that works similar to John Gruber’s original Markdown implementation, which is a bunch of regex replacements with some extra logic inside it. And you could also create a CommonMark-compatible converter whose inner logic works similar to the CM reference implementation, including an identically-structured document tree (see “Appendix A: A parsing strategy” in the spec).*
So the Fortran implementation should by all means considered CM-compatible, but the LISP implementation has an additional nice-to-have level of compatibility. I don’t know that we need to have a name for this additional level, but it’s something to keep in mind.
Of course a plugin written for a Ruby implementation that uses a similar regex replacement technique could be easily ported to the Fortran version, so this kind of “compatibility” doesn’t only apply to the reference implementations.
*or how ever else the final CM reference implementation may eventually work
No, this isn’t what I meant. Sure, anyone can create a CM-compliant implementation and then proudly present their “compliant with the spec” badge. That’s pretty much why there is a CM in the first place - so people could make “compliant” implementations.
But “compliant” is one thing and “officially endorsed” another. Anyone can make the first one, but the second one implies that the very fathers of CM have looked this implementation over and agreed it to be of superb quality. It’s a mark of recognition that sets an implementation apart from all the rest. It says “This particular implementation is preferred over all the others in the market. Consider it to be the one and only canonical reference implementation for [insert language here]. This is GUARANTEED to be good. You can’t go wrong with it.”
And this is what I’d like. To spare me (and other developers) the choice of picking among zillion competing implementations by pointing out one which is known to be good, is unlikely to be abandoned (unless CM itself is abandoned), and will always follow the standard.
Ermm… hello? Bump? Did I say something wrong?
I guess most people here (myself included) feel that a “best implementation for language X” award shouldn’t be in the scope of CommonMark. W3C doesn’t pick a “best HTML browser for operating system X” either. As long as they can show they pass all the tests, they are CommonMark compatible and that’s all there is to it. Beyond that there come a lot of subjective (interface and documentation styles) and hard to measure (like performance) criteria into play.
Well, each reference implementation requires careful maintenance, much more so than any other implementation (higher standards), and for every update to the spec, all reference implementations will have to be updated too.
So every reference implementation is a maintenance burden, especially you’d need an expert developer for each of those languages to maintain each one. So if we had one for every programming language that implements markdown, we’d need dozens of maintainers and updating the specs would be a huge effort, coordinating all those people.