[community-group] Group format (#105)

ilikescience has just created a new issue for https://github.com/design-tokens/community-group:

== Group format ==
In conversations about groups and tokens sharing a name (#97), I had a few ideas about group format.

The current spec has us write the tokens in a group as properties of that group. This affords a high level of flexibility in writing and reading tokens, but results in a lot of extra work on the parsing side[^1]. And that's a totally fine tradeoff to make, but I thought it might be worth exploring ways to get some more concrete definition/formatting in place to help parsers, without losing human read/write-friendliness.

So, an example group according to the current spec (not using prefixes currently being discussed in #61):

```json
{
  "colors": {
    "red": {
      "value" : "#ff0000"
    }, {
    "green": {
      "value": "#00ff00"
    }
  }
}
```

My suggestion (but by no means the only possibility) is that groups, like tokens, should have a "value" property.

```json
{
  "colors": {
    "value": {
      "red": {
        "value" : "#ff0000"
      }, {
      "green": {
        "value": "#00ff00"
      }
    }
  }
}
```

I don't write a parser/translator (hopefully the folks who do can weigh in), but I imagine that being able to expect every object to have a "value" property, regardless of it being a group or token, allows for some performance gains (and code maintenance gains).

Additionally, having all the group's tokens in a `value` property make it faster/easier to access them.

Finally, and this is just a personal aesthetic preference, but it makes me happy to have a very concise and consistent grammar associated with the spec; every object has a "value" property!

What do y'all think?

[^1]: in that getting the tokens in a group requires enumerating all the properties of the object, then removing any properties that are reserved words

Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/105 using your GitHub account


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

Received on Tuesday, 18 January 2022 15:28:23 UTC