記事にアンケートを添付します。 状況の把握にご協力ください。 :-)
最初の理由-Ångströmスタイルシステム
ÅSSを行ったとき 、スタイルを記述するためのデータ形式が必要でした。 JSONを選択しました。 多数の理由により、その主なものは証拠です。 このフォーマットは優れた高速解析（私が比較した）であり、しかも非常にシンプルです。 これは、これらの行に何でも詰め込んで（プロパティ、名前、値用に2つ持っている）、好きなように解釈できることを意味します。 一方では便利ですが、他方ではこのシステムの脆弱性は完全に不十分です。 特に、Swiftのような強く型付けされた言語で作業する場合。
また、文字列（配列、連想配列）だけでなく、プロッターをプロップにしたかったのです。つまり、名前は識別子であり、スペースで奇妙なものではありません。 これにより、近い将来、たとえばAppCodeまたはSublimeのプラグインを作成できるようになります。これにより、スペルが正しいかどうかがチェックされ、何か間違っている場合は強調表示されます。 おそらく、@リンクの自動補完などがあります。
また、いくつかのタイプが欠落していました。 色はスタイラーにとって最もシンプルで最も必要なものなので、K2 for S2で始めました。 ただし、KTVには他の「ネイティブ」タイプが表示されます。
2番目の理由はAPI
アウトソーシングで作業するときは、モバイルアプリケーションにさまざまなAPIを常に実装する必要があります。 それを書いた人々の「誠実さ」の度合いは、時には評価に役立たないことがあります。これらは幻想的に奇妙な構造です。 そして、そのような構成の主な理由はJSONです。 それはあなたが何でも何でもすることができます。 賢明な人々はこの思考の流れを制限しようとし、 http：//jsonapi.orgのような素晴らしいプロジェクトを手に入れますが、フォーマットがJSONのままである限り、どこにも何も移動しないように思えます。 Swiftの Kotlin が登場したのは何の理由でもありません。そのような場合は、null / nilを割り当てることができません。これには特別な型が必要です
たとえば、車のブログなど、投稿のフィードを取得します。 好きな投稿のリストがあり、そこからユーザー、ユーザーの車へのリンクがあります。 1人のユーザーは10の投稿と20のいいね！を持つことができます。 ユーザーが投稿/いいね！（投稿だけでなく、投稿が好きなユーザーやコメントを投稿するユーザーがいる）ごとに複製することは価値がありますか？ いいえ、間違いなく価値はありません。 解析時に必要な場所に挿入されるIDとオブジェクトのフラットリストを使用して、これを解決しました。 しかし、私には、この機能をフォーマットに追加する方が便利だと思われます。 そうすれば、毎回車輪を再発明する必要はありません。この機会を実現する明白な方法があります。
新しいフォーマットは必要ですか？
記事は、もちろん、これらすべての問題の解決策が必要であることを示しました。 意見の二極化、この共通の問題を解決するための単一の方向の欠如、「そして私は気分が良い」-これらすべては、XML対JSON紛争を思い出させます。 KTVは「次のJSON」になるとは決して言いたくありませんが、すべてのサーバーとクライアントの開発者（クライアントはWebだけでなく、モバイルアプリケーションや他のサーバーも）独自の何かを発明することを止めました。 相互作用と発明に多大な労力が費やされています。
同時に、 http：//jsonapi.orgのメンバーが選択したパスは、長期的には間違っていると思います。 それ自体が優れています。 私は、コミュニティ全体にこれらの推奨事項に従うことを強制することが可能になるとのみ考えています。 すでにこれを行っています。XML-RPC、つまりSOAPです。 これはすべて、契約の枠組みで自由形式をクランプする試みです。 経験が示しているように、それは固定しません（より正確には、固定しますが、企業のフレームワーク内でのみ）。 普遍的に使用されている新しいタフなフォーマットのみが、開発者に同じ方法でAPIを同期させ、形成させることができます。 少なくともシンプル。
KTVがこの方向に役立つかどうか-わかりません。 彼は数ヶ月で、まだ小さく、愚かです。 それは本格的なフォーマットに成長することができます、それは素晴らしいでしょう。 いいえ、それはまた素晴らしいです、私は別の、より良い申請者がその残骸に現れることを望みます。