@adobe/design-data-spec 4.3.0 → 4.4.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/schemas/manifest.schema.json +20 -0
- package/spec/authoring-workflow.md +1 -0
- package/spec/component-format.md +3 -1
- package/spec/index.md +2 -0
- package/spec/manifest.md +30 -9
- package/spec/taxonomy.md +2 -0
package/package.json
CHANGED
|
@@ -14,6 +14,21 @@
|
|
|
14
14
|
"minLength": 1,
|
|
15
15
|
"description": "Pin to a foundation release (semver or tag)."
|
|
16
16
|
},
|
|
17
|
+
"platform": {
|
|
18
|
+
"type": "string",
|
|
19
|
+
"minLength": 1,
|
|
20
|
+
"description": "Machine-readable platform implementation id (e.g. \"react-spectrum\", \"web-components\", \"ios\"), matching an id in the platform-implementations registry. Optional: a manifest MAY be anonymous (e.g. a single-platform repo where identity is implicit), but SHOULD declare it once the manifest is relocatable (fetched remotely, or one of several manifests in the same repo)."
|
|
21
|
+
},
|
|
22
|
+
"platformVersion": {
|
|
23
|
+
"type": "string",
|
|
24
|
+
"minLength": 1,
|
|
25
|
+
"description": "Human-readable description of the platform implementation this manifest targets, e.g. \"React Spectrum 3.x\" or \"Spectrum Web Components 0.x+\". Distinct from `foundationVersion` (the pinned foundation release)."
|
|
26
|
+
},
|
|
27
|
+
"repository": {
|
|
28
|
+
"type": "string",
|
|
29
|
+
"minLength": 1,
|
|
30
|
+
"description": "URL of the repository that owns (or, during incubation, will eventually own) this platform manifest, e.g. \"https://github.com/adobe/react-spectrum\"."
|
|
31
|
+
},
|
|
17
32
|
"include": {
|
|
18
33
|
"type": "array",
|
|
19
34
|
"items": {
|
|
@@ -138,6 +153,11 @@
|
|
|
138
153
|
"type": "string"
|
|
139
154
|
},
|
|
140
155
|
"description": "Map of full term to abbreviated form, applied after ordering and before casing."
|
|
156
|
+
},
|
|
157
|
+
"prefix": {
|
|
158
|
+
"type": "string",
|
|
159
|
+
"minLength": 1,
|
|
160
|
+
"description": "Literal string prepended to the fully-formatted token name (after casing/delimiter are applied), unaffected by `casing` itself. For platform naming conventions that wrap the token name rather than reshape it, e.g. CSS custom properties (`--spectrum-`) or other namespaced identifier prefixes."
|
|
141
161
|
}
|
|
142
162
|
},
|
|
143
163
|
"additionalProperties": false
|
|
@@ -20,6 +20,7 @@ The source-of-truth direction is already normative in [Evolution](evolution.md#l
|
|
|
20
20
|
|
|
21
21
|
* Specifying the *output format* of generated artifacts. Legacy format mapping is defined in [Evolution — Legacy format contract](evolution.md#legacy-format-contract); DTCG and StyleDictionary outputs are deferred (RFC [#627](https://github.com/adobe/spectrum-design-data/discussions/627)).
|
|
22
22
|
* Specifying the *consumer-facing API* of published packages (`@adobe/spectrum-tokens`, platform SDKs). Those are separately governed.
|
|
23
|
+
* Restating the full semantics of external implementation contracts already owned by their native standards or package ecosystems. This spec links to authoritative sources instead of duplicating their normative rules.
|
|
23
24
|
* Specifying the *UI* of the authoring tools; this document defines behavioral contracts, not user-interface design.
|
|
24
25
|
* Multi-user collaboration, permissions models, and Figma sync direction (open questions in RFC [#625](https://github.com/adobe/spectrum-design-data/discussions/625)).
|
|
25
26
|
|
package/spec/component-format.md
CHANGED
|
@@ -6,6 +6,8 @@ This document defines the normative **component declaration** object: identity (
|
|
|
6
6
|
|
|
7
7
|
Component declarations close the structural gap between the token name-object's `component`, `variant`, `anatomy`, and `state` fields and the declared surface of each component. Before this chapter, a token referencing `component: "button"` with `variant: "foo"` was undetectable as invalid because no machine-readable component contract existed in the same spec. After this chapter, validators enforce cross-reference rules (see [SPEC rules](#spec-rules)).
|
|
8
8
|
|
|
9
|
+
This chapter defines the Design Data contract for a component. It intentionally does not restate the full platform-native component API, story/example-format semantics, or other standards already owned elsewhere. When another authoritative specification already defines an implementation contract or format, this document points to that source instead of duplicating its normative rules.
|
|
10
|
+
|
|
9
11
|
Scoped under [RFC-A — Component Contract in Design Data Spec](https://github.com/adobe/spectrum-design-data/discussions/832). See also [rfc-coordination.md](../docs/rfc-coordination.md).
|
|
10
12
|
|
|
11
13
|
## Document shape
|
|
@@ -109,7 +111,7 @@ names and references.
|
|
|
109
111
|
|
|
110
112
|
## Options
|
|
111
113
|
|
|
112
|
-
The `options` block declares the component's API surface — the configurable properties that affect its appearance or behavior. It
|
|
114
|
+
The `options` block declares the component's API surface — the configurable properties that affect its appearance or behavior. It is the Design Data contract for the component surface that this repo validates; it does not duplicate the entire implementation-owned API schema. For exhaustive platform-specific semantics, follow the authoritative implementation contract instead of restating it here.
|
|
113
115
|
|
|
114
116
|
**NORMATIVE:** `options` **MUST** be a JSON object. Each key is an option name; each value is an **option descriptor**.
|
|
115
117
|
|
package/spec/index.md
CHANGED
|
@@ -30,6 +30,8 @@ The specification defines:
|
|
|
30
30
|
16. **Authoring workflow** — normative contract for authoring design data via tooling: authoritative source location, lifecycle operations (create / edit / deprecate / rename / alias-rewire / mode-set management), taxonomy-aware decomposition requirement, and output-generation obligations ([Authoring workflow](authoring-workflow.md)).
|
|
31
31
|
17. **Relationship format** — Component/Token Relationship (CTR): the anonymous-token entity unifying `tokenBindings` and token name-object scope fields, explicit relationship context, options validation, and interim legacy-compatibility fields ([Relationship format](relationship-format.md)).
|
|
32
32
|
|
|
33
|
+
This specification intentionally defines the Design Data-owned contract and links to external standards for platform-native implementation semantics instead of restating those contracts as normative local rules. The repository owns taxonomy, validation, lifecycle, and schema rules; the authoritative source for native format behavior remains the external standard it describes.
|
|
34
|
+
|
|
33
35
|
## Conformance
|
|
34
36
|
|
|
35
37
|
The key words **MUST**, **MUST NOT**, **SHOULD**, **SHOULD NOT**, **MAY**, and **OPTIONAL** in this specification are to be interpreted as described in [BCP 14](https://www.rfc-editor.org/info/bcp14) \[[RFC2119](https://www.rfc-editor.org/rfc/rfc2119.html)] \[[RFC8174](https://www.rfc-editor.org/rfc/rfc8174.html)] when, and only when, they appear in all capitals, as shown here.
|
package/spec/manifest.md
CHANGED
|
@@ -41,15 +41,18 @@ A manifest **MUST** conform to [`manifest.schema.json`](../schemas/manifest.sche
|
|
|
41
41
|
|
|
42
42
|
## Optional fields
|
|
43
43
|
|
|
44
|
-
| Field | Type | Description
|
|
45
|
-
| --------------------- | --------------- |
|
|
46
|
-
| `
|
|
47
|
-
| `
|
|
48
|
-
| `
|
|
49
|
-
| `
|
|
50
|
-
| `
|
|
51
|
-
| `
|
|
52
|
-
| `
|
|
44
|
+
| Field | Type | Description |
|
|
45
|
+
| --------------------- | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
46
|
+
| `platform` | string | Machine-readable platform implementation id (e.g. `"react-spectrum"`, `"web-components"`, `"ios"`), matching an id in the platform-implementations registry. See [Identity fields](#identity-fields) below. |
|
|
47
|
+
| `platformVersion` | string | Human-readable description of the platform implementation, e.g. `"React Spectrum 3.x"`. Distinct from `foundationVersion`. |
|
|
48
|
+
| `repository` | string | URL of the repository that owns (or will eventually own) this platform manifest. |
|
|
49
|
+
| `include` | array of string | Semantic **queries** selecting subsets of foundation tokens to materialize. |
|
|
50
|
+
| `exclude` | array of string | Queries removing tokens from the included set. |
|
|
51
|
+
| `overrides` | array of object | Typed overrides; each entry **MUST** preserve the target token’s **value type**. |
|
|
52
|
+
| `extensionsDir` | string | Path (relative to the manifest) to the platform's `extensions/` directory. Default: `"extensions"`. See [`extensions/` directory](#extensions-directory) below. |
|
|
53
|
+
| `namingExceptions` | object | Platform-local overlay on the base naming-exceptions set: names to add and/or remove for this platform's naming validation. |
|
|
54
|
+
| `formatting` | object | Rules for serializing structured name objects into platform-specific token name strings. |
|
|
55
|
+
| `modeSetRestrictions` | object | Mode set restrictions for this platform; see [Mode Sets — Platform restrictions](mode-sets.md#platform-restrictions). |
|
|
53
56
|
|
|
54
57
|
### `include` / `exclude`
|
|
55
58
|
|
|
@@ -75,6 +78,23 @@ apply `Foundation < Platform < Product` precedence to select a single winner. To
|
|
|
75
78
|
counts "tokens a platform ships" from `query` output should resolve first, or it will
|
|
76
79
|
double-count overridden tokens.
|
|
77
80
|
|
|
81
|
+
### Identity fields
|
|
82
|
+
|
|
83
|
+
`platform`, `platformVersion`, and `repository` are optional and have no effect on the
|
|
84
|
+
Foundation→Platform cascade — they exist so a manifest is self-describing wherever it
|
|
85
|
+
lives. This matters once a manifest is one of several configured in the same repo (via named
|
|
86
|
+
`[platforms.<id>]` profiles — see the SDK's `.design-data.toml` reference) or is fetched
|
|
87
|
+
from a remote repository: without `platform`, a manifest fetched by URL has no stable
|
|
88
|
+
identity of its own.
|
|
89
|
+
|
|
90
|
+
A single-platform repo with exactly one manifest **MAY** omit all three; the pattern
|
|
91
|
+
becomes worth adopting the moment a manifest is expected to move (incubating in a
|
|
92
|
+
monorepo ahead of a hand-off to its owning team) or coexist with siblings.
|
|
93
|
+
|
|
94
|
+
`platform`, when present, **SHOULD** match an id in the platform-implementations registry
|
|
95
|
+
(distinct from the token-level `platforms.json` registry, which enumerates *device
|
|
96
|
+
targets* like `desktop`/`mobile`, not *implementations* like `react-spectrum`).
|
|
97
|
+
|
|
78
98
|
### `extensions/` directory
|
|
79
99
|
|
|
80
100
|
**NORMATIVE:** Platform-local additions are declared as a sibling **directory** next to
|
|
@@ -216,6 +236,7 @@ A platform **MAY** declare formatting rules that control how structured name obj
|
|
|
216
236
|
| `casing` | string | One of: `kebab-case`, `camelCase`, `PascalCase`, `SCREAMING_SNAKE_CASE`. Default: `kebab-case`. |
|
|
217
237
|
| `delimiter` | string | Character(s) separating concepts in the serialized string (e.g. `-`, `_`, `.`, `/`). Default: `-`. |
|
|
218
238
|
| `abbreviations` | object | Map of full term → abbreviated form (e.g. `{ "background": "bg" }`). Abbreviations are applied after concept ordering and before casing. |
|
|
239
|
+
| `prefix` | string | Literal string prepended to the fully-formatted token name, applied after `casing`/`delimiter` and unaffected by either — for platform naming conventions that wrap the token name rather than reshape it (e.g. CSS custom properties like `--spectrum-`). |
|
|
219
240
|
|
|
220
241
|
**NORMATIVE:** When `formatting` is absent, the default serialization defined in [Taxonomy](taxonomy.md#default-serialization-legacy-format) is used.
|
|
221
242
|
|
package/spec/taxonomy.md
CHANGED
|
@@ -4,6 +4,8 @@
|
|
|
4
4
|
|
|
5
5
|
This document defines the **token taxonomy**: a hierarchical system of concept categories that classify design tokens, the **token term vocabulary** of allowed words within each category, and the **formatting style** rules that control serialization of structured token names into platform-consumable strings.
|
|
6
6
|
|
|
7
|
+
This chapter defines the Design Data-owned taxonomy contract. It intentionally does not restate platform-native naming semantics or external standards already owned elsewhere; when a platform or implementation standard defines those behaviors, this spec links to that authority instead of copying its normative rules.
|
|
8
|
+
|
|
7
9
|
## Motivation
|
|
8
10
|
|
|
9
11
|
"Naming convention" is too broad a term when discussing malleability across platform teams. A token name like `accent-background-color-hover` embeds multiple independent decisions:
|