アカウント名:
パスワード:
タグを閉じないで利用する輩が、周りに多すぎるので。 そんないい加減な書き方でも表現できたからこそ， 広まったようにも思います． >
タグを閉じないで利用する輩が、周りに多すぎるので。 私もＰタグにかかわらず，いい加減なHTML文書書かれるのを見ると イラっときます．
＞そんないい加減な書き方でも表現できたからこそ，広まったようにも思います
よく見るこの意見については以前から違和感があるんだが。
XMLの様に、ルールは簡単な方が学習コストは低いのではないか？「＜ｐ＞だろうがなんだろうが、全部閉じる」とした方が変に「あれはダメ、これはOK」と覚えるより楽チンだろう。
タイピングの心理的な手間と秤にかけてってことではないかなと。昔は手打ちが標準だったので。
コンピュータ（というか解釈ルール）的には開始記号-終了記号の対が厳密かつ簡潔で扱いやすいのでしょうが、人間にとっては開始記号だけの方が書きやすいということではなかろうかなと。
開始記号-終了記号の対が扱いやすいかどうかは文生成と文解釈で異なるんじゃないかなとも思う。そしてタグに限らず人間は開始記号-終了記号の対を書き出すのが苦手な生き物なんじゃないかと。例えば大抵の構文を意識したエディタではかっこ閉じ補完してくれるあたり、人間は閉じかっこを覚えているのが苦手なことの表れかなとも。（あるいは行指向言語やインデントでブロックを認識するプログラミング言語が思い出したように現れるあたりとかも。）思うに、ヒトのココロにはスタック的構造がなくてそれを模倣するには追加の脳内努力が必要なんじゃないかなーと。
主観的感想を言えば、厳密な構文解析が楽なことが分かっていてもXMLで要素の終了タグは打つのが面倒臭いｗ特にHTMLのテーブルみたいに何層も入れ子になっている時は特に面倒。
いやまぁ、XMLはHTMLの親戚として手打ちしたら面倒だという例に挙げただけで今なら長い文書は可能な場合はツールを使ってます。（昔はAltovaのツールに投資したけど更新費用が高くてお小遣い枠では維持できなくなったので近頃はEclipseのプラグインです。）
ただ元コンテキストはHTMLができた頃の話のHTMLの終了タグの話で、当然その頃はそんなにツールが普及しておらず（というか存在すら怪しかった）手打ちが普通でしたので。（そもそも一般のユーザにとってはマークアップ文書という概念ですらまだいくらか目新しさがあった筈。私も初めて見たときはマークアップ文書というカ
マークアップといえば、HTML(やXML)のタグの、入れ子しか許さないというあの仕様にも、ウンザリしています。本当にマークアップだというなら、入れ子以外の構造も許さなきゃ。
あいうえお
という文字列に対して「あ…うを黄色に」「い…えを下線ひいて」という要求に(同時に)答えるために、
＜yellow＞あ＜underline＞いう＜／yellow＞え＜／underline＞お
と書ければいいのに、HTML(XML)はそれを許さない。それ、マークアップ言語の責務として、なんかおかしくない？
あとついでにいえば、XMLとかで入れ子構造を強制したせいで「XMLは入れ子構造を表現するためのメタデータ形式だ」と誤解してか、XMLを入れ子データ設定ファイルに使ってしまう阿呆が後を絶たないのも、困ったもの。入れ子が好きならJSONかYAMLあたりにしとけです。あれなら入れ子しか書けないし「地の文」も無いからツリーをすっきり書ける／パースできる。
>開始タグ-終了タグの対は人間にとっても読みにくくはないと思います。
冗長でウザイと思う。逆にいえばJSONやS式(Lispの)だって「括弧の対応が表示されるエディタ」のようなツールで見れば問題なく読めるわけだし。
＃「文字化けに強いだろ」というわけのワカラナイ屁理屈をいう奴がHTML登場当時にゃ結構いたっけな。おまえらTCPくらい使えよ…と思ったもんだった。それに連続で数文字が欠けたらHTMLタグだってイチコロなんだし。
> ＜yellow＞あ＜underline＞いう＜／yellow＞え＜／underline＞お
括弧の開きと閉じがオーバーラップしてたら気持ち悪くないですかね。
(1 + 2 * {3 + ) 4}
「本日は『晴天」なり』
そういう感覚があるからHTMLも要素がオーバーラップしないつくりになっているんだと思います。
# とか言いつつSGMLならCONCUR YESにすれば似たようなことができますが。
入れ子でないオーバーラップを許すとスタックでは処理できなくなる（プッシュダウン・オートマトンで受理できなくなる）ということで解析する際の複雑さが上がります。比較的簡単なスタックですら人間の脳にとっては人工的な努力が必要なのだとするとそれ以上でしょう。そこいらへんが「気持ち悪い」の理由じゃないかと。
ツリー構造との対応も不可能ではないにせよ簡単ではなくなります。
入れ子構造がよく用いられるのはツリー構造との対応関係もあるのではないかと思います。
人間の記憶と思考の基礎構造は神経ネットワークに支えられたグラフ的構造（リソースの制約があるだろうから任意の 2 頂点間にエッジがある完全グラフってことはないだろうけど、グラフの構造の制約が現時点では明らかでないので一般のグラフを仮定）ではないかと推測され、そこからアウトプットとして何らかの表現に書き出すときには脳内のグラフ構造を部分的に書き出さないといけない（脳内を全部ダンプするわけにはいかない）だろうと思います。
一般のグラフから部分グラフ取り出すとき、ツリーはあるノードをルートとして選んでそこから重複しないように辿れば比較的簡単に取り出せます。そしてツリーは必ず平面上に表現できる（平面グラフ）うえ、一次元構造しかない文字列を使う場合にも入れ子構造を導入することであいまいさなく表現できます。あいまいさがなければ解釈する（入れ子構造からツリーを再構築する）際のコストが低くなるでしょう。
もちろん一般のグラフから目的に応じて｛バランスの良い|判りやすい}ツリーを切り出すことには余計な努力が必要（複数のノードに繋がるノードをどこへぶら下げるのがいいか？）ですし、それを入れ子構造に変換することにはさらに余計な努力が必要（閉じカッコや閉じタグを忘れないこととか）ですが、脳内にあると思われる知識のグラフの構造を部分的にせよ表現するには悪くない方法かも知れないと思うのです。
もちろんDAGとか色々他にも性質の良いグラフはあるでしょうし、グラフを文書の文字列にコード化する方法もいろいろあるでしょうが、ツリー-入れ子構造は書き出すにも読み取るにも計算量的に色々お手軽なのでよく使われるのかなと。
このようなことは構造を持たない文書には関係ないですが、知識構造の表現能力の向上を目指して文書に人工的な構造を導入しようとした時比較的導入しやすいのがツリーであり、ツリーを素直に表現できるのが入れ子なのではないかと。
ところで、こういう入れ子（＝ツリー構造）は文書では割と多用される一方、会話ではあまり使えない気がします。
というかそもそも会話は脱線すると元には戻れないことが多い。
このあたりも人間の脳が作り出す「意識」はネットワークの上を連想によって辿るように働いていて、他のノードに移ったら移ったきりであり、元に戻るためのスタック的な仕組みをサポートしていないということかなと思っています。
このため入れ子などの構造は会話のようなリアルタイム処理が必要な局面では使えないということなのではないかと憶測。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
違和感・・・？ (スコア:1)
HTTPは単純なプロトコルだから、広まったんだと思いますよ。ただ、HTMLの構造はもう少しきつくてもよかったんじゃ・・・<p>タグを閉じないで利用する輩が、周りに多すぎるので。
-- gonta --
"May Macintosh be with you"
Re: (スコア:1)
タグを閉じないで利用する輩が、周りに多すぎるので。 そんないい加減な書き方でも表現できたからこそ， 広まったようにも思います． >
タグを閉じないで利用する輩が、周りに多すぎるので。 私もＰタグにかかわらず，いい加減なHTML文書書かれるのを見ると イラっときます．
Re: (スコア:0)
＞そんないい加減な書き方でも表現できたからこそ，広まったようにも思います
よく見るこの意見については以前から違和感があるんだが。
XMLの様に、ルールは簡単な方が学習コストは低いのではないか？「＜ｐ＞だろうがなんだろうが、全部閉じる」とした方が変に「あれはダメ、これはOK」と覚えるより楽チンだろう。
Re: (スコア:2, 興味深い)
タイピングの心理的な手間と秤にかけてってことではないかなと。
昔は手打ちが標準だったので。
コンピュータ（というか解釈ルール）的には開始記号-終了記号の対が厳密かつ簡潔で扱いやすいのでしょうが、
人間にとっては開始記号だけの方が書きやすいということではなかろうかなと。
開始記号-終了記号の対が扱いやすいかどうかは文生成と文解釈で異なるんじゃないかなとも思う。
そしてタグに限らず人間は開始記号-終了記号の対を書き出すのが苦手な生き物なんじゃないかと。
例えば大抵の構文を意識したエディタではかっこ閉じ補完してくれるあたり、人間は閉じかっこを覚えているのが苦手なことの表れかなとも。
（あるいは行指向言語やインデントでブロックを認識するプログラミング言語が思い出したように現れるあたりとかも。）
思うに、ヒトのココロにはスタック的構造がなくてそれを模倣するには追加の脳内努力が必要なんじゃないかなーと。
Re: (スコア:1)
主観的感想を言えば、厳密な構文解析が楽なことが分かっていても
XMLで要素の終了タグは打つのが面倒臭いｗ
特にHTMLのテーブルみたいに何層も入れ子になっている時は特に面倒。
Re: (スコア:0)
終了タグを補完してくれるツールを使えば良いのではないか？
そもそもXMLは、人間の可読性よりもマシンリーダビリティを重視してる。
面倒と言いながら手打ちするのは合理的判断とは思えない。
# 面倒と思わないので手打ちする事が多いけど、
Re: (スコア:1)
いやまぁ、XMLはHTMLの親戚として手打ちしたら面倒だという例に挙げただけで今なら長い文書は可能な場合はツールを使ってます。
（昔はAltovaのツールに投資したけど更新費用が高くてお小遣い枠では維持できなくなったので近頃はEclipseのプラグインです。）
ただ元コンテキストはHTMLができた頃の話のHTMLの終了タグの話で、当然その頃はそんなにツールが普及しておらず（というか存在すら怪しかった）手打ちが普通でしたので。
（そもそも一般のユーザにとってはマークアップ文書という概念ですらまだいくらか目新しさがあった筈。私も初めて見たときはマークアップ文書というカ
Re:違和感・・・？ (スコア:0)
マークアップといえば、HTML(やXML)のタグの、入れ子しか許さないというあの仕様にも、ウンザリしています。
本当にマークアップだというなら、入れ子以外の構造も許さなきゃ。
あいうえお
という文字列に対して「あ…うを黄色に」「い…えを下線ひいて」という要求に(同時に)答えるために、
＜yellow＞あ＜underline＞いう＜／yellow＞え＜／underline＞お
と書ければいいのに、HTML(XML)はそれを許さない。
それ、マークアップ言語の責務として、なんかおかしくない？
あとついでにいえば、
XMLとかで入れ子構造を強制したせいで「XMLは入れ子構造を表現するためのメタデータ形式だ」と誤解してか、
XMLを入れ子データ設定ファイルに使ってしまう阿呆が後を絶たないのも、困ったもの。
入れ子が好きならJSONかYAMLあたりにしとけです。
あれなら入れ子しか書けないし「地の文」も無いからツリーをすっきり書ける／パースできる。
>開始タグ-終了タグの対は人間にとっても読みにくくはないと思います。
冗長でウザイと思う。
逆にいえばJSONやS式(Lispの)だって「括弧の対応が表示されるエディタ」のようなツールで見れば問題なく読めるわけだし。
＃「文字化けに強いだろ」というわけのワカラナイ屁理屈をいう奴がHTML登場当時にゃ結構いたっけな。おまえらTCPくらい使えよ…と思ったもんだった。それに連続で数文字が欠けたらHTMLタグだってイチコロなんだし。
Re:違和感・・・？ (スコア:2)
> ＜yellow＞あ＜underline＞いう＜／yellow＞え＜／underline＞お
括弧の開きと閉じがオーバーラップしてたら気持ち悪くないですかね。
(1 + 2 * {3 + ) 4}
「本日は『晴天」なり』
そういう感覚があるからHTMLも要素がオーバーラップしないつくりになっているんだと思います。
# とか言いつつSGMLならCONCUR YESにすれば似たようなことができますが。
Re:違和感・・・？ (スコア:2, 参考になる)
入れ子でないオーバーラップを許すとスタックでは処理できなくなる（プッシュダウン・オートマトンで受理できなくなる）ということで解析する際の複雑さが上がります。
比較的簡単なスタックですら人間の脳にとっては人工的な努力が必要なのだとするとそれ以上でしょう。そこいらへんが「気持ち悪い」の理由じゃないかと。
ツリー構造との対応も不可能ではないにせよ簡単ではなくなります。
Re:違和感・・・？ (スコア:1)
入れ子構造がよく用いられるのはツリー構造との対応関係もあるのではないかと思います。
人間の記憶と思考の基礎構造は神経ネットワークに支えられたグラフ的構造（リソースの制約があるだろうから任意の 2 頂点間にエッジがある完全グラフってことはないだろうけど、グラフの構造の制約が現時点では明らかでないので一般のグラフを仮定）ではないかと推測され、
そこからアウトプットとして何らかの表現に書き出すときには脳内のグラフ構造を部分的に書き出さないといけない（脳内を全部ダンプするわけにはいかない）だろうと思います。
一般のグラフから部分グラフ取り出すとき、ツリーはあるノードをルートとして選んでそこから重複しないように辿れば比較的簡単に取り出せます。そしてツリーは必ず平面上に表現できる（平面グラフ）うえ、一次元構造しかない文字列を使う場合にも入れ子構造を導入することであいまいさなく表現できます。あいまいさがなければ解釈する（入れ子構造からツリーを再構築する）際のコストが低くなるでしょう。
もちろん一般のグラフから目的に応じて｛バランスの良い|判りやすい}ツリーを切り出すことには余計な努力が必要（複数のノードに繋がるノードをどこへぶら下げるのがいいか？）ですし、それを入れ子構造に変換することにはさらに余計な努力が必要（閉じカッコや閉じタグを忘れないこととか）ですが、脳内にあると思われる知識のグラフの構造を部分的にせよ表現するには悪くない方法かも知れないと思うのです。
もちろんDAGとか色々他にも性質の良いグラフはあるでしょうし、グラフを文書の文字列にコード化する方法もいろいろあるでしょうが、ツリー-入れ子構造は書き出すにも読み取るにも計算量的に色々お手軽なのでよく使われるのかなと。
このようなことは構造を持たない文書には関係ないですが、知識構造の表現能力の向上を目指して文書に人工的な構造を導入しようとした時比較的導入しやすいのがツリーであり、ツリーを素直に表現できるのが入れ子なのではないかと。
Re:違和感・・・？ (スコア:1)
ところで、こういう入れ子（＝ツリー構造）は文書では割と多用される一方、会話ではあまり使えない気がします。
というかそもそも会話は脱線すると元には戻れないことが多い。
このあたりも人間の脳が作り出す「意識」はネットワークの上を連想によって辿るように働いていて、他のノードに移ったら移ったきりであり、元に戻るためのスタック的な仕組みをサポートしていないということかなと思っています。
このため入れ子などの構造は会話のようなリアルタイム処理が必要な局面では使えないということなのではないかと憶測。