-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow "miscellaneous" category #26
Comments
Allowing extra parameters is tricky as you can't do any of the validation. Doing this manually is straightforward enough, I think. |
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 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. |
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. |
Is We could say that anything in 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 |
fixed by #44 |
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
The text was updated successfully, but these errors were encountered: