Re: [community-group] The $ property name prefix should be unnecessary with a well-structured schema (#225)

I understand the goals you have for using the prefix, but the prefix really isn't necessary to reach them:

1. **Consistency Across the Specification**: If you drop the `$` prefix, you'll have the consistency of... not using a prefix. I don't think adding one or not creates consistency. The only inconsistency would be if you used prefixes in some places and not in other. To be clear about what I'm proposing: it's that you don't use prefixes anywhere because they're unnecessary.
2. **Collision Prevention**: The standard way to avoid collisions with user-defined keys in JSON schemas is to define a separate object that's entirely user-defined - a general key/value object. As the schema evolves, it evolves within the objects that hold the schema-defined keys. The example I showed above has this quality: there is no object with both schema-defined and user-defined keys.
3. **Clear Token vs. Nested Group Differentiation*: I would argue that the current schema which has some keys belong to the schema and some to the user-defined data is _less_ clear, and having a nested key/value object for nested tokens would be more clear.

I think the style of schema I'm advocating here is by far the more common and plain way to design a JSON schema. Again, I've never seen a schema like this one where all the keys are prefixed and I immediately found it exceedingly odd. I was thinking there had to be an exceptional reason for it, but the reason you give are all not actually problems with the more common JSON schema design.

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


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

Received on Sunday, 13 August 2023 23:23:04 UTC