uniform resource locator

{あれK#F85E/A-E74C-0988}

{希哲16年2月19日11歩 K#F85E/A-E74C-D1B5}
何気なくマイクロブログサービスの用者を示せる記法が欲しいという考え事をしていたら「外部サービス利用者記法」に発展したので,軽くまとめて終了。
とりあえず,分散型 SNS で使われている記法を拡張し,@[用者名]@[ドメイン名]
の汎用記法を整備する方向で進めることにした。
要は,@user
と書いたら Twitter に輪結したり,@user@example.com
と書いたら分散型マイクロブログの捌き手に輪結してもいいのではないか,と考えたことがきっかけだった。
ここで一つ,@user@example.com
は https://example.com/@user
に必ず対応するのだろうかという疑問が湧いた。以前にもなんとなく考えたことはあったが,ActivityPub というか Webfinger で URL を引き出したり,面倒臭そうな気がして進展しなかった。このあたりの仕様がどうなっているのか,いまだによく分からない。
もっとも,ざっと見渡す限り分散型マイクロブログの捌き手は大体 https://example.com/@user
になっているし,自分で Mastodon 捌きを運営していた時も出放りはこれだったので,事実上の標準とみなしていいのかもしれない。
Twitter は @user
でいいかと思っていたが,いくら普及しているとはいえ,これは特定サービスに寄り過ぎだろうということで,@user@twitter.com
で統一することを考えた。ただ,Twitter のプロフィールページの正規 URL は https://twitter.com/user
だ。https://twitter.com/@user
でも転送されるとはいえ,若干気持ち悪い。
さらに,この時点では @user@twitter.com
と書けば @user
と表示されるという仕様を考えていたため,いずれにせよ特定サービス向けの処理を追加出来るようにする必要があった。
ここまで考えたところで,いっそのこと @[用者名]@[ドメイン名]
として,外部サービスの用者を指すための汎用的な記法にしてしまえばいいのではないか,と思えてきた。これは,B̅ 氏が独自に同様の記法を使っているのを見ていたことが大きかった。
[ドメイン名]
は,@[用者名]@twitter
のように自明なら短縮出来るようにしてもいいかもしれない。対応サービス毎に用者名を解釈,輪結先を調整し,それ以外は https://[ドメイン名]/@[用者名]
に輪結する。
少し困ったのは,簡潔で分かりやすい名前が見つからないことだ。一応平たく「外部サービス利用者記法」を仮称としておく。
「異邦人記法」というのも面白いかもしれないと思ったが,一見して意味が分かりにくいので別名としてしか使えないだろう。「宛名記法」はどちらかというとメールアドレス向きか。
デライトで使う予定が全くなかったため,@[用者名]
という表示は Twitter のために使うつもりだったが,これは止めておく。
そもそも SNS などでは自サービス上の用者に対する言及という意味を持つ記法から来ている。デライトで使わなかったとしても,この種の記法を必要とするサービスにはデラングが応用出来ないことになってしまう。
ここから @[用者名]
の本来の意味を考え始め,知番・輪符などと組み合わせる可能性に気付いた。これは「言及記法」として別途検討することにした。

{希哲16年2月16日の日記 K#F85E/A-E74C-67EE}
今日は一日がかりで昨日分のまとめを終わらせるつもりだったが,3分の1くらいしか終わらなかった(15日10歩未完)。
それなりの内容でもあり,昨日の反動でぼんやりしてしまう時間があったこともあるが,デラング構想についての考え事が広がったのも大きかった。
文字装飾記法についての整理から,HTML 研究の必要性を感じた。ウェブアプリを作っているので実用上必要なことは当然知っているが,細かい歴史や設計については知らないことが多い。的確なデラング設計のためには表面的な理解では足りない。文字装飾記法でそれを痛感した。
さらに言えば,幅広く標記言語研究をしたくなった。これまでデラングは「理想の軽量標記言語」を目指してきたが,タグ記法によってその範疇に留まらない可能性を感じるようになった。デラングが目指すべきは「理想の標記言語」であって「標記言語の再定義」なのかもしれない。
ティム・バーナーズ=リーは,WorldWideWeb を作り,URL を作り,HTML を作った。私は,デルンを作り,知番を作り,デラングを作っている。
デラングが発展するにつれ,Markdown が最高の“踏み台”になるという確信も深まる一方だ。やり甲斐に不足はない。

{希哲16年2月13日9歩 K#F85E/A-E74C-0502}
1月19日1歩で考えた URL の省略記法だが,これは [https://example.com/abc ... xyz]
という形式で導入することにした。これなら無理なく直感的だろう。
前々から考えていたリンクカードは,とりあえず,単独行に [https://example.com]
での導入を考える。長い URL の場合に,[] https://example.com
という代替記法があってもいいかと思っていたが,これはチェックボックス記法と紛らわしいため没とする。いずれにせよ,これ以上分かりやすい記法もないだろう。
行内で [https://example.com]
を使った場合には題名を自動取得するなどの機能があってもいい。

{希哲16年1月31日14歩 K#F85E/A-E74C-B7D8}
前歩についてまとめながら,角括弧と知番による輪結の可能性に気付いたため急遽まとめて終了。
多重輪括弧が閲覧専用模動で後景一覧・輪郭ページへの輪結として機能するなら,その逆に閲覧専用模動への輪結手段があってもいい。いま角括弧と URL の組み合わせ([アンカー https://example.com]
)に対応している輪結記法を [アンカー K#XXXX/XXXX]
の形で使えるようにするのが自然だろう。
更に,これは閲覧専用模動では同模動で普通の輪結になるのが自然なので,前歩で書いた「閲覧専用模動で強調も輪括弧の表示もせずに輪符を輪結化したいという場合」にも上手く対応出来る。
ここまでで若干もやもやしていた閲覧専用模動周りの仕様が大分くっきりしてきた。

{希哲16年1月19日1歩 K#F85E/A-E74C-5396}
直書き URL(<a.URI>
)を font-size: 0.9em
の等幅フォントにした(URL 装体調整前後)。字間無しは昨年6月30日の開発からだが維持する。
直書き URL のある描写が読みにくい問題はずっと以前から感じていて,何度か調整しているが,一昨日の開発中にふと,「文字サイズを小さくしていない」ことに気付いた。
昨年6月30日の開発で字間無しにしているが,等幅フォントにして変に目立ち過ぎるという理由で戻したりもしている。この時になぜ文字サイズを小さくするという発想がなかったのか不思議だ。他にも問題が山積していて思考時間が割けず,灯台の下まで目が行かなかったか。
今回は <kbd>
や <code>
の装体について考えていたところだったので,その関連で気付けたのだろう。
文字サイズはやはり0.9emが丁度良い。0.8emにすると長い URL はともかく短い URL を提示する時に今度は目立たな過ぎる。
これにより,十分凝縮されメリハリが付いたので,予てから検討していた長い URL の省略については保留とすることにした。
長い URL の省略は,簡単なようでいざ導入しようとすると意外と難しい問題がある。
まず,デライト上の文書の傾向からいっても,「ちょっと長い」程度の URL は省略したくない。URL の全体が情報として有用な場合がしばしばある。このあたりはマイクロブログなどとは事情が異なる。
では,どこで省略すべきかという問題になるが,長い URL を許容すればするほど比較的短い URL の読みにくさが解消されないというジレンマがあった。これは装体の調整で解決した。
そもそも輪結記法([ ... ]
)もあるので,現状維持で特に困ることはないだろう。そのうち https://example.com/abc ... xyx
のような省略記法を導入してもいい。
ただ,パーセント符号化の復号はしたい。これは昨年3月22日2歩で決めていたことだが,少し面倒臭い部分がありいまだに実現していない。
