Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

extend schema #12

Open
6 tasks
aspiers opened this issue Apr 19, 2015 · 4 comments
Open
6 tasks

extend schema #12

aspiers opened this issue Apr 19, 2015 · 4 comments

Comments

@aspiers
Copy link
Owner

aspiers commented Apr 19, 2015

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
Copy link

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

@aspiers
Copy link
Owner Author

aspiers commented Sep 29, 2018

Agreed!

@aspiers
Copy link
Owner Author

aspiers commented Jan 29, 2023

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
Copy link
Owner Author

aspiers commented Mar 26, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants