- From: Romain Menke via GitHub <sysbot+gh@w3.org>
- Date: Fri, 18 Nov 2022 08:37:29 +0000
- To: public-design-tokens-log@w3.org
I don't think the specification needs another convention to indicate that something is custom and I also don't think that that solves this issue. The specification already defines a good naming format for extensions that can be reused to indicate that a type is user/tool defined. this could be : `"$type": "com.toolprovider.custom-type"` --- What are the practical benefits of having a schema for user/tool defined typed? I don't see how any tool can provide any functionality for a token type it doesn't understand without having a full specification for how to define these schema's and how to act on them. --- Both aspects don't really have anything to do with the point of this issue. Which is that the JSON derived types are problematic because they are underspecified. After @ChucKN0risK stated that the purpose is to allow custom types I think they are vastly more problematic. > JSON derived types enable teams and tools to create proprietary types, which can help inform future spec iterations and we do expect more types to be needed in the future. User/tool defined types should be clearly marked as such, they should not be a side effect of vagueness in the specification. That again leaves JSON derived types without any purpose, which means they should be removed from the specification. -- GitHub Notification of comment by romainmenke Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/120#issuecomment-1319699426 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 18 November 2022 08:37:31 UTC