Re: [community-group] Toughts on the Use of "$" Prefix in the DTCG Token Standard (#240)

> Historical Context: The use of the "$" prefix can be reminiscent of older practices, such as those seen in jQuery, which may not align with modern coding standards and practices. Additionally, this prefix has been used in other contexts, such as RxJS observables, which has led to some confusion and mixed opinions within the developer community.

> I'm reasonably sure the $ convention used here is based on the [variable naming convention originating in Sass](https://sass-lang.com/documentation/variables/).

I don’t believe any of these are correct or relevant to the original decision. As I see you reached the conclusion, the primary need for this character is to **mark reserved object keys.** Using the term `description` is too limiting on what tokens can be named (people may want a token named `typography.description` or `card.group.bg-color`, both of which are valid thanks to prefixes; without which they wouldn’t be).

The `$` character specifically was inspired by [JSONSchema](https://json-schema.org/draft/2020-12/draft-bhutton-json-schema-01#section-8.1.1) that uses this pattern to reserve words. JSONSchema is a **very** relevant pattern to the DTCG spec because **it allows arbitrary nesting,** something that’s forbidden in other schema formats (e.g. OpenAPI). In the case of arbitrary nesting, you **must** reserve certain words and forbid them from usage. Using a prefix is the best of both words, being able to reserve many words, and make their reservation clear, without requiring verbosity and without reasonable conflicts with arbitrary user-provided names.

Remember—this is a **schema format**. JSONSchema is a very close parallel. RxJS, jQuery, Sass, or what have you are all irrelevant. Draw what conclusions you want to personally, but none of those comparisons apply.

> Could there be alternative approaches that might achieve the same goals without the drawbacks associated with the "$" prefix?

> `$description` but also `$type` can be used on a group level. If one concern is to prevent conflicts between the property names of the design token standard and possible design token names, then it would also help if there are no conflicts of properties that are on different levels in the object hierarchy of the design token definitions. … Therefore I suggest that we actually name these descriptions for what they actually stand for: `tokenGroupDescription` and `tokenDescription`

Through discussion you arrived at a proposal to consider, changing `$type` → `tokenType`, `$group` → `tokenGroup`, etc. But these replacements are more verbose and result in far more boilerplate characters than the current specification has. You mention “drawbacks” but I didn’t see a single actual drawback to using the `$` character other than the general opinion of “I see it in jQuery and jQuery is old and I think it’s bad therefore we should change it.”

This is a stylistic change that doesn’t solve any real problems with the schema as-currently-defined. And it’s one proposed without acknowledging relevant prior art like JSONSchema. So I’m personally not in favor of just changing an existing, working schema just because you personally don’t like its aesthetics. But if you feel strongly, I’d recommend making a new issue with a formal syntax proposal change to be reviewed.

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


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

Received on Saturday, 17 August 2024 21:07:25 UTC