[Schema] review for camelCase field names that should be snake_case

[odscjen]

Realised that some of the fields, e.g. referenced_by.authorNames are still incorrectly using camelCase when snake_case is the convention. This will also affect the spreadsheet template

[stufraser1]

This will also affect links with MVdat (the database using MOVER schema) which uses CamelCase, but I think we need to prioritise using JSON conventions.

[odscjen]

I think its best to aim for internal consistency, i.e. using the same format within RDLS.

Regarding links to other schema such as the one used in MVdat there's going to have to be some mapping anyway so I don't think that should prevent us ensuring consistency within RDLS

[duncandewhurst]

Agree that we should be consistent.

I don't think there is a universal convention for using snake_case or camelCase in JSON - see https://stackoverflow.com/questions/5543490/json-naming-convention-snake-case-camelcase-or-pascalcase

JSON Schema itself uses camelCase so we have tended to use that in other standards. Otherwise, you end up with a schema file that mixes snake_case property names and camelCase JSON Schema keywords.

I had assumed that snake_case was preferred in RDLS because that fits best with how you plan to use the standard. If it was chosen out of a desire to conform to JSON conventions, I think camelCase is a better choice for consistency with JSON Schema.

[odscjen]

Moved this back to under discussion just to get final clarity over which we want to go to. Changing everything to camelCase is the bigger job as the majority of field/object names and codes are in snake_case

[stufraser1]

I don't think it was a conscious choice, but I assumed better to stick to JSON conventions. If snake_case works better for use of RDLS standard, and most is in snake_case already then lets persevere with snake_case for everything.