Reserved Fields

[loriab]

You may want to create a list of reserved fields for likely expansion and to prevent ppl from trying to be clever by claiming multiplicity with definition 2S b/c that’s more convenient for them than the MolSSI molecular_multiplicity of 2S+1 (did not look up proper field names)

[tovrstra]

I agree that this a problem but making a list of reserved field names in the variables dictionary is not a robust solution, because you don't know exactly which names you want to add to the standard in future.

It would be better to only allow for some freedom with names in specific places to avoid such issues, e.g.

• variables: only allow names that are set in the standard
• other_variables: anything goes

This way, you can extend the schema easily with names in variables without causing collisions.

[dgasmith]

@tovrstra Can you type a small snippet in a PR to this effect?

[tovrstra]

Should I put it in the main README.md? I'll invent a preliminary list of approved names for variables.

[dgasmith]

Would it make more sense to go into the Variables.md and change that name as well?

[tovrstra]

ok

[tovrstra]

Have to go now though.

[cryos]

Would this be best served as outputs from a workshop discussing necessary reserved fields? Should we offer some whitelisted fields instead that we will never use, so that applications could extend the format?

[tovrstra]

It would also be an option to whitelist fields with a prefix, e.g. anything that starts with custom or extra. It seems not as clean as a separate dictionary, but that is mostly a matter of taste.

[dgasmith]

In QCArchive we added a single extras field that was whitelisted. This seems to work out well in all of our use cases. This is in line with other comments, but any thoughts on making it official?

[loriab]

extras field has worked great for psi, and it's easy to remember. And not too hard to migrate a field from first-class into extras. +1 on making it official.