Allow "miscellaneous" category

[valentinsulzer]

For easily adding extra parameters that don't fall in the specification

Alternatively, this could be done manually by first loading the BPX file and then adding parameters in a python script

[rtimms]

Allowing extra parameters is tricky as you can't do any of the validation. Doing this manually is straightforward enough, I think.

[rtimms]

Actually, this would be an easy addition. We can allow extra fields in an "Extra" part of the schema (e.g. see here and make them all of type FloatFunctionTable to ensure they are valid values/functions/data.

It would be good to allow (enforce?) supplying a reference for any extra parameters? E.g. "this parameter is "a" in eqn 7 of reference...". Not sure of the best way to do this.

[ejfdickinson]

I think that we should advise users sharing "Extra" parameters to write their own symbol tables that make clear the mapping to some corresponding extension of the core BPX mathematical equation set, which they also need to write. Then a user of their extended BPX can make a decision on whether and how to handle the extra parameters in the way they define. Within the JSON itself does not seem to me to be the right place for this.

[ejfdickinson]

Is "User-Defined" a good name for this?

We could say that anything in ["Parameterisation"]["User-Defined"] is validated as FloatFunctionTable by the schema, and the schema doesn't validate the hierarchy or field names within this block.

Outside of this zone, the schema still strictly validates the JSON structure, so we don't allow the user to just write rubbish wherever they like.

Insofar as the BPX mathematical specification is separate to the schema, users are responsible for writing their own extension of the specification to define whatever they put in the "User-Defined" zone.

[rtimms]

fixed by #44