Eric Myhre

Yeah, I can't actually defend this map here all that vehemently. I think I wrote it this way because istm that maps with a single constant value (a [unit](https://github.com/ipld/specs/blob/4eb7b233f38864262c24cc91203098f483f21432/concepts/type-theory-glossary.md#unit-types), essentially)...

Another angle we could regard this from might be: Set should be a Kind in the Data Model. If we took that approach, though, we'd need to define how "set"...

There's _some_ touch made on this in https://github.com/ipld/specs/blob/babe8137b78192db89367536230f1431e8260ead/concepts/type-theory-glossary.md#what-about-numbers , which simply says > we tend to pretend and build abstractions as if numbers are infinite scalars and then salts on...

A couple of misc things I'd like to see added along with those fixtures: - `selector_walk.json` needs just a little bit of explainer about which fields are what. (I grok...

Quick draft on explainer of `selector_walk.json`'s format :arrow_right: This fixture file contains a list of fixture objects. Each fixture object matches the IPLD Schema: ``` type Fixture struct { #...

We also typically give fields `lowercase` or `mixedCase` names. (When you feed this into codegen in golang, it's going to generate accessor methods with appropriate export case.)

Syntax nittery aside, this logically LGTM :D

What's still needed to advance this? At last read, both this and https://github.com/ipld/specs/pull/355 (I assume that's the other follow-up PR you mentioned) look reasonable to me. If this is pending...

Ping for if we can merge this :)

FWIW, a lot of what you describe seems to also fall within the mission of the new IPLD Schemas work, especially as we get to working on codegeneration driven by...