orange @[email protected]

よくわかんないけど、場所を示す文字列がどういうフォーマットであろうが、その文字列の中に意図の情報が含まれていないと、場所(URLならばリンク先)が変化してしまうと意図の解釈がおかしくなるって話だと思うんだけど＞＜

つまり「セクションが一方的に “記事” に従属しているように見えてしまうが、そもそもセクション自体が単体で記事レベルのアイテムとして成立しうるし、それが単にリンクされ埋め込み表示されていると捉えるべきではないか？ (そして大抵のアプリはそういうモデリングをできていない)」というのと、「アイテムがひとつの親アイテムの下にあるという木構造はそもそも情報の関係性のモデリングとしてあまりに貧弱すぎるし、それがサブアイテムの切り出しや整理を阻害しているのではないか？」という感じで世界を見ています

「おいしい食事」記事の中に「おこめ」があるかもしれないが、それが埋め込まれて見えているのは本質的な性質ではなく、「おいしい食事としてのおこめ」という情報が「おいしい食事」情報 “でもある” という関係を埋め込みで表現した、ということだと思うのよね。
で、「おいしい食事としてのおこめ」は同時に「おこめ」情報 “でもある” し、また「生活の買い物」情報 “でもある” かもしれないし、さらには「俺のお気に入り」情報 “でもある” かもしれない。
ほらもう木構造では厳しくなってきた

これは私はちょっとだけ違う捉え方をしていて、「セクションと記事の区切りはどこにある」というのと「情報のまとまりの『親』が単一であることを URL や木構造ナビゲーションは要求するが、本来は情報の関係性ってグラフだよね」というのがある

つまり既存の URL 意味論との互換性云々を無視したとしても、混ぜ込むのは健全な設計であるとは思わないし可能な限り避けるべきバッドプラクティスだと思う

もし新規設計するなら「人間フレンドリーな文字列 + 純粋な識別子」というデータ構造を用意するだろうし、「識別子中に人間用非規範データを混ぜ込む」という手はやっぱり取らないと思う

URL (というよりか URI) が **HTTP/S においては** ID ばかりでなくルーティング情報としても機能しているから「ルート中に無意味な部分があってもナビゲーションに使われなければ問題ない」という発想になってしまうのかもしれないが、 URI 一般にそれを期待すべきでないし、 HTTP でのみ URI 標準から異様に乖離した非ID文字列としてのエセ URI を使ってほしいとも思わない

勝手に改変される identifier、これほど信用できないものもない

それはむしろ「別の用途で使われているかもしれない構造を外部で第三者が勝手に『問題ないだろ』として改変する」ことを推奨しているわけで、 ID どころの騒ぎではないのでは……？

実際、ロケーションバーから URL を全コピーして他所で貼り付けるというのはあまり良い体験ではない。たまに失敗して日本語部分が URL encode されてない人とかいるし。ボタンﾎﾟﾁｰとかで実現されるべきよね

「PC でも Android 等の共有機能みたいにタイトルをペアにする方式を標準で提供しろ」という方向に行くのが一番健全な気がしますね。 ID の構造や意味を弄るよりは。

うーん……
コメントならそれこそ ID と別に並べて書いてしまえばいいわけで、やっぱり「ブラウザなり何なりが標準でタイトルも付加する」形式の方がストレートに見えるなぁ。
Android の共有機能とかは実際にタイトルと URL の組を受け渡しすることを標準的な手法として実現しているわけで

それって一般的な web サーバの機能として持つべきか……？
そもそも「タイトル」と言ってもタイトルバーに出る文字列と記事そのもののタイトルは違ったりするし、さらに content negotiation によってクライアントごとに言語や表示フォーマットが異なる可能性があるし、そういう諸々の複雑な “人間向け” 要件を ID 内に取り込むのはだいぶ余計な複雑さの導入に見えるけど