Milber Ferreira

$type should be a required property

16

[3.2 (Design) Token Properties](https://second-editors-draft.tr.designtokens.org/format/#design-token-properties) A concern I have with the current specification is that we are not making the "$type" property required. I believe that both the "$type" and "$value"...

Add "Option" and "Alias" token clusters

5

One thing I miss in this specification draft (but maybe there is a valid reason for it) is to capture more deeply how token inheritance works, what are the two...

Additional property -> "$reference" (for alias tokens)

12

`Reference` When talking about "alias" tokens. One of the key properties I miss in this specification is the one that would allow me to identify the token that an alias...

Additional property -> $comment

5

`Comment` We currently have the "description" property that tools could use in different ways to inform users about the intention of a token. However, these definitions are in many cases...

Add a "$specificationURL" or "$specificationUrl" or "$specification" (required) property to the "$extensions" property for vendors

1

I think that it is a bit dangerous to leave the "$extensions" property in free format without a way to at the very least, decode their data. Why not add...

Adopt kebab case for token names

4

Adopt kebab case for token names. Referring to [this paragraph](https://second-editors-draft.tr.designtokens.org/format/#groups-0:~:text=Token%20names%20are%20case%2Dsensitive%2C%20so%20the%20following%20example%20with%202%20tokens%20in%20the%20same%20group%20whose%20names%20only%20differ%20in%20case%20is%20valid%3A): `Token names are case-sensitive, so the following example with 2 tokens in the same group whose names only differ in...