Ryan Johnson

This might be relatable to #109.

The whole point of using JSON as the chosen format is to ensure cross-platform interoperability using a well-defined data structure. By adding this type of syntax to the spec, we're...

To me `$name` implies that something should be explicitly named as defined (verbatim), after transformation. Given that the intent is to provide human-readable text (likely for documentation or in-flow consumer...

Are all properties of a composite `typography` token required? I'd like to define _partial_ token definitions so that I can compose more complex styles after translation? ```sh { fontFamily, fontWeight...

I agree, there may be valid use cases for defining a `line-height` with a unit, so it makes sense that the `lineHeight` prop should support _either_ a unitless number or...

> As you've noted, the question to answer is whether it should be an inherited property or not. I'm tempted to say that it should _not_ be inherited - i.e....

Why not a `$status` field instead? I can see this being useful to describe a token throughout the entirety of its lifespan (not just during deprecation). Could start with just...

Having `$deprecated` be an object makes sense, but I'd argue that a `$value` prop seems both redundant and conflicts with the definition of a Token. If `$deprecated` is _present_, it's...

Given that there are much better and more mature tools to accomplish changelog / history / audit trails, I'd highly recommend against trying to wedge it into the spec. Additionally,...

> for example : > > ```json > { > "type styles": { > "heading-level-1": { > "$type": "typography", > "fontFamily": { "$value": "Roboto", "$type": "string" }, > "fontSize": {...