Re: [community-group] Composite Token Composition (#179)

If built-in composite tokens cannot be modified, I'd recommend introducing `*-part` variants, such that translation tools can differentiate them from their fully-defined counterparts and apply looser validation requirements.

- **Strict Validation**:
    - all $value properties are REQUIRED, unless documented otherwise
    - $value MUST NOT contain extra, unsupported properties
- **Loose Validation**:
    - all $value properties are OPTIONAL
    - $value MUST contain at least one valid property
    - $value MUST NOT contain extra, unsupported properties


Strict Validation | Loose Validation
----- | -----
`strokeStyle` | `strokeStyle-part`
`border` | `border-part`
`transition` | `transition-part`
`shadow` | `shadow-part`
`gradient` | `gradient-part`
`typography` | `typography-part`
`<anotherType>` | `<anotherType>-part`


## Strengths
* Naming convention is simple, yet flexible enough to support new, built-in composite token types.
* Validation strategy allows for any combination of partially-defined composite tokens (infinitely flexible to authors' needs).

## Weaknesses
* No centralized algorithm on how to combine two or more partially-defined composite tokens.
    * Is this the spec's responsibility or the tokens author?



## Example: Typography

### Valid Definitions
```json5
{
  one: {
    $type: 'typography',
    $value: {
      fontFamily: "{alias.to.a.fontFamily}",
      fontWeight: "{alias.to.a.fontWeight}",
      fontSize: "{alias.to.a.dimension}",
      letterSpacing: "{alias.to.a.dimension}",
      lineHeight: "{alias.to.a.string}"
    }
  },

  two: {
    $type: 'typography-part',
    $value: {
      fontFamily: "{alias.to.a.fontFamily}",
      fontWeight: "{alias.to.a.fontWeight}"
    }
  },

  three: {
    $type: 'typography-part',
    $value: {
      fontSize: "{alias.to.a.dimension}",
      letterSpacing: "{alias.to.a.dimension}",
      lineHeight: "{alias.to.a.string}"      
    }
  }
}
```
- `one` defines a full `typography` token on its own
- combining `two` and `three` results in a fully-defined `typography` token



### Invalid Definitions
```json5
{
  four: {
    $type: 'typography',
    $value: {
      foo: 42
    }
  },

  five: {
    $type: 'typography-part',
    $value: {
      foo: 42
    }
  },

  six: {
    $type: 'typography-part',
    $value: {
    }
  }
}
```
- `four` does not define all required properties
- `four` defines an unsupported property
- `five` does not define any valid properties
- `five` defines an unsupported property
- `six` does not define any valid properties (empty)
- no combination of `typography-part` tokens will result in a fully-defined `typography` token

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


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

Received on Tuesday, 8 November 2022 00:12:10 UTC