{知番譜類}{知番}{.oln}{希哲15年12月19日の開発}{統合せず}{無理に}{.d 接尾子}{特殊な拡張子}{.unk}{適当な拡張子}...=}(102)

{希哲15年12月19日1歩 K#F85E/A-E74C-00D9}

分割格納方式への移行作業前に,知番譜類における拡張子扱いについて検討して終了

従来通り無接尾子知番譜台許容することにした。

これまでの自我台録/kn/K#F85E/には無接尾子譜台いくつかあるが,譜類添付機能合わせ,これを全て拡張子付き練名することを考えていた

そもそも知番譜類は,知番譜類名にしてデルン上管理する譜類管理手法として始まり,デライト開発本格化してからこの経験を元に拡張子毎添付譜類という概念固まった

当初一貫性観点からむしろ無拡張子基本考えていたため,初期知番譜類には無拡張子実体拡張子付き疎輪結置いているものがある。ただこれは煩雑な上に,Windows 仮想機上手く扱えない問題があったため次第にやらなくなった。以後,普通に拡張子付けることが多くなった

いっそのこと,全て拡張子付きにして譜類添付機能との整合を取るかと考えたわけだが,全ての譜類適当な拡張子があるわけではなく,必ず指定するとなると煩雑化恐れがある。適当な拡張子がなければ .unk のような特殊な拡張子を使う,台録なら .d 接尾子を使うなど仕様複雑化する。

仮に無拡張子知番譜台空けたところで,その使い道があまり無いという問題もある。本来輪郭情報を置くのが適当なところだが,エクスポート機能等では閲覧編集都合から .oln を使うことを決めている分割格納方式採用したことで利便性いずれにせよ知機駒手補うしかなくなっているので,実体場筋利便性持たせる必要もなくなった。

譜類添付機能エクスポート機能はあくまでも知番譜台応用として,無理に統合せず一定相互運用性確保しておくに留めるのが最善結論付けた

ただ,拡張子用の疎輪結だけは問題なので普通の拡張子付き練名しておくことにした。

=}
{希哲15年12月13日の開発}{冗長過ぎる}{application/x-kn-acv}{揺らいだ}{KNIF_ 接頭子}{KFF- 接頭子}{KFF}{KN-ACV}{混同の恐れ}{KN- 接頭子}...=}(113)

{希哲15年12月13日4歩 K#F85E/A-E74C-143E}

アンダースコア略記法内包子におけるアンダースコア記法廃止についての検討終了

現状譜類名(例:._acv台録名(例:/_kn/駒手名(例:_knなどにアンダースコア接頭子略記法として多用していた時期名残り多くあるが,ほとんど活用していないため,いったん廃止することを決めた

アンダースコア略記法やその応用記法問題は,明示性簡潔性ともに中途半端で,現実には使いにくいというにある。より簡潔な記法冗長な記法があると使い分け方無駄増えややこしいし,使い所無い

知機駒手では大分前から _kn よりも kn使うようになっているが,9月9日13歩以後はこの kn省けるようにしたため,_出番完全に無くなってしまった結局 _ よりも kn使ってしまう理由は,どうせ面倒臭いなら分かりやすい方が良い,ということだった気がする

これまでの経験上十分明示的な冗長記法短縮記法2つまとめていくのが一番良さそうだ。


KNIF使っていたアンダースコア記法廃止し,代わりに kn- 接頭子導入することを決めた

例えば,これまでの ._acv冗長表記.kn-acv短縮表記.acv となる。知機駒手同様,混同の恐れが無い場合は原則として短縮表記用いる

.kn.acv のようにすることも考えたが,一つの拡張子として認識されないと不都合なこともあるので,MIME 型application/x-kn-acv正式名称初期合わせるKNIF の各形式与える正式名称は,旧称 KFF の時は KFF- 接頭子KNIF になってから KN-ACV のような KN- 接頭子になり,一時 KNIF_ 接頭子揺らいだこともあったが冗長過ぎる,これを機に KN- 接頭子確定する


アンダースコア記法依存した実装排除しながら段階的置換進めていく

=}
{終了}
{}