これら 
kb10uy(@kb10uy@mstdn.maud.io)の投稿
もみあげの長い美少女の話ばかりしています
Avatar icon: [𝕏] CamemBellcheese
Header: [𝕏] generalcanon
各種フレコ:
beatmaniaIIDX(八段): 1751-5340
オンゲキ(15.8): 3067667719792
Arcaea(◆9): 433827474
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
UE4はその点から考えるとあんまりmod作るのに向いたゲームエンジンではなさそう。立ち位置がDLCになりがちなので
VMで動く処理系の上にあるゲームなら最悪でも適切なインジェクション(jarやD3DやOpenGL)入れれば本体と同じレイヤーで動かすことはできそうだけど本体がネイティブだとまあ本体側に配慮がないと割と厳しそうではあるねえ
このアカウントは、notestockで公開設定になっていません。
MaidForge みたいな名前のフォーラムがあったらまた違ったのかもしれないけど発生しなかったっぽいしなあ
それはそうとさっきセルフBTしたのはこれだけ各所からうちのこを集めると僕が使いこなせないようなパーツも使いこなしててセンスの多様性を感じるというやつです
簡単に言うと、スキーマによる検証がドキュメントに新しい情報を付加できるべきか否かみたいな話
＠IT：XMLにおける「ボヘミアンと貴族の階級闘争」を読み解く
https://www.atmarkit.co.jp/fxml/tanpatsu/24bohem/01.html
この辺りの話を知っていると、ｲﾝﾀｰﾈｯﾂネイティブな文書が必ずしもプロセッサにとってネイティブなデータ構造として表現されるべきかというのは自明ではないよね
そういえば気になってたことがあって、XMLは1.0なのにv5とかあるのはどういう経緯なんだろう
全てを RDF で交換できる世界であればそれが良かったかもしれないけど、まあそれは無理な話なので……
これは手段と目的が逆で、「既存のデータを (context 追加以外に) 極力変更することなく解釈可能にする」というのが JSON-LD の目標なので、既存データが tagged union 風でない以上、 JSON-LD が扱うデータもそうなるわけです
{"tag": "foo", "data": ...}
みたいに「確定で読めるプロパティが1つあってそれを読めば残りの展開が確定する」タイプの構造なら良かったのに……
AP 自体は JSON-LD 対応を optional なものと位置付けているので、 JSON-LD 対応せず ActivityPub 処理系を実装することはできます
あれがまだtagged union みたいな感じで判別できれば良かったものを、いきなり string | object みたいな型が生えてくるのでキレる
あとはなんだろうなあ、真面目に扱おうとするとcontext周りでリクエスト飛ばしたり検証したりするハメになる
it's not really fun なのは JSON-LD だよ！！！
このアカウントは、notestockで公開設定になっていません。
