possible_project_model_schema

A possible Project Specification system

We're going to use the following conventions for this system:

• An all-caps name refers to a constant e.g. "MAX_ENTRIES"
• A title case name refers to a type e.g. "Integer", "String" or "Bone" (note that this type is not the same as a JSON or JavaScript type) or a metadata tag e.g. "Annotation" or "Certainty"
• Members (need a better term here) of a type will use snake-case e.g. "creek_name"
• Named constraints (if we need them) use camel case e.g. "inSouthernHemisphere"
• Namespaces are denoted by "::" e.g. "faims-core::Integer"
• Settings for the type (need a better term here also) use kebab case e.g. "super-types"

An example document follows:

{
  "namespace": "faims-core",
  "constants": {
    "CONSTANT1": 1 // could also be "CONSTANT1": "Number(1)"
  },
  "types": {
    "Number": {
      "super-types": []
    },
    "Integer": {
      "super-types": ["Number"] // could also be "super-types": ["faims-core::Number"]
    }
  },
  "named-constraints": {
    // need good example...
  },
  "metas": {
    "Comment": {
      "type": "faims-core::String",
      "default": ""
    },
    "Certainty": {
      "type": "Number",
      "default": 1
    }
  }
}

Some helper/meta types we may want (named can be changed):

• Integer: As JS only has a number type, this would check that values are representable as integers (e.g. either we error if the input requires more than 52-bits to store, or we switch to a string representation and hope we can rely on a BigInt implementation...)
• Array: represents an array containing elements of a specific type e.g. "Array(Number)"
• Map: represents a map from one type to another e.g. "Map(UserId, User)"
• Class: a supertype which represents a type which has members
• OneOf (or EnumType): A metatype which takes a list of types, and represents choice between types e.g. "Array(OneOf(Number, String, Null))".
• Option (or Either): A metatype which represents something that can either be a specific type, or null e.g. "Option(Number)"

Some settings on types we may want are:

• "super-types": the types the current type is derived from
• "additional-members": additional members that the subtype has (by default this is an empty array)
• "removed-members": members that super types have which this type should not have (this seems like a red flag to James Tocknell - I'm putting this here as a discussion point).
• "allowed-values": a list of values this type can have
• "recommended": Data should be required, user is explicitly warned. To the module author, it's on by default.
• "migrate-as": the default value of the type (needed for migrating with a new field/member)
• "constraints": the constraints on the type (if we put this on the type, not on the Data Model).
• "metadata-here": List of metadata names defining if a metadata's value is allowed to be set for the current type. Defaults to the true for primitive types, false for compound types.
• "metadata-members": For each metadata, defines if metadata should be settable on members of the current type. true/false are a substitute for array of all members/empty array. {"Annotation": true, "Certainty": ["birthdate"]}. Defaults to true for all metadatas. (Meaningless for primitive/non-compound types)
• With metadata-here set to true, it is probable the user doesn't want metadata on subcomponents, so metadata-here should default to false in the gui, and visa versa. if metadata-here is false

You can discard bad data when you use it

Currently I'm using "Type(value,...)" all over the place, it would be useful to find a nice was to write this in a more expanded JSON form (rather than the custom DSL I've got currently...).

initial passes at using the new project model encoding for the primary models

• Oral History