Re: [community-group] Define order of operations during parsing of tokens files (#123)

> 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](https://tr.designtokens.org/format/#dfn-design-tool), changes to the value of a token being referenced by aliases SHOULD be reflected wherever those aliases are being used.

Found this recently after re-reading the current draft.

I might be wrong but I think that the intention here is to define value invalidation, not the order or timing of dereferencing.

- You can resolve references early while still having value invalidation.
- You can resolve references late without having any value invalidation. (clearly not intended here)

If this is the intention I think it might be fine to do early de-referencing as long as all relevant values are invalidated and updated in case of a change.

Is this correct?

----

My concern with late de-referencing is that it is undefined how this works when there are multiple token files.

-- 
GitHub Notification of comment by romainmenke
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/123#issuecomment-1136120815 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 24 May 2022 16:08:32 UTC