不要な配慮を仕様から撤廃: 「（※）ウェブサーバ及びオペレーティングシステムにおける拡張子の登録状況を考慮し、拡張子をtxtとしている。」

[usagi]

概要

https://github.com/gsi-cyberjapan/layers-dot-txt-spec/blob/master/specifications.md#%E9%81%A9%E7%94%A8%E7%AF%84%E5%9B%B2

（※）ウェブサーバ及びオペレーティングシステムにおける拡張子の登録状況を考慮し、拡張子をtxtとしている。

と記述されているが、

1. この記述が追記された 2015-09-18 時点でも JSON は十二分に普及したフォーマットでした。おそらく、この判断を行った時点でも本質的な問題も「ウェブサーバ及びオペレーティングシステムにおける拡張子の登録状況」ではなく HTTPd に設定すべき MIME (本仕様側ではなくHTTPdの設定課題) というだけの事ではなかったのかな、と思います。
   • ca0abfe#diff-ea143bba157429c58a3ba7f3185734dfR6
2. 2020-09 現在、 JSON の扱いが MIME 上問題になる一般的な HTTPd は存在しないし、OSの拡張子登録状況は事実上まったくこの仕様やこの仕様を用いるアプリ実装には関係ないのではないかと思います。

つまり、これただの微妙に迷惑な謎仕様というだけなのではないかと思います。

期待される解決

1. 仕様として .txt ではなく .json に変更する。
2. 仕様から拡張子やOSについての曖昧な謎理由の注記も撤去する。
3. (optional) 格納ディレクトリーの仕様も layers_txt から layers または適当な意図を表すだけの名称に変更する。
4. 現在の URL を直接参照しているサードパーティー製のアプリなどの配慮を明確に決め実施する。
   1. 変更の事前の十分な期間での告知: アクティブな8割以上のサードパーティーアプリの開発者が対応できるように少なくとも1ヶ月以上、ながければ3ヶ月程度前には告知するのが望ましいでしょう。
   2. 変更は gsimaps においては HTTPd で 301 Moved Permanently を ./layers_txt/.txt -> ./layers_txt/.json となるように設定し、可能な限り恒久的にこの設定を保持する
   3. (optional) 格納ディレクトリーも変更する場合はディレクトリーレベルでの 301 Moved Permanently も設定する

---

もし、謎仕様ではなく有効な具体例が実在する場合は仕様書に明確に「ｘｘがｘｘでｘｘするのは問題なので合理性の観点から .txt 拡張子及び text/plain MIME を用いる」のように理由を列挙し、謎仕様ではないことを明確に示し、将来的に仕様を一般的な設定に合わせられるとすれば一体どのような課題を解決すればよいのか、あるいは事実上解決できないから仕様として諦めるよりほかないのか、自明な表現にします。

[johofukyu]

ご指摘ありがとうございます。

拡張子については、過去の経緯から".txt"としており、地理院地図等のプログラムもこの仕様に基づいてプログラミングされております。また、地理院地図のレイヤ定義ファイルは既に様々なシステムから参照されていることから、恐れ入りますが拡張子は現行のままとさせていただきます。

しかしながら、ご指摘を踏まえ、「（※）ウェブサーバ及びオペレーティングシステムにおける拡張子の登録状況を考慮し、拡張子をtxtとしている。」及びそれが引く「（※）」については、規約から削除いたします。

よろしくお願いいたします。

[usagi]

また、地理院地図のレイヤ定義ファイルは既に様々なシステムから参照されていることから、恐れ入りますが拡張子は現行のままとさせていただきます。

そのために 301 Moved Permanently も提案しているのですが失礼ながらご検討頂いた上でのご判断でしょうか？よりよいプロジェクトの未来のためにあくまでも建設的にご確認頂ければ幸いです。

もちろん、検討の上で、否定理由はコメント頂かない上でも仕様としてそうするのだとAuthorさんが決めれば、サードパーティー開発者等々はそれはそれでただ従うだけの事ではあります。しかし、より合理的で美しく現実的な既存実装や慣れのユーザビリティーにも配慮できる選択肢があると考えて起票しましたので、起票に際して提案した方策について否定される場合は十分な理由も明示頂けると起票者としても心中すっきりいたします。

[johofukyu]

ご提案いただいた方法で技術的な解決はできるものと承知しておりますが、国土地理院におけるシステム運用コストを考慮した結果、現行のままとさせていただきたいと思います。
これらの問題のクリアのめどが付いた際には、いただいたご意見を参考に対処を検討いたします。