Add sub/main forms to json schema

On the other hand, there seems to be a preference for flat CSL JSON (ignoring the funky date-variables nesting). And some of the flat fields already exist like container-title-short and backcompat would be good.

If going with the flat structure, I think it’s best to update the CSL JSON schema to include these properties. I don’t think it makes sense to add -short variants where there is not a documented or theoretical need.

To enable the flexibility to add suffixes to CSL fields, we could look into JSON Schema pattern properties. This would allow us to keep the number of schema definitions from exploding:

{
  "type": "object",
  "patternProperties": {
    "^title(-long|-sub|-main|-short)?$": { "type": "string" }
  },
  "additionalProperties": false
}

This looks promising. This will work for title, right? What’s the best way to add the prefix patterns? Does that work?

{
  "type": "object",
  "patternProperties": {
    "^(container-|collection-)?title(-long|-sub|-main|-short)?$": { "type": "string" }
  },
  "additionalProperties": false
}

Or should we add one pattern per title?

{
  "type": "object",
  "patternProperties": {
    "^title(-long|-sub|-main|-short)?$": { "type": "string" },
    "^container-title(-long|-sub|-main|-short)?$": { "type": "string" },
    "^collection-title(-long|-sub|-main|-short)?$": { "type": "string" }
  },
  "additionalProperties": false
}

Readability is better here, but it is redundant, of course. Maybe something like this?

{
  "type": "object",
  "patternProperties": {
    "^(container-
        |collection-
        |volume-)?
        title(-long|-sub|-main|-short)?$": { "type": "string" }
  },
  "additionalProperties": false
}

_Originally posted by @denismaier in https://github.com/citation-style-language/schema/pull/271#issuecomment-649559085_

It seems that we currently deal with sub/main forms in the rnc schema, but there’s nothing on the input side. Shouldn’t we add those? (I was about to start writing the documentation for the split-title feature and also to prepare some tests. But it looks like there are still some open quesitons…)

Edit: Currently, it looks like we’ll support this by changing titles to objects.

[denismaier]

So, summing this up: I will start drafting the documentation and the test based on these assumptions:

1. In styles, we’ll have @form="sub" and @form="main" available. The standard/long form of a title will be the reassembled title.
2. On the input side, users can provide split-points explicitly with ||.

[bdarcus]

The casing requirements are why I’m not a big fan of including “full” as an element–that would require text comparison of “full” to “main” and “sub” to determine what to capitalize.

OK, this is a key piece I was missing.

So among styles which do not specify decomposition, if we have a full title, some will specify to modify casing, and others will specify to leave it alone.

The problem this presents is with a full title, a processor won’t have access to the sub-components, so it won’t be able to modify the casing.

@denismaier, do you think you could modify the main post to reflect this as clearly as possible, for the record?