Re: [community-group] [RFC] Format specification (#1)

Please correct me if I am wrong, but the point of this project is to define a Token Specification? The proposal itself clearly states, 

> At the moment, this proposal doesn't advocate for a particular file format (JSON, TypeScript…), it merely discusses what the shape of it should look like.

Is the purpose of this project to define a new standard [media type](https://en.wikipedia.org/wiki/Media_type)? The question I have is, what is the media type? Or is that still part of the discussion. 

I see this going one of a few ways. 

1. There is the pattern of the `application/ld+json` spec, e.g. the opportunity for `application/token+json`.
2. Or possibly a new text specification, e.g. `text/token`

In either case, there could be the argument for a new file type, e.g. `.tokn`

The differences between media types are subtle. If you are not familiar with the differences in media types, [read more](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types).

I bring this up as I see forks of this conversation expressing concerns with not only the storage of data but the transformation of and production of date from other data. The differences in that are huge. 

I also see opinions about strong typing and implementation. I feel these opinions are misplaced as there are two parts of a media type. The content and the engine. 

I feel that this conversation should be about the content, and the implementation of the engine is up to interpretation over time. E.g. the media type of `application/json` describes what [JSON is](https://www.ietf.org/rfc/rfc4627.txt), but not specifically how any platform is to execute this media type. 

Lastly, as this thread is getting increasingly long, what are the next steps to aggregate opinions and maintain focus on the objective?  

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

Received on Saturday, 29 February 2020 18:08:09 UTC