Can I add my 2 cents.
Every processor is likely to start its work by taking input in whatever form it is given and either refuse to deal with it at all or convert it to some sort of “internal” representation, which is quite unlikely to be JSON, YAML, HTML, or any variant thereof and almost certain to be a sort of lightly-marked up list-like or s-expression like structure.
One then simply layers on parsers which take any external representation and convert it to the internal one.
The critical question from a processor design point of view is only this: what types of input do I need to recognise and distinguish. As I understand it that is (as things stand) just these: text, numbers, dates, names. Within the text class, it must recognise and distinguish between “plain” text, italic text, bold text, superscript text, subscript text, smallcaps and text protected against changes of case.
Exactly how those are marked in any type of input a processor may choose to accept is a detail that is less important, so long as I know how it is going to be done for any type of input that I am willing to process.
It may make sense to specify a “canonical” representation for any given type of input, e.g. (for JSON, use <i></i> <b></b> ..., for YAML use ..., for BibTeX use \em{} \textbf{} ...), and at this point it’s actually fine to let a thousand flowers bloom: not every processor will or needs to process multiple different input forms. But anyone who chooses to process YAML will know what to expect etc. (Strictly speaking, the CSL spec doesn’t even need to specify what form the input takes at all, so long as it can be coerced respectably into an internal representation that respects the CSL “types”.)
HOWEVER, it would be a really annoying thing to specify multiple versions of markup for a given form of input. If I’m getting JSON, I want to know how I have to parse it. I don’t want to have to “sniff” it to see if I think someone’s used markdown or whatever. A frontend should be responsible for coercing its input into one definite canonical form. A processor should always expect to be told what form its input is going to be in, and to know with certainty what sort of markup that input is allowed to contain. And a processor must never be expected to do anything other than handle that markup correctly. Spending time trying multiple different markups in an attempt to brute force one that makes sense is a big waste of energy.
So please don’t give me JSON and then leave me to “figure out” whether it’s html-ish JSON or markdown-ish JSON.
The history of standards suggests that being “generous in what you accept” is a nice idea, which leads to exponential trouble down the line.
For my own part, I would specify that for JSON input (and every processor should at least deal with that) the “html-ish” tags are correct, and the only allowable tags. Those and only those tags will be recognised as valid/special. As an API design, admittedly, they are horrible (especially nocase and small-caps), but sometimes we have to live with the mess we have.
Everything else is then left to the frontend. If someone wants to write a database frontend that will manage its data and allow rich-text entry in any form it likes, that’s OK, but it’s then its responsibility if it is going to output JSON that it will expect a processor to deal with to make any conversions.
