YAML as an alternate format about community-group HOT 2 CLOSED

No need to apologise! We're keen for folks to question and challenge things in the spec draft.

We considered things like YAML and also extensions to JSON like JSON5 but eventually settled on plain JSON as we felt that was the most widely and consistently supported across different programming languages.

As for supporting YAML and JSON, my main concern would be interoperability. The goal of our spec is define a file format that allows people to easily and reliably exchange design token data between various tools. Any tool that supports the spec should be able to read or write files that any other tool that also supports the spec can handle. Therefore, if we allow both YAML and JSON that would mean that every tool that supports our spec would need to be able to read both formats.

My gut feel is that the extra work and testing that each tool vendor would have is likely to be a bigger barrier to adoption than JSON (arguably) being a bit less friendly to write than YAML.

from community-group.

Therefore, if we allow both YAML and JSON that would mean that every tool that supports our spec would need to be able to read both formats.

I can respect that. And I can also see how focusing on a single, unified format for now is the best way forward. As for OpenAPI supporting both, I’m actually not sure when it happened, but it is interesting that it has developed alongside JSON Schema and for the most part does tend to be JSON-focused.

I can respect not adding distractions now to the current priority of figuring out the general schema and token types, so again, JSON seems like a solid choice! Perhaps in the far future YAML could be considered if, as you said, the tooling has already stabilized and the community at large agrees.

from community-group.