I think I was reading about CommonMark when I saw this mentioned.

Sad because true?

Honestly, I think CommonMark is probably a pretty good idea, all things considered. There are people that are going to get concerned with a "spec" that's, as CommonMark puts it, "ambiguous". You don't want strange edge cases that seem to conflict with reasonably hard and fast rules. I think the best complaint I've seen (and I can't dig the source back up in 10 mins of googling) is the "underline for headers" issue.

What do you do here?

This is a header. Or is it the last thing in a section before a horizontal line?
--------------------------------------------------------------------------------
I'm not sure. You tell me.

Apparently the original spec didn't address many edge cases like this, and you'd have to go to the code. I can't recall why that code wasn't good enough, other than folks occasionally disagreeing with it. And different users do have different needs, so I think that's a fair complaint.

And most importantly for coders, CommonMark gives you a test suite. We like to have explicit pass/fail conditions. You're only as good as your metrics and QA.

But yeah, any time somebody's providing something called Babelmark to help you see what's going on in different flavors of a markup format with unresolved edge cases, you've got a fragmentation problem.

Also worth mentioning: Is HTML a Humane Markup Language? from Atwood. Probably as good a visualization of why we might prefer Markdown to some other markup language that's got some traction right now as I've seen, though Atwood here (contra Atwood now, afaict) strangely decides that HTML is easier to eyeball than Markdown.

In other news, I had this choice definition of POJO open from Martin Fowler's site. I was pretty confident when I read "Anemic Domain Model" that he'd meant Plain Old Java Object, but the backstory is both hilarious and tragic.

POJO An acronym for: Plain Old Java Object.

The term was coined while Rebecca Parsons, Josh MacKenzie and I were preparing for a talk at a conference in September 2000. In the talk we were pointing out the many benefits of encoding business logic into regular java objects rather than using Entity Beans. We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely.

(ー_ー﹡)

Labels: coding, fowler, markdown, standards