Token aliases with invalid or unsuited intermediate value

[romainmenke]

https://tr.designtokens.org/format/#aliases-references

When a tool needs the actual value of a token it MUST resolve the reference - i.e. lookup the token being referenced and fetch its value. In the above example, the "alias name" token's value would resolve to 1234 because it references the token whose path is {group name.token name} which has the value 1234.

Tools SHOULD preserve references and therefore only resolve them whenever the actual value needs to be retrieved. For instance, in a design tool, changes to the value of a token being referenced by aliases SHOULD be reflected wherever those aliases are being used.

Aliases MAY reference other aliases. In this case, tools MUST follow each reference until they find a token with an explicit value. Circular references are not allowed. If a design token file contains circular references, then the value of all tokens in that chain is unknown and an appropriate error or warning message SHOULD be displayed to the user.

https://tr.designtokens.org/format/#type-0

A token's type can be specified by the optional $type property. If the $type property is not set on a token, then the token's type MUST be determined as follows:

• If the token's value is a reference, then its type is the type of the token being referenced.
• Otherwise, if any of the token's parent groups have a $type property, then the token's type is inherited from the closest parent group with a $type property.
• Otherwise, the token's type is whichever of the basic JSON types (string, number, boolean, object, array or null) its value is.

Example :

{
	"one": {
		"$type": "color",
		"$value": "#ffffff"
	},
	"two": {
		"$type": "dimension",
		"$value": "{one}"
	},
	"three": {
		"$type": "color",
		"$value": "{two}"
	}
}

Is three a valid color token with value #ffffff ? Or is it invalid because the intermediate token has type dimension

Currently this is ambiguous because there are not precisely defined parsing steps.

Dereferencing aliases doesn't mention type at all. So it seems that types aren't a factor for this process.

[romainmenke]

Somewhat related :

{
	"one": {
		"$type": "dimension",
		"$value": "#ffffff"
	},
	"two": {
		"$type": "color",
		"$value": "{one}"
	}
}

Is two a valid color token with value #ffffff ? Or is it invalid because the aliased token has a type mismatch with it's value.

[ilikescience]

My feeling here is that type is not relevant for aliases, since we haven't seen a case for re-typing tokens (see #189).

So, either:

1. Alias tokens should NOT have a $type key,

or:

2. Alias tokens should have a $type of alias (or something equivalent - inherit?).

In either cases, the resolved type will always be whatever the aliased token's type is. I think option 2 fits best with the conversation in #139.

[romainmenke]

Neither are possible due to composite types :/

There is no alias token here. This is a composite token which has aliases in sub fields.

  "shadow": {
    "medium": {
      "$type": "shadow",
      "$description": "A composite token where some sub-values are references to tokens that have the correct type and others are explicit values",
      "$value": {
        "color": "{color.shadow-050}",
        "offsetX": "{space.small}",
        "offsetY": "{space.small}",
        "blur": "1.5rem",
        "spread": "0rem"
      }
    }
  },

---

Somewhere in this issue : https://github.com/design-tokens/community-group/issues/126#issue-1209463733 I propose the concept of a typed group over composite types.

That never got much traction but in such a schema you could apply your solution.

---

thinking about this more...

1. is possible even with composite types.

If a token is only a $value field with an alias then $type must be omitted. If a token is a composite token then the fields have implicit types anyway.

[ilikescience]

If a token is a composite token then the fields have implicit types anyway.

Yes, this is an issue that I think we need to dig into in a separate topic. Implicit typing of composite tokens makes sense, but requires a strict definition of all the keys that a composite token may have. In the case of typography, in CSS alone there are 57 properties that can change the way type appears. To make implicit typing work, and to not arbitrarily restrict the use case, we'd need to create and maintain a type mapping for all those properties, plus any additional properties on other platforms that aren't covered by CSS.

For this issue, do you think requiring alias tokens to NOT have a type (proposal 1.) solves the issue?

[romainmenke]

For this issue, do you think requiring alias tokens to NOT have a type (proposal 1.) solves the issue?

It might, but an error handling algorithm would also solve it. I have no opinion or preference on what is best here.

It is currently unspecified what to do in this case.

---

Yes, this is an issue that I think we need to dig into in a separate topic. Implicit typing of composite tokens makes sense, but requires a strict definition of all the keys that a composite token may have. In the case of typography, in CSS alone there are 57 properties that can change the way type appears. To make implicit typing work, and to not arbitrarily restrict the use case, we'd need to create and maintain a type mapping for all those properties, plus any additional properties on other platforms that aren't covered by CSS.

I am unsure what you mean, can you open a separate issue and elaborate? maybe with some examples?

[kevinmpowell]

Related to #200