アカウント名:
パスワード:
なんだかんだ言って、初めてスクリーンエディタができた頃からごく最近まで、 アルファベットと数字だけ使えればよかった時代は幸運だったし幸福だったと 思う。全ての文字が同じ大きさだったおかげで、印字内容とレイアウトという 異なる概念がでそのまんま具現できたから。そのおかげでテキストエディタっ てのは最初の時代から今まで使えるずっと便利なWYSWYG環境だったわけで。
でも、「レイアウトなんて情報交換には無駄無駄。押し着せのレイアウトで十分」というふうには、割り切れんもんなのでしょうか?
見落としているかもしれませんが、レイアウトというのは貴重な情報源です。適切なレイアウトはデータを整理し、人間の理解を助けます。そもそも、人間が表現を行うときには、本質的にデータとレイアウトの両方を含んでいます。ただ、そのままではmachine readabilityが低いので、ここ数年来、データとレイアウトを分離する必要性が認知され実践されてきました。
しかし、分離したとき
#たぶん全部というのかなぁ? もしこれらすべてというのであれば、同じレンダ
machine-machine interfaceはどんな形式でも構いません。統一されるのはよ いことなのでXMLでOKです。
しかし、私は最初から今までhuman-machine interfaceの話をしています。 human-machine interfaceはend pointなので、どんな形式に変換してもよいし、 その際には人間のニーズにとって、より直感的で便利な形式を採るのがよいで しょう。
具体的な例として挙げて来たのが、ターミナルエミュレータ(たとえば今回の mlterm)に表示される情報をCやPerlの中に埋め込む時に、よいインタフェース は何か? ということです。プログラムのソースもhuman-machine
#結局は、スタイルシートは面倒だという話?それはそれで、納得できる意見です。
アプリケーション(=ユーザがやりたいこと)を定義した時には、適切なユーザ インタフェースを選びますよね。面倒でないというのは良いUIの要件ですから、 タグを打つのよりも楽な方法があればそれを採るわけです。もちろん、XML直書き の方が幸せな人がいれば、それでもいいわけ
XMLの使用をユーザに意識させるのは良いインタフェースでは無い、というの はよろしいでしょうか?
その上で、実装の簡便さの利得が、ユーザが受ける苦労の程度を上回るならば ユーザにXMLの使用を意識させるのも妥当だと思いますよ。
それを前提に「
このあたりが、立場の違いの一つですね。エンドユーザ向けかと言われれば、 「もちろん違います」とこたえるのですが。
私はここ用いられている意味での「エンドユーザ」とアセンブラやPostScript を記述する「プログラマ」を、区別する必要は無いと思っています。両者とも、ユーザイ ンタフェースのこちら側であり、目的や環境が異なるだけです。そしてその目 的や環境に応じて、直感性や、機能性などのさまざまなパラメータの中から何 を重視するかを選んで、ユーザインタフェースが決まるわけですから。
したがって、nasbさんがXMLを「人間と機
うーん。もうちょっと感が。
はるかに遠ざかってしまった気がします。(;_;)
私の考えは、ユーザによって(nasbさん言うところの)「目的や環境」が異なり、 本当にそれぞれの利便を追求すると一つのインタフェースになるとは思いにく いってやつです。
私の考えは、ユーザによって「目的や環境」が異なるので、それぞれに応じて 適切なインタフェースを選べばよい、です。で、両者に違いがあるのですか?
これは論理的には間違っていませんが、ちょっと抽象論に寄りすぎて、現実に は違うものを無理に一緒にしている感があります。同じ論理
既存のスタイルシートに任せるかどうかは、ユーザが選択するのではないですか?ユーザが選択する以上は、それがユーザの意図したレイアウト情報になるはずですが。そうで無ければ、そのユーザは何らかの方法でスタイルシートを書けばよいのではないですか?
なぜスタイルシートを書くことが、ユーザインタフェースの一部にはなりえな いんですか?
#おお。そうか、これを指してnasbさんは「レイアウト情報を含むXML実装」と呼びたいのですね。 #でも、この言葉ではHTML4.0をそのままXML化したようなものを思い浮かべてしまいます。 #nasbさんの言いたいことであれば、もっと抽象的な言い方をすべきだったのではないでしょうか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
ところで (スコア:1, 興味深い)
文字ピッチの問題をどうやって解決すればいいんでしょうか。
たとえば、英語端末では歴史的に固定ピッチフォントでないと困りますし、
日本語端末だと歴史的に漢字は ANK の倍の幅をもってないといろいろ困ったことになったりしますけど、
エスニックな文字ではその辺はどうなってるんでしょう?
前から多言語な端末作
Re: ところで (スコア:1)
> 英語端末では歴史的に固定ピッチフォントでないと困りますし、
しばらく9termを使った経験からいうと、端末がプロポーショナルフォントでもあんまり困らないと思います。困るのはせいぜい、アスキーアートを見る時くらいじゃないでしょうか。
Re: ところで (スコア:1)
Re: ところで (スコア:1)
# で、タブの定義は? :-)
Re: ところで (スコア:1)
繁雑にはなるけど、パーズは楽になる、、、はず、、。
#XMLの適用って、どんなデータまで妥当?
スペースの次はタブ (スコア:1)
なんだかんだ言って、初めてスクリーンエディタができた頃からごく最近まで、 アルファベットと数字だけ使えればよかった時代は幸運だったし幸福だったと 思う。全ての文字が同じ大きさだったおかげで、印字内容とレイアウトという 異なる概念がでそのまんま具現できたから。そのおかげでテキストエディタっ てのは最初の時代から今まで使えるずっと便利なWYSWYG環境だったわけで。
Re:スペースの次はタブ (スコア:1)
>たとえ ば JavaML [washington.edu] なんてものもあるけど、そのソースを手で
>こう [washington.edu]書くなんて気が狂うでしょ。
それぐらいは、書けんことはないですよぉ。それって、別にテキストじゃなくてプログラムローダーを書いているわけですから。
>テキストエディ タでスペースバーを叩いてレイアウト決めてたのに比べればどれだけ大変か。
それは同意。でも、「レイアウトなんて情報交換には無駄無駄。押し着せのレイアウトで十分」とい
Re:スペースの次はタブ (スコア:1)
見落としているかもしれませんが、レイアウトというのは貴重な情報源です。適切なレイアウトはデータを整理し、人間の理解を助けます。そもそも、人間が表現を行うときには、本質的にデータとレイアウトの両方を含んでいます。ただ、そのままではmachine readabilityが低いので、ここ数年来、データとレイアウトを分離する必要性が認知され実践されてきました。
しかし、分離したとき
Re:スペースの次はタブ (スコア:1)
これ↓以前のところは同意。
>しかし、分離したときに、人間の自然な表現に含まれていたはずのレイアウトは
>どこに行くのでしょう?
さて、このあたりからちょっと立場が違うようです。さっきの乱暴な聞き方じゃなくて、もう少しブレークダウンします。文書はどこまでオリジナルに忠実であるべきだと思いますか?
#たぶん全部というのかなぁ?
もしこれらすべてというのであれば、同じレンダ
Re:スペースの次はタブ (スコア:1)
machine-machine interfaceはどんな形式でも構いません。統一されるのはよ いことなのでXMLでOKです。
しかし、私は最初から今までhuman-machine interfaceの話をしています。 human-machine interfaceはend pointなので、どんな形式に変換してもよいし、 その際には人間のニーズにとって、より直感的で便利な形式を採るのがよいで しょう。
具体的な例として挙げて来たのが、ターミナルエミュレータ(たとえば今回の mlterm)に表示される情報をCやPerlの中に埋め込む時に、よいインタフェース は何か? ということです。プログラムのソースもhuman-machine
Re:スペースの次はタブ (スコア:1)
>具体的な例として挙げて来たのが、ターミナルエミュレータ(たとえば今回の mlterm)に
>表示される情報をCやPerlの中に埋め込む時に、よいインタフェース は何か? ということです。
>プログラムのソースもhuman-machine interfaceの一つ ですよね。
それが論点の中心であれば、私の意見は「XML吐くだけならフレームワークというか、ライブラリと言うか、それを補助するものを使えばいいんじゃないかなぁ?」です。でもnasbさんの本論は「そのような所でも表現の余地を残したい」でしたっけ。そうすると、、、
Re:スペースの次はタブ (スコア:1)
アプリケーション(=ユーザがやりたいこと)を定義した時には、適切なユーザ インタフェースを選びますよね。面倒でないというのは良いUIの要件ですから、 タグを打つのよりも楽な方法があればそれを採るわけです。もちろん、XML直書き の方が幸せな人がいれば、それでもいいわけ
Re:スペースの次はタブ (スコア:1)
>私は終始「人間と機械の間」のインタフェースの話をしています。
私もそうです。ただ、私の場合はそもそも人間(この場合はnasbさん)の要求がどこにあるかを明らかにしない限りは、インタフェースの設計は無理だと思っています。また、基本にある技術を仮定せずには、何ができるかを判断できません。それで、XMLを仮定してnasbさんの場合だと、どの程度が妥当かを聞いている訳です。要するに、技術で実現できることを念頭において、何ができることを期待するかやどの程度まで労力を払ってもよいかを、nasbさんの一例でよいから知りたいと思った訳です
Re:スペースの次はタブ (スコア:1)
XMLの使用をユーザに意識させるのは良いインタフェースでは無い、というの はよろしいでしょうか?
その上で、実装の簡便さの利得が、ユーザが受ける苦労の程度を上回るならば ユーザにXMLの使用を意識させるのも妥当だと思いますよ。
Re:スペースの次はタブ (スコア:1)
> 「人間と機械の間」のインタフェースの話に、基本技術として
>XMLが出てくる のが変だと思うのですが。XMLは「機械と機械の
>間」のインタフェースですよ ね。
このあたりが、立場の違いの一つですね。エンドユーザ向けかと言われれば、「もちろん違います」とこたえるのですが。
アセンブラも、PostScriptも、HTMLも、人とマシンをつなぐための言語ですよ。技術者しか使いませんが。テキストで符号化するものは、たいていそうだと言ってかまわないのじゃないでしょうか。もちろん、XMLだって同じだと考えています。
したがって、nasbさんがXMLを「人間と機械のイ
Re:スペースの次はタブ (スコア:1)
私はここ用いられている意味での「エンドユーザ」とアセンブラやPostScript を記述する「プログラマ」を、区別する必要は無いと思っています。両者とも、ユーザイ ンタフェースのこちら側であり、目的や環境が異なるだけです。そしてその目 的や環境に応じて、直感性や、機能性などのさまざまなパラメータの中から何 を重視するかを選んで、ユーザインタフェースが決まるわけですから。
Re:スペースの次はタブ (スコア:1)
>私はここ用いられている意味での「エンドユーザ」とアセンブラやPostScript を記述する
>「プログラマ」を、区別する必要は無いと思っています。
えと、nasbさんがこのように思いたいというのは認識しました。私の考えは、ユーザによって(nasbさん言うところの)「目的や環境」が異なり、本当にそれぞれの利便を追求すると一つのインタフェースになるとは思いにくいってやつです。
>その観点でいうと、たとえば「XHTMLを直書きさせる」というのは、XHTMLとい
>う「機械と機械」のインタフェースをほぼそのまま「人間と機械
Re:スペースの次はタブ (スコア:1)
はるかに遠ざかってしまった気がします。(;_;)
私の考えは、ユーザによって「目的や環境」が異なるので、それぞれに応じて 適切なインタフェースを選べばよい、です。で、両者に違いがあるのですか?
Re:スペースの次はタブ (スコア:1)
たぶん、一番の違いは、次の所にあるんだろうと言う気がします。
#私は複雑なものは複雑なままとらえるのを好むんで、徹底的に条件をつける、
#という違いに思えてきました。まぁ、それでも分からん所もあるんですが。
下層がどのような機能を持つかを気にしないでよいのは、アプリケーションのレベルから見て下層が100%等価なものの場合だけです。
#出力ファイルを保存するディレクトリを変えたところで、操作には影響しません。
前にnasbさんが上げたグラフィックツールの保存形式の例だって、JPEGを選択すると圧縮率がどうだとか、別途設定ダイアログがありますよね?すべてが全く同じユーザインタフェースにはなりませんよね?これは、下層の機能によってユーザインタフェースが変わる例ではありませんか?
>レイアウト情報を用いないXMLの実装を用いて「スタイルシートに任せ る」と言った時点で、
>ユーザの表現したレイアウト情報が落ちるんです。
あのー、すんません。このあたりは、徹底的に理解できんです。
既存のスタイルシートに任せるかどうかは、ユーザが選択するのではないですか?ユーザが選択する以上は、それがユーザの意図したレイアウト情報になるはずですが。そうで無ければ、そのユーザは何らかの方法でスタイルシートを書けばよいのではないですか?なぜスタイルシートを書くことが、ユーザインタフェースの一部にはなりえないんですか?
それに、スタイルシートを使えば落ちてしまうようなレイアウト情報って何があるのでしょう?テキストの中に含めた空白の数とかを問題にしたいのでしょうか?今話している文脈では、カラム幅は不定という前提がありますから、空白は入っているか否かしか問題にはできないはずで、レイアウト情報を持っているとは言えませんが。
また、私はスタイルシートを用いるとは言っていますが、XMLの入力と同様に入力補助手段を用意するのでしょうから、その場合ユーザインタフェースの上からはシームレスに見えるでしょう。
#おお。そうか、これを指してnasbさんは「レイアウト情報を含むXML実装」と呼びたいのですね。
#でも、この言葉ではHTML4.0をそのままXML化したようなものを思い浮かべてしまいます。
#nasbさんの言いたいことであれば、もっと抽象的な言い方をすべきだったのではないでしょうか?
#実装なんて言葉が出ると、私なんかものすごく具体的な事柄を期待してしまうのですが。
#また、そのように理解した上でもスタイルシートに関しておっしゃることは理解できないままです。
>複雑な組み合わせが起こる文字種でも、そんなに簡単に限界に到達する気はし
>ません。そもそもの発端が「それらのことを考えましょ」という話ですし。
本当ですか?少なくとも、漢字の各パーツ(へんやつくりより小さいレベルのもの)を組み合わせて、任意の漢字をつくり出すのと同程度に大変なものになるはずです。そりゃ不可能では無いにしろ、最初に言っていたタブで区切る程度の簡単な形式とはかけ離れたものになりませんか?共通点は、タブで区切られているというだけで、グループ化を可能とする記号列とか、ネストを可能にする記号列とか、特定の部分の参照の方式とかを追加していくのですよね。
Re:スペースの次はタブ (スコア:1)