input: Convert root into object, require version

[bdarcus]

Convert the root of schema into an object with metadata, and a required
version property.

Include optional title and description properties.

While I'm at it, also removing the edtf regex on a separate commit.

Close #319

---

Examples

Aside from this being a better, forward-looking, design, it's also more consistent with the pandoc YAML model.

The below shows this change, but in larger context of the other changes suggested in the v1.1 branch; notably with dates and titles.

An example, validated against the schema in YAML, with EDTF dates (though the regex here doesn't cover the date-time example ATM, so the validator throws an error on that property; really need a proper EDTF regex, which is not my skillset, or maybe just drop the constraint for now; see #421).

---
version: 1.1
description: An example CSL YAML 1.1 file
references:
  - type: book
    id: test1
    issued: '2020'
    title: 
      main: Title
      sub:
        - Subtitle
    author:
      - given: Jane
        family: Doe
  - type: article-journal
    id: test2
    issued: 2020-07/2020-08
    title: Simple title
    author:
      - given: John
        family: Smith
  - type: post
    id: test3
    title: “Most kids are fine!”, people say
    issued: 2022-06-02T01:57:29Z
    URL: https://twitter.com/zeynep/status/1532356192567189506

... and converted to JSON:

{
  "version": 1.1,
  "description": "An example CSL YAML 1.1 file",
  "references": [
    {
      "type": "book",
      "id": "test1",
      "issued": "2020",
      "title": {
        "main": "Title",
        "sub": [
          "Subtitle"
        ]
      },
      "author": [
        {
          "given": "Jane",
          "family": "Doe"
        }
      ]
    },
    {
      "type": "article-journal",
      "id": "test2",
      "issued": "2020-07/2020-08",
      "title": "Simple title",
      "author": [
        {
          "given": "John",
          "family": "Smith"
        }
      ]
    },
    {
      "type": "post",
      "id": "test3",
      "title": "“Most kids are fine!”, people say",
      "issued": "2022-06-02T01:57:29.000Z",
      "URL": "https://twitter.com/zeynep/status/1532356192567189506"
    }
  ]
}

... with schema-backed completion in VSCode:

Seems this ecosystem has evolved in the past two years. Once we settle on a final version, we really need to get this schema published on https://www.schemastore.org/json/, which makes editor support all the easier.

cc @jgm @bwiernik @denismaier @cormacrelf @retorquere

[retorquere]

Regexes cannot realistically test for valid edtf dates across the range of possible dates/date ranges/date combos expressable in edtf, so it'd either be too lenient or too restrictive.

[bdarcus]

Regexes cannot realistically test for valid edtf dates across the range of possible dates/date ranges/date combos expressable in edtf, so it'd either be too lenient or too restrictive.

I thought you might have something to say about this; thanks!

Seems better to be too lenient, given the purpose.

[bdarcus]

@retorquere - do you think I should just remove the regex "pattern" here entirely?

    "edtf-string": {
      "title": "EDTF date string",
      "description": "CSL input supports EDTF, levels 0 and 1.",
      "type": "string",
      "pattern": "^[0-9-%~X?./]{4,}$"
    }

Or do you have a suggestion for a more lenient regex, that would still be useful?

[retorquere]

I've been trying to find the place where I got it without success but I think I read at some point that EDTF dates are not regular, so regexes are problematic to parse/validate them. I know just enough about EDTF to leave validation to @inukshuk.

Personally, I'd add edtf validation as custom format attributes, and provide a reference implementation using ajv + EDTF.js. If I'm reading https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.2.3 right, processors that don't know about these custom properties would validate presence but not format of the property.

edit: the regex above would reject date sequences and significant-digit markers (S), letter-prefixed calendar year (Y), and dates with time.

[bdarcus]

the regex above would reject date sequences and significant-digit markers (S), letter-prefixed calendar year (Y), and dates with time.

The last is important for us. Are the others?

[retorquere]

I don't know, honestly. Does the processor do anything with date sequences? Letter-prefixed seems valid, even if I've not seen it in the wild yet.