Skip to content

typeschema

James Tocknell edited this page Mar 15, 2021 · 2 revisions

Why not TypeSchema for the Project Specification:

We need some JSON-based format to encode a specific project's Project Specification, such that it can be stored in the database, be represented in a user-friendly way to the Project Lead, be used with the GUI Specification to build the forms, and with the Data Model to encode and decode the project's data. We want to be able to represent types and have subtypes of types.

TypeSchema currently only allows subclassing the JSON "object" class, you cannot (without problematic workarounds), subclass any other type (e.g. "number" or "string"), nor can you subclass more than one type. Enums are not done on the subtype, instead this information must be on the normal JSON type, and is lost on subtypes if you try to define a type with the information. Additionally, while one advantage of TypeSchema is that we can generate JSONSchema from it (and hence pass that into JSONForms), if we want to keep the GUI Model separate from the Project Specification (which seems ideal, and allows for overriding/extending the GUI independent of the Project Specification), then JSONForms will not be that useful.

Additionally, TypeSchema has no way to represent multi-leveled enums (as would be needed for the Geochemistry module).