extend schema

[aspiers]

Candidates for optional extra fields as suggested by itsme:

• [ ] page name / index as printed in the original book and referenced in the original table of contents - note this does not necessarily have to be a straight number, e.g. "A7" might mean the 7th page of appendix A.
• [ ] key
• [ ] rhythmic feel (e.g. "medium swing")
• [ ] tempo
• [ ] composer
• [ ] an album the tune was recorded on

[infojunkie]

Would be great to also add book metadata, e.g. full book title, publisher, etc.

[aspiers]

Agreed!

[aspiers]

I'm wondering if it makes sense to move to YAML format, something like this:

book: The New Real Book 1
edition: 2
published: <date here>
index:
  - title: Affirmation
    page: 16
  - title: Airegin
    page: 17
  - title: Always There
    start: 18
    end: 19
...

and have the CSV format auto-generated from the YAML, with the first row of the CSV determining the fields in use. The CSV files could still be checked into git so that people who need that format could immediately download. We could have simple CI checks to ensure that the YAML and CSV files are always perfectly in sync.

That would give us a lot more flexibility:

• Book-level attributes
• Optional fields anywhere (like the ones mentioned above) without having to clutter either YAML or CSV with empty values when they are not used.
• Nesting multiple books inside a single data structure

The only downside I can think of is that anyone submitting PRs would potentially have to learn how to write YAML. But we could easily write a little script to convert from CSV to YAML, and then anyone who is comfortable doing that could help add missing YAML to retrofit newly submitted CSVs.

Why YAML instead of XML or JSON? They are both much more technical and less human-readable (e.g. the above example is easily understood by anyone), and offer no significant benefits over YAML (at least, not in this context).

[aspiers]

Just discovered an alternative to YAML: Dolt and DoltHub - filed as #39.