アカウント名:
パスワード:
なんだかんだ言って、初めてスクリーンエディタができた頃からごく最近まで、 アルファベットと数字だけ使えればよかった時代は幸運だったし幸福だったと 思う。全ての文字が同じ大きさだったおかげで、印字内容とレイアウトという 異なる概念がでそのまんま具現できたから。そのおかげでテキストエディタっ てのは最初の時代から今まで使えるずっと便利な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の使用を意識させるのも妥当だと思いますよ。
それを前提に「表現の余地」を残すのであれば、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)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
ところで (スコア: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の使用を意識させるのも妥当だと思いますよ。
スタイルシートがなぜ必要なのか判らないのですが、ひょっとして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)