GitLab

The very first draft tried to get away with *one* "Kind" enumeration,
but that quickly became odd and shakey; *two* separate "Kind" enums
(one for the Data Model, one for the lower level Representation;
working terms, and mine) fits a lot better.  The latter is what we're
committing here.

Also of interest here is a proposal for a distinction between whether
fields are *required* vs *nullable*.  I'm not sure this has been done
before in any of the other systems I've examined so far; it's a concept
I think we'll want for dealing with the subtle distinction between
whether some piece of data *matches* our schema vs whether it's *valid*
within our schema.  But it's quite hypothetical; it's possible this
whole concept of "matching" will turn out a lot more complex than that.

There's a tossed out syntax for a schema DSL in a comment.  This is
utterly unscrutinized and should not be taken too seriously yet.

The example code at the bottom declaring some type system is code that
*could* be used, but is mostly for demonstration and early dev
purposes: in the long run, we *do* want to come up with a DSL, and all
the relevant grammers, parsers, and so on for using that as an
implementation-agnostic source of truth.  At that (far future) point,
this kind of code would be used internally to represent what's been
parsed out of the DSL; but users shouldn't really be writing it.
(That's a long-winded way of saying "yes, some parts of that code are
extremely not DRY and would be error prone if written manually"; and
indeed, they would, and thus the point is not to.)
Signed-off-by: Eric Myhre <hash@exultant.us>