Matt Ström-Awn

Ok, returning to this after having some experience with trying to parse larger token files, I think some kind of explicit key is necessary. The main reason is that groups...

My initial thought when seeing new token type proposals is to ask: can this be solved with groups? eg, without using a new token type, you might have this: ```json...

Interesting! It's funny that JSON allows for this. My feeling is that token names have to be non-zero. I can't imagine a use case for a token called "" ......

I'm ok with empty groups as long as we specify that they can/should be ignored when parsing.

I agree that tokens files aren't the right place to store conditional logic that applies on a platform level — the place to solve that problem is on the platform!

I think this could be solved by using JSON's escaping rules. See image below from json.org:  To add our own "downstream" escaping, a double backslash would suffice. So you'd...

Returning to this after a bit of experience working with composite types, I think that we should have: 1. Implicit types for properties specifically covered by the spec. eg, the...

I have a very strong preference for keeping all of the values of a composite token together. This is faithful to the nature of a design token as being a...

Big +1 to having this use case be solved by token groups, not by a new type. And agreed with the suggestion to avoid arrays where we can; I think...

> I don't think there is much value at this time in supporting platform specific contexts and that it will be problematic to implement in design tools. Agreed!