Re: [community-group] Groups and Aliases Specification Updates (#298)

Super happy to see `$root` and `$extends`, those are both concepts I've needed in the past. I've definitely baked my own support for `$root` in past SD pipelines.

> Decision: Maintain curly brace syntax for token references, require JSON Pointer support for property references.
>
> Rationale: Originally attempted to make syntaxes equivalent, but discovered fundamental incompatibility - curly braces implicitly target $value while JSON Pointer provides direct path access.

@ilikescience I think it's a problem that this shorthand exists. I've wanted to resolve aliases to whole tokens in the past (because they were identical), and not being allowed to do prevented me from reducing my maintenance surface; aliasing individual properties still meant that adding properties in the source required adding aliases in the targets.

Very happy to have `$extends` as an escape hatch now, but I still don't get why `$value` should get preferential treatment in aliasing, forcing other use cases to use an alternate syntax. I'd personally prefer a breaking change that brings both syntaxes on a feature parity level. Though I understand this is in the realm of my personal preferences and I expect the vast majority would prefer for the `$value` shorthand to be preserved :)

I'd curious if curly brackets shorthands could instead resolve to the same property as the one making use of an alias (e.g. `"$value": "{my.token}"` points to `my.token.$value` but `"$type": "{my.token}"` points to its type) ? That would maintain retrocompatibility for the common use case (value -> value aliasing) whilst allowing more coherence and flexibility.

-- 
GitHub Notification of comment by Sidnioulz
Please view or discuss this issue at https://github.com/design-tokens/community-group/pull/298#issuecomment-3245719296 using your GitHub account


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

Received on Tuesday, 2 September 2025 14:59:57 UTC