Kyle Husmann

> As far as I'm aware, there is no `base::version()`, so there's no conflict. Ah yes, it's not `base::version()`, it looks like it's just a global constant, not a function:...

> Maybe you would like to add it as attribute instead? For a while I've been thinking about an approach close to this, but where resources are loaded by `read_resource`...

Would V2 be an opportunity to implement this pattern as a top-level field type rather than as an enum constraint on other types? e.g, instead of : ``` { "fields":...

@peterdesmet excellent points. Conceptually, I'm imagining the `enum` *type* to be specifically for representing categorical / ordinal variables, that is, a field with a distinct set of levels that may...

Thanks for bringing up the encoded categoricals @pschumm, I think this is worth more discussion. I think the `values` array in the categorical type should always be specified as logical...

I like where we're going with this! Especially @peterdesmet 's proposed `categories` prop! I agree, putting the levels in a map with `value` props greatly improves readability and is a...

> The example I gave above was intentional; for example, this is how REDCap exports data by default (i.e., categorical variables get exported with their numeric codes, except for defined...

> This reinforces my original contention that the issue of field-specific missingValues is closely related to efficient description of categorical variables > The proposal here would still work without field-specific...

> In general, union types offer a lot of flexibility to keep things backward compatible and are often elegant (e.g. not having to add a new roles property over role)....

@nichtich Agreed -- I think that's exactly the direction we want to go, and "inline-categories" gives us the first step.