"Add" CSL YAML

This and this suggests we can use our JSON schemas to validate a YAML alternative.

Pandoc already supports a YAML alternative (cc @jgm).

I suggest we do something with this, since it’s zero work for us, and would give more options for users and developers.

Perhaps most sensible option is just adding a sentence to the spec that mentions this possibility, without requiring implementations to support it?

Edit: actually, we say nothing about input in the spec currently. So we would need to add a section on input data, and say that our schema can validate either json or yaml.

Proposal

Based on this discussion, we should:

1. review the existing json schema for any possible adjustments we might want to make now. Date parts are one obvious discrepancy; are there any others?
2. add an optional field for the content markup format to parse; the html subset could be default, and we could enumerate other options; say markup: org.

_Originally posted by @bdarcus in https://github.com/citation-style-language/schema/issues/277#issuecomment-650192158_

[jgm]

It seems that this works with pandoc-citeproc to specify an open range:

  issued:
  - year: 2042
  - {}

But I wouldn’t worry too much about my data model, since I’m planning to transition eventually to the new citeproc library I’m writing. It already passes more citeproc tests than pandoc-citeproc, and it’s much faster and more maintainable. It uses the date-parts model that is part of current CSL.

[bwiernik]

So how about this:

Proposal

1. We define a set of markup features that citeprocs should be able to process.
2. We define the syntax for CSL-JSON, likely building on the existing HTML-like syntax
3. Processors of CSL YAML should recognize and support the CSL-JSON markup syntax regardless of other markup format used
4. CSL YAML includes a markup element indicating the type of markup used (“none”, HTML, Markdown, TeX, Docbook, etc.) for other markup syntax.
   • Specifying “none” would allow a Zotero user, for example, to stop pandoc from parsing Markdown without having to escape the characters (which would interfere with using the data with a word processor).

Second, just a reminder that pandoc is pretty much the most universal document converter in the world; I think we should seriously consider the perspective of its author.

@jgm I mean no disrespect; sorry if I’ve come off otherwise. pandoc is the single most amazing piece of software I’ve encountered, and I use it daily. I’m just hoping to maintain as much compatibility for GUI users as possible.