//Listのオブジェクトはデフォルト値からの差分が表現されているだけである。
//IDが必要である。他のパラメタはデフォルト値から変更がなければ必要がない。
//RefIDまたはRefIDsがListに設定されている場合は、メンバを作る必要があり、対応するオブジェクトまたはStringを設定する必要がある。
//ただ、ここのバージョン管理をどうするべきなのか全く不明である。RefIDの参照先が消えた場合、RefIDsのメンバ名が変更された場合、メンバがなくなった場合など。
//RefIDsに新メンバが追加された場合、参照先なし、nullの状態とすることで事なきを得ることが出来るだろう。メンバが削除された場合も、ないものにアクセスする人はいないから問題ない。
//list_idが変更される、これは面倒を見きれない。idが変更される、これもRenameのような追跡機能を作る価値はないように思う。
//根本的に、元jsonの仕様変更で参照先が消えてしまう、ということは当然起きるものとして、参照先はあればめっけもん、なくても問題ないようにプログラムを組むのが基本になると思う。
//そもそもlistからitemが削除されれば参照先はなくなってしまうので、参照先がなくならないことを前提にプログラムを組むべきではないように思う。まあ削除機能をなくして絶対に参照先がなくならないようにするのも手だとはおもうけれど、
//そのアプローチでは仕様変更には対応できず、仕様変更しないと頑なに誓っても変更は起きるものだろうと思う。
//参照先がid名の仕様変更でなくなってしまい、必要なデータが失われるようなら、古いバージョンのデータを使い回すのは諦めてもらうほかないだろう。
//デフォルトオブジェクトの変数の追加、これはデフォルト値が透過されるだけなので問題ないはず。
//変数の削除、削除したデータにアクセスする人はいないはずなので問題ないだろう。必要なら削除せず残しておくべき。どうせこのシステムは差分しか保存されないのだし。
//変数名の変更、これはまあやってもいいと思う。参照先IDとかではないので、パラメタになっていない以上管理可能だと思う。
//RefListIDsの変数の追加。これもデフォルトのnull、参照先なしが透過されるだけなので問題なかろう。
//RefListIDsの変数の削除、これも削除されたものにアクセスする人はいないので問題なかろう。
//RefListIDsの名前の変更、これはlist_idの変更にほかならない。
//list内オブジェクトでlist定義は出来ず、二重listは発生しない予定である。なのでlist_idはパラメタライズされていないと考えられる可能性もある。
//つまりlist_idはデータ全体で一意なので、ListIDのRename設定もデータ全体で一つのテーブルに管理させることで名前の変更も理論上可能と考えられる。
//問題はそこまでする価値はないだろうということ。なんでそこまでしてバージョン間でlist_idを変えながら動作させたいのか。
//list_idが変わった場合、「参照先なし」として動作してもらうことで、一応panicせずに動かすことは出来る。動いているうちに入るのかは謎だが・・・
//さらに、listごとにID名変更テーブルを設定可能にすることで、古い参照先を新しい参照先に対応させることも可能である。
//どっちにしても、参照先idが消える事態にはどうあがいても対応できないわけだが・・・やれるだけやるとしようか・・・？？？
//根本的に、参照先IDはパラメタライズされてるとは考えていない。実際勝手にIDを作ってlistに新規追加することは仕様上可能だけど、その使い方をバシバシしてくるとは思っていない。
//もっとデータは静的なものだと思う。ゲームでも薬草の新しいやつをゲーム中にプレイヤーが追加するよりも、製作者がアップデートで追加する方が普通だろう。
//しかし、キーでしかないただのIDを変更可能にする必要がどれだけあるのだろうか。可読性や意味を司るパラメータ名と違って、IDは他と区別するための記号という意味のほうが遥かに強いはずである。
//つまり、データが壊れるのが嫌なら被参照ListのIDは削除するな、変更するな、管理不能になるのが嫌なら追加も慎重にしろ、という掛け声だけで大半の問題は解決可能ではないかと思われる。
//list_idは可読性に関わるパラメータ名として立ち現れるので変更可能にすべきかも知れない。
//やはり、開発途中のデータと完成時のデータで、開発途中のデータが少しでも使えなくなる可能性がある変更は、完成時に整合性を持たせるために最終的に使わなかったものを削除していく、といった作業として現れてきて、
//「開発途中では作ってたけど最終バージョンではいらなかった」ものを一つ一つ判断するというおよそ不可能なことを行わなければならず、誤削除によって破綻してしまう可能性があるので、誤削除が起こりうるフォーマットはいずれ破綻すると思われる。
//誤削除が行われないようにするためには、削除を行う必要がないデータ形式にする必要があり、そのために「差分しか保存しない」使われず変化がないデータは保存されないので無視できるシステムになっていて、
//さらに使われなくなったidに関しても、削除でなくobsolete_hogeのようにIDを変更し脇に追いやることも可能になる。脇に追いやるのにID変更が必要なのかは必ずしも定かでないが・・・
//開発途中のどのバージョンのデータも、常に整合性をもって、管理可能な複雑度のまま最新バージョンで動かすことが出来る、というのでなければどうせ破綻するという考えに基づいて動くべきだと思う。
//そのためのプラクティスとして、「idの削除はしない」「id名、list_id名は変更可能なので、使わなくなったらobsolete_とかにして脇においやる」というのが良かろうと思う。

いや、list_idはともかくidの変更に実用的意味があると考えるのはおかしくはないか？
Obsolete機能を追加すべきだと思う。現行のデータがObsoleteなアイテムを参照している場合、警告が出る。
warning自体見ようと思わなければ見れない機能なので、どれほど意味があるのかは不明だが、「いらないものはObsoleteする」という推奨動作を与えてナッジすること自体は良い考えだと思う。

でもやっぱりidの変更機能も用意すべきだろうか。よくわかんないからとりあえず作ろうかな。

Obsoleteはどうするべきか。Obsolete : true? 印をつける標準的機能を用意するのには賛成だ。