Re: [community-group] Add format schema (#360)

> I think we’ll likely revisit the language of the spec. But I think we’d need to keep it, wouldn’t we? Otherwise this couldn’t exist! I think it’s safe for someone opting into JSON Schema, to allow JSON Schema syntax.

It would certainly make it easier to use! But I think the schema could be useful even without allowing $schema. For example when used as a linter with something like [Ajv](https://ajv.js.org/). Or in Vscode you can also match certain files to schemas in [user settings](https://code.visualstudio.com/docs/languages/json#_mapping-in-the-user-settings). But in any case it is probably nicer to keep allowing `$schema` even if it is not specifically allowed in the technical report.

> Yes we should allow for any number of components. This is more just future-proofing, because even though the currently-supported colorspaces all happen to have 3 components, we plan on expanding these and in the future, CMYK colorspaces would have 4+. Changing it now would just mean not having to change it later.

Moved the restrictions to the color space definitions 👍

> I’m not sure, actually! VS Code seems to have pretty decent 2020-12 support. Are there certain features you opted out of that would be helpful? I think I’d need to understand the tradeoffs a little more.

Both [schemastore](https://github.com/SchemaStore/schemastore/blob/master/CONTRIBUTING.md#best-practices) and [ajv](https://ajv.js.org/guide/schema-language.html#draft-2019-09-and-draft-2020-12) recommend the `draft-07` version for better tooling support and performance.

The main feature we'd lose is `unevaluatedProperties`. This keyword is aware of properties defined anywhere in the schema composition (via `$ref`, `allOf`, etc.), whereas `additionalProperties` only sees properties defined in the immediate schema.

In practice, this means you can't both:
1. Reference a shared definition from another schema
2. Add extra properties to it
3. Still forbid any property not explicitly defined

With `unevaluatedProperties` in draft-2020-12, I could [reference `groupProperties` and combine it with a `$schema` property](https://github.com/dgtlntv/dtcg-json-schema/blob/80f239e80ecc4ef33366d4f269bd3548ce9eacb3/schemas/format/format.json#L8) while still rejecting unknown properties.

In draft-07, using `additionalProperties: false` would reject the referenced properties too (since it doesn't "see" them). So instead, I had to [inline the full definition](https://github.com/dgtlntv/dtcg-json-schema/blob/0c62389cfe6c36deb2a312e9cb3f8bc0a6348120/schemas/format/format.json#L7).

This makes things slightly less DRY. If I remember correctly, this only affects two places: the root format.json definition linked above, and the resolver schema where I had inline vs normal sets/modifiers.

> That would be great! We use [Vitest](https://vitest.dev/) in this repo, so as long as they are convertible to that, that would be a great addition.

I wasn't able to find any existing set up for tests in this repo. Do you have any guidance where/how to set it up? I don't think transitioning to Vitest should be an issue.

> I was not able to easily test it because of the absolute $ref URLs that point to files that don’t yet exist. I left this comment elsewhere, but could we try relative URLs, at least for testing? I have several documents in [dtcg-examples](https://github.com/design-tokens/community-group/pull/github.com/terrazzoapp/dtcg-examples) I could test them on.

I moved all of the `id`'s and `ref`'s to be relative for testing now. From my understanding it is ok for the `ref`'s to be relative but `id`'s should [ideally be absolute](https://json-schema.org/understanding-json-schema/structuring#id) in the final version.

-- 
GitHub Notification of comment by dgtlntv
Please view or discuss this issue at https://github.com/design-tokens/community-group/pull/360#issuecomment-3633236907 using your GitHub account


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

Received on Tuesday, 9 December 2025 16:47:58 UTC