アカウント名:
パスワード:
なんだかんだ言って、初めてスクリーンエディタができた頃からごく最近まで、 アルファベットと数字だけ使えればよかった時代は幸運だったし幸福だったと 思う。全ての文字が同じ大きさだったおかげで、印字内容とレイアウトという 異なる概念がでそのまんま具現できたから。そのおかげでテキストエディタっ てのは最初の時代から今まで使えるずっと便利なWYSWYG環境だったわけで。
しかし、世界は広くてキャラクタベースではどうにも表示できない 文字もある。既にマシン性能の方はピクセルベースでも十分なんだけど、かと いって文字を表示するのに「えっと、この文字はこのエンコーディングで、このフォ ントを使っていてるから、このウィンドウシステムだと横148 ピクセル食うか ら、次の項目までは152ピクセル進めて…」なんていちいちやりたくない。 「あ~あ、スペースで位置合わせていた頃は幸せだったな~」と。
さすがに、ピクセル数えて…なんてことする必要はほとんど無いし、XMLを使って 記述量を絞ったままそれなりにレンダリングさせるのでいいんだけど、でも、 最初に挙げたように、XMLですら手書きはしたくないんですよ。テキストエディ タでスペースバーを叩いてレイアウト決めてたのに比べればどれだけ大変か。
で、ここでやっと本題なんですが、実は可変ピクセル文字環境でも、 TSV (tab-separated values)のようにタブで項目を区切ってやって、cursesみたいな感じ(エスケープシーケンスみたいなもっと低レベルなものでいいかも)で自動的なテキストレイアウタを作って統一してやれば、古式ゆかしい「スペース文字でレイ アウト」という流儀にちょっと毛が生えたぐらいの手間で同じぐらいの気軽さ で世界中うまく行くんじゃないかなあ。
…と、最近のEmacsでプロポーショナルフォントを使ってソースを書いてて思ったのでした。結構気持ちいいですよ。
でも、「レイアウトなんて情報交換には無駄無駄。押し着せのレイアウトで十分」というふうには、割り切れんもんなのでしょうか?
しかし、分離したときに、人間の自然な表現に含まれていたはずのレイアウトはどこに行くのでしょう? その情報は落とされて無視されるか、人力でタグ付けなどのエンコーディングを行うか、という理不尽な扱いを受けることになります。それは対人間インタフェースとして望ましいものではありません。
人間の意図をきちんと汲み取ってくれるようなインテリジェントなインタフェースがそのうちできればいいのでしょうが、でも現状あるシンプルな技術だけでもそれなりの実現がありそう、という話です。
machine-machine interfaceはどんな形式でも構いません。統一されるのはよ いことなのでXMLでOKです。
しかし、私は最初から今までhuman-machine interfaceの話をしています。 human-machine interfaceはend pointなので、どんな形式に変換してもよいし、 その際には人間のニーズにとって、より直感的で便利な形式を採るのがよいで しょう。
具体的な例として挙げて来たのが、ターミナルエミュレータ(たとえば今回の mlterm)に表示される情報をCやPerlの中に埋め込む時に、よいインタフェース は何か? ということです。プログラムのソースもhuman-machine interfaceの一つ ですよね。
文書はどこまでオリジナルに忠実であるべきだと思いますか? 内容が伝わる フォントの種別、サイズ 図表の位置 改ページ位置 改行位置 欧文のハイフネーション形式
#結局は、スタイルシートは面倒だという話?それはそれで、納得できる意見です。
別の例では、イラストを描きたいと思ったら、ドローイングソフトを持ってき て、マウスやタブレットで入力するわけです。そのソフトの内部でSVGを使ってい ようとUIには関係ないです。
ただ、タブ区切り方式で綺麗に並ぶのは、表とかプログラムテキストだけです よね。しかも、エスケープシーケンスやcursesを仮定すると、パイプでつない で後処理というのはXML以上に面倒になりそうな気がします。このあたりは、 どうお考えですか?
XMLの使用をユーザに意識させるのは良いインタフェースでは無い、というの はよろしいでしょうか?
その上で、実装の簡便さの利得が、ユーザが受ける苦労の程度を上回るならば ユーザにXMLの使用を意識させるのも妥当だと思いますよ。
それを前提に「表現の余地」を残すのであれば、XMLの枠組みではスタイルシー トを記述するようになるのですが、これは許容範囲なのかなぁと聞いてみたわ けです。
ということで、もし「スタイルシートいらない」&「標準のタグセットがあればいい」であれば、私が考えている「可能な限りの表現の自由」を求めているわけではないので、対立しているように見えた話題には決着がつきます。 他には、特にnasbさんと対立しているという意識は無いのですが、こんな話題ならまだ続けたいような気も。
このあたりが、立場の違いの一つですね。エンドユーザ向けかと言われれば、 「もちろん違います」とこたえるのですが。
したがって、nasbさんがXMLを「人間と機械のインタフェースではない」と判 断させた理由にはちょっと興味があります。
その観点でいうと、たとえば「XHTMLを直書きさせる」というのは、XHTMLとい う「機械と機械」のインタフェースをほぼそのまま「人間と機械」に写像した、 と言えます。適当な入力支援を使う場合も同様に、それはXHTMLを若干加工を 加えて新たなユーザインタフェースの一つに写像したものです。
さて、Jadawinさんは
レイアウトは不要。「人間と機械」の間は直書き、またはな んらかの入力支援を用い、「機械と機械」の間はXHTMLのようなレイアウトを 含まないXMLの実装を用いる。
レイアウト表現は落とさない。「人間と機械」の間はTSV(のよ うなもの)、「機械と機械」の間はとくに拘らない。 (当然、XMLを使うならレイアウトを含むXMLの実装になるだろう。)
ということで、もし「スタイルシートいらない」&「標準のタグセットがあれ ばいい」であれば、私が考えている「可能な限りの表現の自由」を求めている わけではないので、対立しているように見えた話題には決着がつきます。
1. タブ区切りだとどの程度までできるんだろう?
# カラムを揃えるポリシやそのアルゴリズムを考えるのは楽しそうですが。
うーん。もうちょっと感が。
はるかに遠ざかってしまった気がします。(;_;)
私の考えは、ユーザによって(nasbさん言うところの)「目的や環境」が異なり、 本当にそれぞれの利便を追求すると一つのインタフェースになるとは思いにく いってやつです。
私の考えは、ユーザによって「目的や環境」が異なるので、それぞれに応じて 適切なインタフェースを選べばよい、です。で、両者に違いがあるのですか?
これは論理的には間違っていませんが、ちょっと抽象論に寄りすぎて、現実に は違うものを無理に一緒にしている感があります。同じ論理を展開すると、ユー ザがキーボードを叩いて、文章を入力できるという意味では、ユーザインタ フェースとして、かな漢字変換がT-コードやJIS16進入力と同じだと主張でき てしまいます。ユーザインタフェースを語る文脈では、あまりにも乱暴な論理 展開ではないでしょうか?
誤解しています。「人間と機械」のインタフェース(またはユーザインタフェー ス)というレイヤの話をしているのです。単一のインタフェースの話している のではありません。
例示も、「機械と機械」のインタフェースというレイヤのものを、「人間と機 械」のインタフェースというレイヤに持ってくるときに、写像の方法が何通り もあるよ、という話です。
>レイアウトは不要。「人間と機械」の間は直書き、またはな んらかの入力支援を用い、 >「機械と機械」の間はXHTMLのようなレイアウトを 含まないXMLの実装を用いる。 これは明らかに私の主張を誤解されています。レイアウトを不要という人間が、 自らスタイルシートの話題を出したりはしません。
>レイアウトは不要。「人間と機械」の間は直書き、またはな んらかの入力支援を用い、 >「機械と機械」の間はXHTMLのようなレイアウトを 含まないXMLの実装を用いる。
これは明らかに私の主張を誤解されています。レイアウトを不要という人間が、 自らスタイルシートの話題を出したりはしません。
誤解とは思えません。ここでは(これまでも)ユーザインタフェースの話をして います。ユーザインタフェースがレイアウトを機械に伝達するかどうか?の話 です。レイアウト情報を用いないXMLの実装を用いて「スタイルシートに任せ る」と言った時点で、ユーザの表現したレイアウト情報が落ちるんです。
後で出た「拘りたいならスタイルシートを別に書き起こせばいい」という話は 別の話です。それは、そもそも、「レイアウト情報を含むXML実装」と(「機械 と機械」の)インタフェース的に等価です。そして、私の言っていることに包 含されます。
スタイルシートを利用するとHTMLと同程度にサボりたい人はサボれるし、いじ りたい人にはいくらでもいじれるようになります。
スタイルシート(どのスタイルシートを指しているのかは知りませんが)のよう にレイアウトを表現する能力を持ったインタフェースが、レイアウトを伝達す る目的に使えるのは言うまでも無く自明ですが。
こちらの立場は対立というよりは、「nasbさんがXMLをけぎらいしているらし いのをなんとか変えたい」に変わってます。
私はXMLは嫌いでもなんでもなくて、XMLとは関係ない話に関して「XMLは関係 無い」と言っているだけなのですが、その点が伝わるとこの長話も終わるのか なあ、という気がしてきました。
ただ、TSVの方式は明らかにベストではありません。複雑な文字の組合せのあ るタイ語やアラビア語では比較的すぐに限界にぶちあたるだろうと思います。 #それらを考えないなら、今まで通りでよい分けですし。
ただ、TSVの方式は明らかにベストではありません。複雑な文字の組合せのあ るタイ語やアラビア語では比較的すぐに限界にぶちあたるだろうと思います。
#それらを考えないなら、今まで通りでよい分けですし。
複雑な組み合わせが起こる文字種でも、そんなに簡単に限界に到達する気はし ません。そもそもの発端が「それらのことを考えましょ」という話ですし。
ですから、もし本当にすべての言語をサポートするつもりなのであれば、一見 は手間がかかるだけのように見えても、XML+スタイルシートの形式が最終的に は一番の近道ではなかろうかと思っているわけです。
「機械と機械」のインタフェースにそれを用いるのには反対はしませんけれど (というか、そこは話の本質でないのでどうでもいい)、その先の「人間と 機械」のインタフェースには何を選んでもいいでしょう。 それこそ、「ユーザによって『目的や環境』が異なるので、それぞれに応じて適 切なユーザインタフェースを選べばよい」です。
#単にnasbさんは物事を簡単にとらえたいから、細部を省いた言明を好み、 #私は複雑なものは複雑なままとらえるのを好むんで、徹底的に条件をつける、 #という違いに思えてきました。まぁ、それでも分からん所もあるんですが。 下層がどのような機能を持つかを気にしないでよいのは、アプリケーションのレベルから見て下層が100%等価なものの場合だけです。 #出力ファイルを保存するディレクトリを変えたところで、操作には影響しません。 前にnasbさんが上げたグラフィックツールの保存形式の例だって、JPEGを選択すると圧縮率がどうだとか、別途設定ダイアログがありますよね?すべてが全く同じユーザインタフェースにはなりませんよね?これは、下層の機能によってユーザインタフェースが変わる例ではありませんか? >レイアウト情報を用いないXMLの実装を用いて「スタイルシートに任せ る」と言った時点で、 >ユーザの表現したレイアウト情報が落ちるんです。 あのー、すんません。このあたりは、徹底的に理解できんです。 既存のスタイルシートに任せるかどうかは、ユーザが選択するのではないですか?ユーザが選択する以上は、それがユーザの意図したレイアウト情報になるはずですが。そうで無ければ、そのユーザは何らかの方法でスタイルシートを書けばよいのではないですか?なぜスタイルシートを書くことが、ユーザインタフェースの一部にはなりえないんですか? それに、スタイルシートを使えば落ちてしまうようなレイアウト情報って何があるのでしょう?テキストの中に含めた空白の数とかを問題にしたいのでしょうか?今話している文脈では、カラム幅は不定という前提がありますから、空白は入っているか否かしか問題にはできないはずで、レイアウト情報を持っているとは言えませんが。 また、私はスタイルシートを用いるとは言っていますが、XMLの入力と同様に入力補助手段を用意するのでしょうから、その場合ユーザインタフェースの上からはシームレスに見えるでしょう。 #おお。そうか、これを指してnasbさんは「レイアウト情報を含むXML実装」と呼びたいのですね。 #でも、この言葉ではHTML4.0をそのままXML化したようなものを思い浮かべてしまいます。 #nasbさんの言いたいことであれば、もっと抽象的な言い方をすべきだったのではないでしょうか? #実装なんて言葉が出ると、私なんかものすごく具体的な事柄を期待してしまうのですが。 #また、そのように理解した上でもスタイルシートに関しておっしゃることは理解できないままです。 >複雑な組み合わせが起こる文字種でも、そんなに簡単に限界に到達する気はし >ません。そもそもの発端が「それらのことを考えましょ」という話ですし。 本当ですか?少なくとも、漢字の各パーツ(へんやつくりより小さいレベルのもの)を組み合わせて、任意の漢字をつくり出すのと同程度に大変なものになるはずです。そりゃ不可能では無いにしろ、最初に言っていたタブで区切る程度の簡単な形式とはかけ離れたものになりませんか?共通点は、タブで区切られているというだけで、グループ化を可能とする記号列とか、ネストを可能にする記号列とか、特定の部分の参照の方式とかを追加していくのですよね。
既存のスタイルシートに任せるかどうかは、ユーザが選択するのではないですか?ユーザが選択する以上は、それがユーザの意図したレイアウト情報になるはずですが。そうで無ければ、そのユーザは何らかの方法でスタイルシートを書けばよいのではないですか?
なぜスタイルシートを書くことが、ユーザインタフェースの一部にはなりえな いんですか?
#おお。そうか、これを指してnasbさんは「レイアウト情報を含むXML実装」と呼びたいのですね。 #でも、この言葉ではHTML4.0をそのままXML化したようなものを思い浮かべてしまいます。 #nasbさんの言いたいことであれば、もっと抽象的な言い方をすべきだったのではないでしょうか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
ところで (スコア:1, 興味深い)
文字ピッチの問題をどうやって解決すればいいんでしょうか。
たとえば、英語端末では歴史的に固定ピッチフォントでないと困りますし、
日本語端末だと歴史的に漢字は ANK の倍の幅をもってないといろいろ困ったことになったりしますけど、
エスニックな文字ではその辺はどうなってるんでしょう?
前から多言語な端末作
Re: ところで (スコア:1)
> 英語端末では歴史的に固定ピッチフォントでないと困りますし、
しばらく9termを使った経験からいうと、端末がプロポーショナルフォントでもあんまり困らないと思います。困るのはせいぜい、アスキーアートを見る時くらいじゃないでしょうか。
Re: ところで (スコア:1)
Re: ところで (スコア:1)
# で、タブの定義は? :-)
Re: ところで (スコア:1)
繁雑にはなるけど、パーズは楽になる、、、はず、、。
#XMLの適用って、どんなデータまで妥当?
Re: ところで (スコア:1)
Re: ところで (スコア:1)
もしかして、端末がウェブを覗いて、直接flashやmp3を再生したりするんだろうか?
さらのその拡張でSVGtermとかもあったりするんだろうか?SMILtermなんてのもできるんだろうなぁ
#世の中、恐いのぉ。わし、もう爺や。
スペースの次はタブ (スコア:1)
なんだかんだ言って、初めてスクリーンエディタができた頃からごく最近まで、 アルファベットと数字だけ使えればよかった時代は幸運だったし幸福だったと 思う。全ての文字が同じ大きさだったおかげで、印字内容とレイアウトという 異なる概念がでそのまんま具現できたから。そのおかげでテキストエディタっ てのは最初の時代から今まで使えるずっと便利なWYSWYG環境だったわけで。
しかし、世界は広くてキャラクタベースではどうにも表示できない 文字もある。既にマシン性能の方はピクセルベースでも十分なんだけど、かと いって文字を表示するのに「えっと、この文字はこのエンコーディングで、このフォ ントを使っていてるから、このウィンドウシステムだと横148 ピクセル食うか ら、次の項目までは152ピクセル進めて…」なんていちいちやりたくない。 「あ~あ、スペースで位置合わせていた頃は幸せだったな~」と。
さすがに、ピクセル数えて…なんてことする必要はほとんど無いし、XMLを使って 記述量を絞ったままそれなりにレンダリングさせるのでいいんだけど、でも、 最初に挙げたように、XMLですら手書きはしたくないんですよ。テキストエディ タでスペースバーを叩いてレイアウト決めてたのに比べればどれだけ大変か。
で、ここでやっと本題なんですが、実は可変ピクセル文字環境でも、 TSV (tab-separated values)のようにタブで項目を区切ってやって、cursesみたいな感じ(エスケープシーケンスみたいなもっと低レベルなものでいいかも)で自動的なテキストレイアウタを作って統一してやれば、古式ゆかしい「スペース文字でレイ アウト」という流儀にちょっと毛が生えたぐらいの手間で同じぐらいの気軽さ で世界中うまく行くんじゃないかなあ。
…と、最近のEmacsでプロポーショナルフォントを使ってソースを書いてて思ったのでした。結構気持ちいいですよ。
Re:スペースの次はタブ (スコア:1)
>たとえ ば JavaML [washington.edu] なんてものもあるけど、そのソースを手で
>こう [washington.edu]書くなんて気が狂うでしょ。
それぐらいは、書けんことはないですよぉ。それって、別にテキストじゃなくてプログラムローダーを書いているわけですから。
>テキストエディ タでスペースバーを叩いてレイアウト決めてたのに比べればどれだけ大変か。
それは同意。でも、「レイアウトなんて情報交換には無駄無駄。押し着せのレイアウトで十分」というふうには、割り切れんもんなのでしょうか?こういった所を覗いている人ですら。
#皮肉じゃなく、純粋に疑問っす。
簡単なレイアウタに関して言えば、CGIプログラムがHTMLを吐くためのフレームワークが色々ありますよね?あれと似たような仕組みで、emacsマクロができたら手で入力するんでも不可能ではないかもしれないとか思ったりして。
#「タイトルページ中で、上上下下右左右左ABだ!」
Re:スペースの次はタブ (スコア:1)
しかし、分離したときに、人間の自然な表現に含まれていたはずのレイアウトはどこに行くのでしょう? その情報は落とされて無視されるか、人力でタグ付けなどのエンコーディングを行うか、という理不尽な扱いを受けることになります。それは対人間インタフェースとして望ましいものではありません。
人間の意図をきちんと汲み取ってくれるようなインテリジェントなインタフェースがそのうちできればいいのでしょうが、でも現状あるシンプルな技術だけでもそれなりの実現がありそう、という話です。
Re:スペースの次はタブ (スコア:1)
これ↓以前のところは同意。
>しかし、分離したときに、人間の自然な表現に含まれていたはずのレイアウトは
>どこに行くのでしょう?
さて、このあたりからちょっと立場が違うようです。さっきの乱暴な聞き方じゃなくて、もう少しブレークダウンします。文書はどこまでオリジナルに忠実であるべきだと思いますか?
もしこれらすべてというのであれば、同じレンダリングエンジン、同じフォントフォントセットを要求していることになります。でも、それってどこか一社が独占している状態か、それらが完全にオープンソースで公開されている状態かのどちらかでしか、実現しそうにもないです。細かいところは各社各様で、しかも自社の財産だから妥協しないという状況が続いてるようですから。
個人的には、文書環境において標準化が一番重要なフェーズにいるんじゃないかと考えています。そのような意味から、とりあえずはレイアウトの細かい所は積極的に忘れたいと思っています。
>その情報は落とされて無視されるか、人力でタグ付けなど
>のエンコーディングを行うか、という理不尽な扱いを受けることになります。
>それは対人間インタフェースとして望ましいものではありません。
でも、それはすべて人間の思い通りにさせ、それを人間の手間で実現するからですよね?それだと結局グラフィックツールになってしまうんじゃないでしょうか?
#昔の毛筆手書きを真面目に再現しようとするとそんな話になりますよね。
#漢字と平仮名で、また文頭や名詞などでも文字の大きさは違うでしょう。続け字の話もあります。
でも、そのような文書の表示は携帯電話じゃ、メモリ、画面サイズ、CPUパワーのどれを取って見ても厳しいですよね?しかも、すべての人がそれなりのレイアウトセンスを必要としますよね?いちいちすべてに体裁情報をつけるのは大変ですよね?
そしてその現実的な落とし所が、内容と体裁の分離なのではないでしょうか?スタイルシートをカスタマイズしたり、個別の段落や行に違うスタイルを適用することは(論理的には)可能ですから、そのあたりで手を打ってもらえませんか?このようなことを天秤にかけた結果だと考えれば、100%の自由がないことも理不尽とまでは言えないと思いませんか?
#「半紙に筆でできることが、なんでコンピュータだと難しいんだよ!」と言われたら、
#どうしよう。どんな道具でも自由にならない分特定の能力を拡大できるのだと思うけど。
Re:スペースの次はタブ (スコア:1)
machine-machine interfaceはどんな形式でも構いません。統一されるのはよ いことなのでXMLでOKです。
しかし、私は最初から今までhuman-machine interfaceの話をしています。 human-machine interfaceはend pointなので、どんな形式に変換してもよいし、 その際には人間のニーズにとって、より直感的で便利な形式を採るのがよいで しょう。
具体的な例として挙げて来たのが、ターミナルエミュレータ(たとえば今回の mlterm)に表示される情報をCやPerlの中に埋め込む時に、よいインタフェース は何か? ということです。プログラムのソースもhuman-machine interfaceの一つ ですよね。
私の答えは「ニーズに応じて」です。そこはたぶん一緒の意見だと思うのですが。Re:スペースの次はタブ (スコア:1)
>具体的な例として挙げて来たのが、ターミナルエミュレータ(たとえば今回の mlterm)に
>表示される情報をCやPerlの中に埋め込む時に、よいインタフェース は何か? ということです。
>プログラムのソースもhuman-machine interfaceの一つ ですよね。
それが論点の中心であれば、私の意見は「XML吐くだけならフレームワークというか、ライブラリと言うか、それを補助するものを使えばいいんじゃないかなぁ?」です。でもnasbさんの本論は「そのような所でも表現の余地を残したい」でしたっけ。そうすると、、、やっぱり意味付けに基づいた単純な自動化だけでは無理です。
共通のスタイルシートで80%ぐらいはうまくいくのでしょうから、残りの問題のでる所をそのパラグラフ固有のスタイルシートを用意することである程度解決できそうです。
#結局は、スタイルシートは面倒だという話?それはそれで、納得できる意見です。
ただ、タブ区切り方式で綺麗に並ぶのは、表とかプログラムテキストだけですよね。しかも、エスケープシーケンスやcursesを仮定すると、パイプでつないで後処理というのはXML以上に面倒になりそうな気がします。このあたりは、どうお考えですか?
Re:スペースの次はタブ (スコア:1)
#ストカ臭い?
Re:スペースの次はタブ (スコア:1)
別の例では、イラストを描きたいと思ったら、ドローイングソフトを持ってき て、マウスやタブレットで入力するわけです。そのソフトの内部でSVGを使ってい ようとUIには関係ないです。
面倒だということは、適切なUIでないということなので、UIを変えるだけでしょ う。Re:スペースの次はタブ (スコア:1)
>私は終始「人間と機械の間」のインタフェースの話をしています。
私もそうです。ただ、私の場合はそもそも人間(この場合はnasbさん)の要求がどこにあるかを明らかにしない限りは、インタフェースの設計は無理だと思っています。また、基本にある技術を仮定せずには、何ができるかを判断できません。それで、XMLを仮定してnasbさんの場合だと、どの程度が妥当かを聞いている訳です。要するに、技術で実現できることを念頭において、何ができることを期待するかやどの程度まで労力を払ってもよいかを、nasbさんの一例でよいから知りたいと思った訳です。
さて、最初の話題に立ち返って私の頭の中を整理すると、
#違ってたら言って下さい。
で、すれ違っていると思う理由は、私はこの場合にnasbさんの許容範囲がどこにあるかを聞きたいと思っているのに、nasbさんが一般の話ととらえて、「人によりけり、場合によりけり」と答えているように思えることです。
ここで確認したいのですが、nasbさんはまだこの話題続けたいですか?どうも、問題のとらえ方が私とnasbさんでは違うようなので、このまま話を進めても同じことを違う言い回しでなんども繰り返すはめにおちいりそうです。
見直してみると私の方にも舌足らずなところが、幾つかあります。一番大きいのは、「私はXMLを手で書ける」と言いましたが、「すべてのユーザにXMLを手で書く事を強制したい」と思ってません。だからこそ、直書きではなくて入力支援のフレームワークを使うのだろうと仮定しました。それを前提に「表現の余地」を残すのであれば、XMLの枠組みではスタイルシートを記述するようになるのですが、これは許容範囲なのかなぁと聞いてみたわけです。最初は冗談半分の記事から始まってたので、私の話がわかりにくかったのでしょう。その点はご容赦下さい。
私のまとめが許せん位に違っている場合、まだまだ話を続けたい場合にはこの記事にコメントして下さい。
Re:スペースの次はタブ (スコア:1)
XMLの使用をユーザに意識させるのは良いインタフェースでは無い、というの はよろしいでしょうか?
その上で、実装の簡便さの利得が、ユーザが受ける苦労の程度を上回るならば ユーザにXMLの使用を意識させるのも妥当だと思いますよ。
スタイルシートがなぜ必要なのか判らないのですが、ひょっとしてXHTML(また はレイアウトを仕様に含めないその他のXMLの実装)を仮定していたのでしょう か?Re:スペースの次はタブ (スコア:1)
> 「人間と機械の間」のインタフェースの話に、基本技術として
>XMLが出てくる のが変だと思うのですが。XMLは「機械と機械の
>間」のインタフェースですよ ね。
このあたりが、立場の違いの一つですね。エンドユーザ向けかと言われれば、「もちろん違います」とこたえるのですが。
アセンブラも、PostScriptも、HTMLも、人とマシンをつなぐための言語ですよ。技術者しか使いませんが。テキストで符号化するものは、たいていそうだと言ってかまわないのじゃないでしょうか。もちろん、XMLだって同じだと考えています。
したがって、nasbさんがXMLを「人間と機械のインタフェースではない」と判断させた理由にはちょっと興味があります。
#「面倒臭い」と「難しい」は、エンドユーザ向けにはふさわしくないことしか示していません。
>XMLの使用をユーザに意識させるのは良いインタフェースでは無い、
>というの はよろしいでしょうか?
>その上で、実装の簡便さの利得が、ユーザが受ける苦労の程度
>を上回るならば ユーザにXMLの使用を意識させるのも妥当だと
>思いますよ。
最初の言明だけだと100%の賛成はできませんが、後の文も含めれば同意できます。
>スタイルシートがなぜ必要なのか判らないのですが、ひょっとしてXHTML
>(また はレイアウトを仕様に含めないその他のXMLの実装)を仮定していたのでしょう か?
うーむ。私がなにやら勝手に色々仮定しすぎていたのかな?以下、私の認識です。
(ちなみに私は、以前Operaの話題であったパラグラフ先頭のJIS X 0208の空白が削除される件は、スタイルシートで対応するのが筋だと考えてます。そんなところで独自性を主張しても、「日本語対応って面倒クセェ」と思われるだけで、あまりメリットがなさそうです。)
ということで、もし「スタイルシートいらない」&「標準のタグセットがあればいい」であれば、私が考えている「可能な限りの表現の自由」を求めているわけではないので、対立しているように見えた話題には決着がつきます。
他には、特にnasbさんと対立しているという意識は無いのですが、こんな話題ならまだ続けたいような気も。
Re:スペースの次はタブ (スコア:1)
その観点でいうと、たとえば「XHTMLを直書きさせる」というのは、XHTMLとい う「機械と機械」のインタフェースをほぼそのまま「人間と機械」に写像した、 と言えます。適当な入力支援を使う場合も同様に、それはXHTMLを若干加工を 加えて新たなユーザインタフェースの一つに写像したものです。
さて、Jadawinさんは
という話をしていて、私は という話をしている、というのが私の認識ですが、私は二人の間で何かが対立しているという気がしないのです。 「標準のタグセット」を「適切な仕様を与えた新たなXMLの実装」と読み取っ ていいとすると、「そういう実装を使っても構わない」と思っています。 これは私自身深く考えていたわけではありません。しかし、Jadawinさんが既 に書かれていたようなことができれば十分と思います。というのは、(この話 がもともとターミナルエミュレータのトピックだったように)ターミナルエミュ レータに出力させるような古典的な(しかしまだ需要はある)プログラムを記述 するための便法が、私の想定する「ユーザの目的」だからです。# カラムを揃えるポリシやそのアルゴリズムを考えるのは楽しそうですが。
Re:スペースの次はタブ (スコア:1)
>私はここ用いられている意味での「エンドユーザ」とアセンブラやPostScript を記述する
>「プログラマ」を、区別する必要は無いと思っています。
えと、nasbさんがこのように思いたいというのは認識しました。私の考えは、ユーザによって(nasbさん言うところの)「目的や環境」が異なり、本当にそれぞれの利便を追求すると一つのインタフェースになるとは思いにくいってやつです。
>その観点でいうと、たとえば「XHTMLを直書きさせる」というのは、XHTMLとい
>う「機械と機械」のインタフェースをほぼそのまま「人間と機械」に写像した、
> と言えます。適当な入力支援を使う場合も同様に、それはXHTMLを若干加工を
>加えて新たなユーザインタフェースの一つに写像したものです。
これは論理的には間違っていませんが、ちょっと抽象論に寄りすぎて、現実には違うものを無理に一緒にしている感があります。同じ論理を展開すると、ユーザがキーボードを叩いて、文章を入力できるという意味では、ユーザインタフェースとして、かな漢字変換がT-コードやJIS16進入力と同じだと主張できてしまいます。ユーザインタフェースを語る文脈では、あまりにも乱暴な論理展開ではないでしょうか?
>レイアウトは不要。「人間と機械」の間は直書き、またはな んらかの入力支援を用い、
>「機械と機械」の間はXHTMLのようなレイアウトを 含まないXMLの実装を用いる。
これは明らかに私の主張を誤解されています。レイアウトを不要という人間が、自らスタイルシートの話題を出したりはしません。そもそもスタイルシートがどのようなものかご存知ですか?
>レイアウト表現は落とさない。「人間と機械」の間はTSV(のよ うなもの)、
>「機械と機械」の間はとくに拘らない。 (当然、XMLを使うならレイアウトを含むXMLの実装になるだろう。)
これもXMLとスタイルシートに関する誤解から来ている言葉のように思えます。スタイルシートを利用するとHTMLと同程度にサボりたい人はサボれるし、いじりたい人にはいくらでもいじれるようになります。どうです?nasbさんの要求にあっているとは思いませんか?
>という話をしている、というのが私の認識ですが、私は二人の間で何かが対立しているという気がしないのです。
こちらの立場は対立というよりは、「nasbさんがXMLをけぎらいしているらしいのをなんとか変えたい」に変わってます。
>ターミナルエミュ レータに出力させるような古典的な(しかしまだ需要はある)プログラムを記述
>するための便法が、私の想定する「ユーザの目的」だからです。
このような条件であれば、nasbさんのおっしゃっていることのだいたいには同意できます。ただ、TSVの方式は明らかにベストではありません。複雑な文字の組合せのあるタイ語やアラビア語では比較的すぐに限界にぶちあたるだろうと思います。
#それらを考えないなら、今まで通りでよい分けですし。
ですから、もし本当にすべての言語をサポートするつもりなのであれば、一見は手間がかかるだけのように見えても、XML+スタイルシートの形式が最終的には一番の近道ではなかろうかと思っているわけです。
#ちなみに、XML+スタイルシートが唯一の解であるとも、それが最も簡単な解であるとも、
#主張はしません。とりあえず、XMLの自由度の高さを生かせばかなりの場面で対応できるだろう。
#それより条件が絞れるかどうかは、それらの言語を生まれながらに話す人々の判断にまかせたい
#てな感じでしょうか。
Re:スペースの次はタブ (スコア:1)
はるかに遠ざかってしまった気がします。(;_;)
私の考えは、ユーザによって「目的や環境」が異なるので、それぞれに応じて 適切なインタフェースを選べばよい、です。で、両者に違いがあるのですか?
誤解しています。「人間と機械」のインタフェース(またはユーザインタフェー ス)というレイヤの話をしているのです。単一のインタフェースの話している のではありません。
例示も、「機械と機械」のインタフェースというレイヤのものを、「人間と機 械」のインタフェースというレイヤに持ってくるときに、写像の方法が何通り もあるよ、という話です。
誤解とは思えません。ここでは(これまでも)ユーザインタフェースの話をして います。ユーザインタフェースがレイアウトを機械に伝達するかどうか?の話 です。レイアウト情報を用いないXMLの実装を用いて「スタイルシートに任せ る」と言った時点で、ユーザの表現したレイアウト情報が落ちるんです。
後で出た「拘りたいならスタイルシートを別に書き起こせばいい」という話は 別の話です。それは、そもそも、「レイアウト情報を含むXML実装」と(「機械 と機械」の)インタフェース的に等価です。そして、私の言っていることに包 含されます。
スタイルシート(どのスタイルシートを指しているのかは知りませんが)のよう にレイアウトを表現する能力を持ったインタフェースが、レイアウトを伝達す る目的に使えるのは言うまでも無く自明ですが。
私はXMLは嫌いでもなんでもなくて、XMLとは関係ない話に関して「XMLは関係 無い」と言っているだけなのですが、その点が伝わるとこの長話も終わるのか なあ、という気がしてきました。
複雑な組み合わせが起こる文字種でも、そんなに簡単に限界に到達する気はし ません。そもそもの発端が「それらのことを考えましょ」という話ですし。
「機械と機械」のインタフェースにそれを用いるのには反対はしませんけれど (というか、そこは話の本質でないのでどうでもいい)、その先の「人間と 機械」のインタフェースには何を選んでもいいでしょう。
それこそ、「ユーザによって『目的や環境』が異なるので、それぞれに応じて適 切なユーザインタフェースを選べばよい」です。
Re:スペースの次はタブ (スコア:1)
たぶん、一番の違いは、次の所にあるんだろうと言う気がします。
#単にnasbさんは物事を簡単にとらえたいから、細部を省いた言明を好み、
#私は複雑なものは複雑なままとらえるのを好むんで、徹底的に条件をつける、
#という違いに思えてきました。まぁ、それでも分からん所もあるんですが。
下層がどのような機能を持つかを気にしないでよいのは、アプリケーションのレベルから見て下層が100%等価なものの場合だけです。
#出力ファイルを保存するディレクトリを変えたところで、操作には影響しません。
前にnasbさんが上げたグラフィックツールの保存形式の例だって、JPEGを選択すると圧縮率がどうだとか、別途設定ダイアログがありますよね?すべてが全く同じユーザインタフェースにはなりませんよね?これは、下層の機能によってユーザインタフェースが変わる例ではありませんか?
>レイアウト情報を用いないXMLの実装を用いて「スタイルシートに任せ る」と言った時点で、
>ユーザの表現したレイアウト情報が落ちるんです。
あのー、すんません。このあたりは、徹底的に理解できんです。
既存のスタイルシートに任せるかどうかは、ユーザが選択するのではないですか?ユーザが選択する以上は、それがユーザの意図したレイアウト情報になるはずですが。そうで無ければ、そのユーザは何らかの方法でスタイルシートを書けばよいのではないですか?なぜスタイルシートを書くことが、ユーザインタフェースの一部にはなりえないんですか?
それに、スタイルシートを使えば落ちてしまうようなレイアウト情報って何があるのでしょう?テキストの中に含めた空白の数とかを問題にしたいのでしょうか?今話している文脈では、カラム幅は不定という前提がありますから、空白は入っているか否かしか問題にはできないはずで、レイアウト情報を持っているとは言えませんが。
また、私はスタイルシートを用いるとは言っていますが、XMLの入力と同様に入力補助手段を用意するのでしょうから、その場合ユーザインタフェースの上からはシームレスに見えるでしょう。
#おお。そうか、これを指してnasbさんは「レイアウト情報を含むXML実装」と呼びたいのですね。
#でも、この言葉ではHTML4.0をそのままXML化したようなものを思い浮かべてしまいます。
#nasbさんの言いたいことであれば、もっと抽象的な言い方をすべきだったのではないでしょうか?
#実装なんて言葉が出ると、私なんかものすごく具体的な事柄を期待してしまうのですが。
#また、そのように理解した上でもスタイルシートに関しておっしゃることは理解できないままです。
>複雑な組み合わせが起こる文字種でも、そんなに簡単に限界に到達する気はし
>ません。そもそもの発端が「それらのことを考えましょ」という話ですし。
本当ですか?少なくとも、漢字の各パーツ(へんやつくりより小さいレベルのもの)を組み合わせて、任意の漢字をつくり出すのと同程度に大変なものになるはずです。そりゃ不可能では無いにしろ、最初に言っていたタブで区切る程度の簡単な形式とはかけ離れたものになりませんか?共通点は、タブで区切られているというだけで、グループ化を可能とする記号列とか、ネストを可能にする記号列とか、特定の部分の参照の方式とかを追加していくのですよね。
Re:スペースの次はタブ (スコア:1)