Linuxは、開発環境が40年前と同レベル

間違ってもらっては困るのは、それはコマンドライン・メインなのが主因ではないということ。
本当の一因は、本来手書きでも簡単な Makefile の作成をわざわざ難しくしてしま
う autotools を権威に流されたのか多くのプロジェクトが使ってしまっている事にある。
高々 Makefile 1つ作るためにも以下のような工程を踏まなければならない。
本来、典型的には、ソースファイルである *.c, *.cxx, *.cpp を指定するだけ
でも自動生成する事が出来るはずなのに、ツール類が馬鹿だからそうなってない。
なのに、「Linuxはプログラマーには便利」などと嘘情報が流れるから、普及しない。
しかも、カレントディレクトリのスクリプトの実行に「./configure」などと「./」
の指定が必要なのも馬鹿丸出し。ファイル名に大文字小文字の区別がされているのも馬鹿。
ファイルのコピーもdosなら、「copy *.c /xxx/aaa 」で済むことが
$ find . -name '*.c' | xargs -n 1 -i cp -p {} /xxx/aaa
などとしなくてはならず長すぎ、馬鹿ですか？ しかも、'*.c'の部分が、*.c と書かれている
説明が溢れているがそれだとbashが展開してしまうのでたまたま上手く行く事はあっても、
実際には正しくない。また、mountしないとディスクが認識出来ないのも初代PC-8001の
レベル。PC-8801で自動マウントできるようになったのに（いつの時代（苦笑））。まずは、
不便さを認めるなければ、改善すらままならないのにそれすら全否定。正直に便利と思って
るなら井の中の蛙で馬鹿で無知なだけだ。そして、僅か１点でも間違いがあれば全てが間違って
いるように全否定してしまうLinux信奉者の愚かさもアホとしか言いようがない。

あげ

そういうところがあるから潰しは効く。
パッケージ管理をsnappyに置き換えるらしいけどあまり流行ってない。
移行したのかと思ったらまたdebに戻すとか言ってるのもある。

>>123

XML云々以前に設定ファイルの構造なんか元々ばらばらだろ

お？ 今頃レスがｗ

>>177
だから設定ファイルの構造を仕様化すればよかったという話ですよ？
極論を言えば、設定ファイルなんぞ入れ子構造なし。
リスト形式だけでも十分なんですよ

例
<xml>
　<input type="text" name="name1">
　<input type="text" name="name2">
　<input type="text" name="name3">
　<input type="text" name="name4">
</xml>

分かりやすくHTMLっぽくしましたがね

ここを出発点に項目が多くなれば見づらくなるので
グループ化、階層化するための<fieldset>のようなものが必要
複数の選択項目から選べるよう<select> <option> のようなものが必要
数値入力、日付入力、などの機能が必要

そうやって設定を行うためのフォームのようなタグを定義していって
あとはCSSとJavaScriptのサポートでも行えば、
設定ファイル自体が、設定UIとしての機能を持ち、
汎用の設定ツールで設定可能なものができていたんですよ。

つまりわざわざ設定画面を作り込む必要がない
プロトタイプのような簡易なもので十分な段階では、本当に手軽に作ることができ、
作り込もうと思った段階で使いやすい設定画面に少しづつ変えていくことができたわけです。

アホな妄想垂れ流すヒマがあったら
スレタイ読んでくれ

>>179
レスが付いたから、レスしただけ
妄想自体はアホではない。

.netなら設定をXMLで出し入れする機能あるよ

>>181
XMLで出し入れするのはいくらでもあるよ。
でもXMLっていうのは、通常そのまま使うものじゃない
例えばSVGのようにタグを作って使うもの。

アプリごとに独自のタグ作って、それで
使いやすいものができるわけがない。
XMLによる設定ファイルは確実にやり方を間違った

ぼくのかんがえたさいきょうの設定ファイルの規格でも発表したらよかろあ

>>183
考える前に既存の仕様を探したほうが良い。
すでに最強であることは保証済み

最初に思いつくのはHTMLのフォームだね
あれはデータをポストするものだが、
ファイルに保存すれば設定ファイルとしても使える

最強既存規格が普及してないのはなぜだろう

リナックスのディストリみたいに
こっちの方がもっと最強！
が量産されるだけ

>>185
Linuxのみ普及していないというならまだしも
他でも使われていないようなものが使われてないから
[Linuxは、開発環境が40年前と同レベル]である
と言われても頭おかしいとしか言いようがないよな

>>187
その一連のレスは、そういう内容ではないんだが、頭大丈夫か？

>>183-187
設定ファイルの仕様化？標準化？とりあえずxmlなんかでやるぐらいならjsonでやってくれって感じ。
設定ファイルのスタンダードいくつか出てきてるけど、xmlなんぞ持ち出してくるとは少しきついな。
html手打ちさせるアプリケーションってなんだよwwww

レスする先を間違えた。無視してくれ、失礼。

>>189
> 設定ファイルの仕様化？標準化？とりあえずxmlなんかでやるぐらいならjsonでやってくれって感じ。
jsonでやっても複雑になるだけだぞ

JSONはデータのみをやり取りする方法。メタ情報的なものが少ないからデータ通信には適してるが
手書きは面倒だし（例 コメントが書けない）手書きするならYAMLのほうがまだまし。

今の設定ファイルにはメタ情報が含まれていない。ここで言うメタ情報というのは
ある設定値が取れる範囲などの情報が書かれていないということ
例えば、sambaのmap to guestという項目は「Never」「Bad User」「Bad Password」の
いずれかの値を入れることができるが、そのことが設定ファイルには書かれていない
（コメントとして書かれている場合があるかもしれないぐらい）

これがHTMLであれば、<select>を使って<option>で選択可能項目を明示できる

言っておくが、このHTML風XMLの設定ファイルをユーザーがテキストエディタで直接変更することは考えていない
そんなことをすると<select>とか<option>とか書いてもそれ以外の値に設定できてしまうだろ

ブラウザライクな設定ツールから設定する。バイナリ形式の設定ファイルがユーザーが直接変更できないのと同様
設定変更には設定ツールを用いる。HTML風XMLの設定ファイルは開発者が作成するもの

> 設定ファイルのスタンダードいくつか出てきてるけど、xmlなんぞ持ち出してくるとは少しきついな。
> html手打ちさせるアプリケーションってなんだよwwww
これは手打ちを不要にするための方法。

設定ファイルのフォーマットが標準化されることで、ブラウザライクな汎用の
設定ファイル編集ツールを作ることが可能になる。
HTMLのフォームだって設定を変えるのに手打ちしてるわけじゃないだろ？
HTMLを元に作ったUIで設定を変更している。

>>191
勉強し直せ。xmlでやるぐらいならjsonでいいってことを言っただけでjsonも好ましくない。
ただ、リスト構造でいいならjsonの連想配列で十分。yaml以外のスタンダードもある。
とりあえず、なにも知らない人、文章力読解力のない人の妄想ってことが十分わかったのでもう絡んでこないで。

> 勉強し直せ。xmlでやるぐらいならjsonでいいってことを言っただけでjsonも好ましくない。

いやだから、XMLはOKだけどJSONはNGって場合もあるんだよ。
例えばOfficeのフォーマットなんかJSONじゃまず無理だろ

違いはXMLにはデータのメタ情報が追加できるってこと。
JSONは名前と値だけしかない。これが問題になる有名な例が日付型

JSONで書くとこのような感じになるが、このdateが文字列か日付なのかを区別することができない
{ "now": "2013-09-16T22:32:36Z" }

それに対してXMLだと以下のようにメタ情報を追加できる。
<value name="now" type="date">2013-09-16T22:32:36Z</value>

もちろんJSONでも、値を入れるときは特別なハッシュ構造とすること
なんて独自のルールを追加すりゃできるが、それはデータの持ち方を工夫するということであって
フォーマット自体の表現力が足りないためのワークアラウンドに過ぎない

データ通信は今現在の仕様として、この項目は日付型として扱うみたいにしちゃえるけど
永続的なデータとして残しておくようなものには適していない

XMLで値の範囲を制限したいなどはスキーマ使えばできるだろ
実際やってるかどうかは置いといて規格はある

確かにあるね。昔はDTD、今（？）はXML Schemaかな
あれは設定ファイルのフォーマットのチェックには使えると思う
複雑らしいけど

でも設定ファイル（兼入力フォーム）のXMLファイルには適してないと思う
何故かと言うとUIを作るための情報としては不足してるから

例えば、HTMLの<select>は意味的には<input type="radio">と同等なんだ
また<select multiple>は<input type="checkbox">と同等
前者は複数の選択項目のうちから一つを選ぶもの
後者は複数の選択項目のうちから複数を選ぶもの

なぜ同じものが２つ用意されているかと言うと、インターフェースを意識しているからだろう
<select>は画面に選んでいるものだけが表示される。
<input type="radio">は選択されてないものも含めて表示される。
どのようにレンダリングされるかはブラウザが決めることだが、
期待するレンダリングがそのタグに含まれてる

これが単なる入力チェックならどちらも同じになるだろうね
なのでXML Schemaはフォーマットの検証として使うことはできるが
フォームの代替にはならない

設定ファイルの標準化と文章コーディングを同一視してる時点で厳しい。
xmlはマークアップ言語でjsonはデータ記述言語なんでそもそもが違う。
一般的には設定ファイルには最小限の変数だけがあればいい。
なんだ？ものすごくエスパーしたけど、詰まるところは
設定ファイルのフォーマットを標準化すれば設定ファイル編集アプリなるものが一個で済むでしょってだけの話か？
そしてそれをブラウザでアクセスさせるのか？

それから設定ファイルをテキストエディタで直接編集する場合の
問題点の一つとして多言語対応が難しいっていうのがある

コメントによる説明はおそらく英語だろう見ながら変更がしづらい。
結局の所、エンドユーザーの使い勝手を考えると
設定ツールの存在は必須と言える。

>>196
> なんだ？ものすごくエスパーしたけど、詰まるところは
> 設定ファイルのフォーマットを標準化すれば設定ファイル編集アプリなるものが一個で済むでしょってだけの話か？
そのとおり。正確に言えば開発者の負担が減る
開発の初期段階は簡単なフォームを用意するだけでいいし、
アプリごとに独自の設定ツールを開発する負担が無くなるのは大きなメリット
初心者でも簡単に変更できるし、多言語対応などもできる

> そしてそれをブラウザでアクセスさせるのか？
ブラウザは開いているHTMLファイル自体を変更できないのでだめだが
ブラウザベースで作ればJavaScriptやCSSも使えるのでいいだろう。

今でもブラウザで設定が可能なものはあるが、それはたいてい
ウェブサーバー機能を持っているものに限られるだろう
ウェブサーバーを必要とせず、ブラウザベースだが開いているHTMLファイル（の項目）しか
変更できず、セキュリティのために外部サイトの接続もできないようにしたものが良いだろう

>>196
> xmlはマークアップ言語でjsonはデータ記述言語なんでそもそもが違う。

そう。だからなんでjsonなんてものを持ってきたのか理解ができない

>>196
> 一般的には設定ファイルには最小限の変数だけがあればいい。

理屈的にはそのとおりだが、実際の設定ファイルを見ると
最小限の変数以外のものがたくさんある。

その多くは、ユーザーのために設定の変更をサポートするための
説明だったり、設定値の候補だったりする

現実には設定ファイルには最小限の変数だけでは
だめだということがよく表されている

jsonが設定ファイルのアプリなんかいっぱいある。
今、xmlが廃れて、jsonがやや使われ始めてるのは可読性の問題。
つまり、GUIで制御できるならテキストベースの設定ファイルは必要ないし、
テキストベースの設定ファイルは必要最小限の変数で見やすいのが求められてる。
xmlは書きにくい読みにくい。htmlも直接書かないのが流行ってる。

つまり知らないから変な提案する。

やっぱり理解してないｗ
jsonが設定ファイルのアプリが一体どれだけあるっていうんだか
あったところで、そういうアプリはどうせオリジナルの設定ツール使って設定だろ？
そういうのをいちいち作らないといけないのが大変だという話をしてるのに
大変な実例を持ってこられても意味がない

GUIで設定できるHTMLがテキストベースである理由もわかってないのだろう
XMLが読み書きしにくいって、お前はテキストエディタも使えないのかｗ

XMLベースのものなんていくらでもあるSVGもそうだし
Office形式もXMLベース。XAMLもそうだし、
apt-file search .xml とでも実行してみろ。122732ファイルもでてきた。
apt-file search ".xml" | cut -f1 -d: | uniq | wc -l
3444のパッケージで使われている。たいしてjsonは2149パッケージだ。
おかしいなｗjsonの方が使われてるじゃないかｗ

それにXMLじゃなかったら独自形式ばっかりだろ
あと反論の仕方も幼稚だ。いまXMLじゃないからが理由であって
俺の話に何一つ言及できていない。するだけの知能がない。

訂正

3444のパッケージで使われている。たいしてjsonは2149パッケージだ。
おかしいなｗ。jsonの方が少ないじゃないかｗ

> jsonは2149パッケージだ。
せいぜいXMLの1割ぐらいかと思ってたけど6割越えてるのか

HTMLのなんとかというタグはこう使うなんてのは
別でそういうお約束を与えてるだけなのに自然に決まるみたいな発想はどこから湧いてくるんだろう

自然に決まるなんて誰が言ったんだろう？

この下らないスレのやり取りでも新しい発見があった
それは既存のテキスト形式の独自形式の設定ファイル

それは、テキストエディタが設定ツールで
設定ファイル自体はUIとみなせるということ
設定ファイルには設置値だけではなく、コメントという形で
どういう項目であるかが書かれていて、ユーザーは
その説明を見て設定を変更する

新しいもなにも*nixは昔からコンソールでテキストコンフィグをいじるんだろ。
だからなにも知らないって言われるんじゃねーかwww

>>207
やっぱり理解してないｗ

上の方で馬鹿がいっていただろ？
設定ファイルは単に値さえ入っていればいいって。

現実として設定ファイルに人間が読むための文章が
入っていることの意味を理解してない

設定ファイルは単なる設定値があるだけのものではなくて
インターフェースになってるって話をしてる

そしてそのインターフェースを強化するための
XML設定ファイルの話をしてる

もう新しいスレたてろ。

classのセッターゲッターの話ですか

それは全く関係ないね。

>>205
自然に決まらないならoptionがどういうUIを持つか実装依存で何の意味があるのやら

何の意味があるのやらと言われても、ブラウザがそうじゃん
iPhoneの<select> & <option> 見たことある？
PC版とぜんぜん違うよ。ドラムロールと呼ばれるUIになってる

見た目は違う（実装依存）だが機能は同じ
物事を抽象化して考えられないのかな？

>>213
selectが選択肢から選ぶというのはどこから湧いてくるわけ？

>>214
質問の意図がさっぱりわからない

話の流れとしては、設定ファイルがXMLのものはたいてい
XMLを間違った方向に使ってしまってメリットが失われている
これが話の発端

間違っているというのならどういう使い方が正しいのか？
と聞かれたのでHTML（のフォーム）を参考にすれば良いと言った

そのHTMLのselectがどういうものかはw3cとかが決めてるだろ
もちろん参考でしかないのでXML設定ファイルを同じように
する必要はないが、他のXMLベースのフォーマットと同じように
誰かが決めるだけの話しだろ

それで、その質問は何が言いたいのだ？
俺はXMLベースの正しい使い方はどういったものであるべきかを説明しているだけなんだが？
selectの細かい仕様とか誰が決めるのかとかどうでもいいよ。
そこはXML設定ファイルがどうあるべきかの話にとって本質的な部分ではない

要するに誰かがオレオレ仕様決めるだけか
何の意味があるのやら

要するに
マークアップ良いじゃん。使いたい。メタデータあるし。
マークアップを解釈できるソフトで設定ファイルを管理しよう。
これを標準化しよう。ってことだろ。

こんなゆるい、どこまでも意味ない標準もないし、マークアップ縛りってだけの意味のない制限。

理解してほしい文章書くなら後出しジャンケンやめて、標準化したい仕様を書かないとなんにも伝わらん。

実装出すと、仕様出す、コンセプト出すが酔い順番で
コンセプトが誰にも理解してもらえない時点でどうでもいい話だな

>>216
何の意味って、最初に言ったとおり、
世の中はXMLの使い方を間違ったよなーって話をしてるだけ

>>217
標準化しようじゃなくて
世の中はXMLの使い方を間違ったよなーって話をしてるだけ

>>218
仕様を書く必要はないよ
世の中はXMLの使い方を間違ったよなーって話をしてるだけ

>>219
世の中はXMLの使い方を間違ったよなーって話をしてるだけ

お前が間違ってると主張する意味がわからんし
オレオレ正しい正しい使い方もわからん

まあガリレオ並みの人物なら死後にでもやっぱり世間が間違ってた、あいつは凄い！ってなるやろﾊﾅﾎｼﾞｰ

特定目的のXMLと専用ツールを作っただけだな

だから最初からそう言ってる。

XML設定ファイルは、アプリが個々に要素を定義するんじゃなくて
共通の仕様を作るべきだったと

そうすれば設定ツールは汎用のものを別に開発できて、
全てのXML設定ファイルをそのツールで設定でき
開発者も独自の設定ツールを作ることがなくて楽になってたんだよ。

GUI大嫌いって開発者でも、XML設定ファイルにするだけで
テキストエディタでも設定できるし、設定ツールでも設定できるようになってた
さらに作り込めば使いやすいUIを作れるし、多言語化もできてた

だから間違った方向に進んだよなーって思ってるわけだよ。

特定目的設定XMLで表現できない項目が出てきたらどうすんだ

>>227
> 特定目的設定XMLで表現できない項目が出てきたらどうすんだ
結論を先にいうとそういうのはないと思ってる

設定のしやすさは別として（後述するがこれは解決できる問題）
どんな設定であっても、キーとバリューのリストで設定できる
例えば、Firefoxのabout:config の例
　設定名: devtools.performance.timeline.hidden-markers
　型: 文字列
　値: ["Composite","CompositeForwardTransaction"] (JSON文字列かな？）

このような単純なキーとバリューのリストで保存されている。
これを見る限り、型としては最低限、文字列、整数値、真偽値 があれば必要十分なのだろう
まあJSON文字列とか卑怯な物使ってるからねｗ

もう少し便利にするならば、レジストリを参考して「複数行文字列」「変数展開が可能な文字列」や
キーバリューのリスト型みたいなものがあるといいだろう

で、開発の初期段階であれば、どんなに複雑な項目であっても
最悪JSON形式の文字列でテキストエディタで保存すればOKということ。
JSON設定ファイルなんてものがあるんだから、それぐらい苦じゃないだろう？ｗ

でも、設定のしやすさの問題が残っている。エンドユーザーにとってはJSON文字列で設定するのは大変。
そこで出てくるのが・・・というかもったいぶって言うほどのことではなくウェブが
すでにその問題を解決してる。CSSとJavaScriptでインターフェースを作ればいい。
そしてその値をフォームにマッピングする（例えばJSON形式で保存）

当然外部CSSとJavaScriptを使うため、設定ファイル自体はシンプルな状態を保つことができるし、
テキストエディタで編集したい人はそのまま編集できる。
それでいて設定ファイルをシームレスにユーザーインターフェースへとつなげることができる。

ウェブ技術の応用だからUIを作れる人は多いだろうし、なによりUIの作り込みは後からやれるから開発者の負担も減る

何でも設定できる汎用フォーマットに何でも設定できる汎用GUIという
ありとあらゆる機能を詰め込んだ膨大な仕様、実装を要求してることに気が付かないのか

>>229
ぜんぜん？　だって>>224を見てよ。
タグは使い方を変えただけ。本質的には今の使い方と変わらない
今までと同じようにテストエディタで編集できる

それに加えて汎用の設定ツールの開発が可能になる。
設定ツールの仕様がブラウザ並みに大変になる思うかもしれないが、
CSSやJavaScriptはオプショナルに過ぎない。搭載は必須ではない。

ネスケ4とかガラケーやテキストブラウザレベルのものがあれば
設定ツールとして機能する。膨大でもなんでもない。

どうせ今だって複雑な項目をテキストエディタで編集してるんだろ？
ならそこだけ諦めて <textarea>で編集すればいいだけだよ。

そして将来高機能な設定ツールが登場すれば、CSSとJavaScriptで
リッチなUIが使えるようになるし、それがでるまでは
テキストエディタやテキストブラウザ等で設定できる

そして設定ツールは汎用なので独立して開発できる。
なにかアプリを作ったときエンドユーザーが簡単に使えるようにと
アプリ開発者がオリジナルの設定ツールを作る必要はないわけだ。

重要なのは、テキストエディタで編集するのなら、
今のXML設定ファイルとほぼ同じ使い勝手でありながら、
将来的に拡張していけるということ、
今よりも悪くなっているところがなにもない

相当頭悪そうでまともにプログラム書いたこと無さそうなのがわかるので
なんか実装見せてくれたら誰か相手してくれると思うよ

一言悪口を言わないと気がすまないようだなｗ

何かわからなかったら言えば説明するし、
わかったなら、そのことについてコメントしろよ。
なんで書いてあることをいつも見なかったことにして悪口だけ言うんだ？

お前の言うことには中身がない。
頭悪そうに見えるのはお前の方だよ

あなた人の指摘が理解できないでトンチンカンな持論くりかえすだけだからね
だからこれ以上なにか言いたきゃ実装出せば

人の指摘ってどれのこと？

一連のXML、HTML君の言い分をまとめれば矛盾だらけだけど、矛盾を指摘するのがだるいから意味のあることだけまとめるね。
・マークアップ言語を使って設定アプリを作れる。xmlは間違った進化してるけど、それはxmlの仕様を変えれば問題ない。
ってことだ。マークアップも一応プログラミング言語だからPC上でできることは何でもできる。っていうだけのことでしょ。

つまりおまえの言ってる標準は言語を使えばアプリを作れるってPCの誰でも知ってる標準にXMLと設定アプリを加えただけなんだが、
それ以上になにかあるのか？っていうこと。

>>123から始まってるxml君の言いたいことはよくわからんが、
メタ情報の標準化はxmlに限らずオントロジーの作法を知らないからxmlの仕様がーとなるんだろ。
メタ情報を標準化しなくてもオントロジーを定義してrdfの仕様に沿えばメタ情報の解釈はできるんだけど知ってるのかな。
膨大なアプリじゃないと言い切るならどんなブラウザでもそのくらいはできるし大丈夫だよね。

>>236
お前がわかってないじゃんｗ

XMLは何の略か知ってる？ eXtensible Markup Languag
日本語にすると「拡張可能なマークアップ言語」
「拡張されたマークアップ言語」ではないんだよ。

拡張可能が意味する所は、拡張して使いましょうってこと。
XMLの仕様を変える？XMLの仕様のどこが問題なんだ？

ODFなど様々なXMLベースの仕様が作れるほど拡張可能な素晴らしいマークアップ言語だろ
ただ世の中XMLを間違った拡張をした独自の設定ファイル形式が多いってだけ

それはXMLの仕様や進化とは関係ない。そもそもXMLの仕様はシンプルではずっと前から
安定していて、仕様を変える必要性もないほど柔軟で拡張可能に作られている
俺はXMLの仕様自体には文句をつけていない。アプリ独自の拡張方法に文句をつけてる

俺が言ってる意味ちゃんと理解できてる？XMLがどういうものかもわかってないでしょ？
君どうも知識が浅いよ。具体的じゃなくてどうとでも取れるようなことしか言ってない。


> マークアップも一応プログラミング言語だから

ぜんぜん違う。チューリング完全であることはプログラミング言語に要求されることの一つだが、
マークアップ言語はチューリング完全ではない
そういうポロッと素人レベルのことを漏らすから、知識浅いとわかる

> PC上でできることは何でもできる。っていうだけのことでしょ。
そんな意味のないことは一言も言ってない。お前が理解してない証拠。
（俺が言ってることを理解出来ないが）きっと誰でもわかるようなことを言ってる違いないと
お前が思って、誰でもわかるようなことを言ってる例として出しただけでしょ？

>>237
何が言いたいの？

俺はXMLベースの設定ファイルの多くが間違った拡張をしてると言ってるだけ？

で、お前は？オントロジー？
XMLベースじゃなくても、頑張ればなんでもできるって
一般的な話をしてるだけ？

俺はそんな話はしてないよね。

変な所にはてながついちゃったｗ

俺はXMLベースの設定ファイルの多くが間違った拡張をしてると言ってるだけ

俺は今の現実を批判してるのであって、
お前みたいに存在しないものを作るなんて話はしてない
架空の世界の話はしてないんだよ

> 膨大なアプリじゃないと言い切るならどんなブラウザでもそのくらいはできるし大丈夫だよね。

XMLベースならテキストエディタで変更できるんでー
大丈夫ですよーｗ

現実にはお前の理想とする設定ツール実装は存在しないんだろ？
それは架空の話と言うんだよ

だからテキストエディタで設定できるって（笑）
何度も言わせんなや

ぼくのかんがえたさいきょうの設定はテキストエディタで何でも設定できるんだー！って何が凄い発想なのか

>>240
>俺はXMLベースの設定ファイルの多くが間違った拡張をしてると言ってるだけ
ここにみんなが突っ込んでるんじゃなくて（間違った拡張も主観的な主張だけど。）、
>XML設定ファイルは、アプリが個々に要素を定義するんじゃなくて
>共通の仕様を作るべきだったと
それは作りたい人が作ればよろしい。みんな使わないと思うが。

自由に拡張できるといい、他人の拡張を間違っているといい、しまいには共通の仕様を作れと言う。
文脈に矛盾が生じてるのに気がついていない。

ぼくのかんがえたさいきょうの汎用設定用XMLスキーマを策定すれば素晴らしい未来が訪れる、
ということらしいがスキーマの汎用性を高めれば仕様も実装も爆発し
制限すれば不便になりさいきょうでは無くなりそうだ。
ぼくちんの妄想の中ではいい感じに出来上がってるらしいのでサンプル実装はよ

>>246
それの何処が矛盾してるんだ？

・XMLは拡張可能なマークアップ言語
・いろんな人が拡張してるが、アプリ独自の設定ファイルは
間違った拡張をされている
・設定ファイル用のXML拡張の仕様を作れ

やっぱり何も間違ってないな。
お前がXMLを理解してないから、矛盾に見えるんだろう？

>>247

>>220に書いた

XMLの拡張とは何を意味してるのか？

>>248
アプリ独自の設定ファイルがxmlで独自拡張が間違っている例を上げてください。
そしてそれがどのように間違っているかを示してください。

もしかしてスキーマを作ることを「XMLの拡張」なのかね

>>252
それがわかるならオントロジーもrdfも理解しても良さそうなんだが。

>>250
XMLの拡張の意味も知らないで突っかかってきてるのかよｗ

XMLの言葉の意味の通り
「eXtensible Markup Language」
「拡張可能なマークアップ言語」

XMLの拡張とは何を意味しているかは、
XMLの意味を調べればわかる（すでにこのスレに書いた）

俺が書いたことが信用出来ないならググれ、と言おうと思ったが、
仮にググったら、良い説明があったので以下を読め
http://www.atmarkit.co.jp/aig/01xml/xml.html

↑にはどういう勘違いがあるかも書いてあるから、
XMLが本当はどういうものかがわかるぞｗ

>>251
すでにこのスレに書いた

>>253
その話はしてないと言ったはずだが？

>>254
具体的に拡張するとは何を定義するか説明できるの？

>>257
それ俺が質問してるんだわ

XMLは何の略か知ってる？ eXtensible Markup Languag
日本語にすると「拡張可能なマークアップ言語」
「拡張されたマークアップ言語」ではないんだよ。

おれがXMLとはなにか知ってる？と聞いてるのに
聞き返してるのは知らないってことなんかね？

いつものことだがこういう輩は自分で説明すると
（どこがも言わずに）それは違う。やっぱりわかってないって
いうだけで逃げるので、ソースを出すことにしてる

https://support.office.com/ja-jp/article/%E5%88%9D%E3%82%81%E3%81%A6%E3%81%AE-xml-a87d234d-4c2e-4409-9cbc-45e4eb857d44

XML タグを利用することで、自分が見ているデータの種類がはっきりわかります。
たとえば、それが猫に関するデータであることがわかります。猫の名前や年齢などを簡単に見つけられます。
ほとんどすべてのデータ構造を定義するタグを作成できることから、XML は "extensible (拡張可能)" と呼ばれています。

具体的な拡張の固有名詞挙げられる？

すでに何度も書いてる。このスレを検索しろ

というか、調べればわかることをわざわざ書かせるのは
揚げ足取り目的だってわかってるからさぁ

http://park18.wakwak.com/~little-box/xml_basic/1-002.htm

>>238
なんかを見るとODFが「XMLの拡張」の例だとおもいこんでるようだけどあってるのかな？

ODFを展開して出てくるXMLそれぞれが
XMLを拡張（独自タグを定義したもの）になってる
で、揚げ足取りは？ｗ

>>253
メタフォーマットであるXMLのフォーマットを決める、スキーマを定義する、ことにすぎないことを
XMLの拡張なるものと思い込んでいて
ぼくのかんがえたさいきょうの設定ファイルに適したオレオレスキーマを定義することを設定向けXML拡張と呼んでるらしい。

スキーマを定めることでフォーマットが固定されるのに
「拡張」という言葉を使うことでなんでも自在な機能が持てると
妄想も拡張しているようだ。

？

メタフォーマットであるXMLのフォーマットを決める、スキーマを定義する、ことにすぎないことを
XMLの拡張というんですよ？

なんだろう？最もすごいものじゃないと拡張と言っちゃいけないとでも思ってたの？
へんだなぁ。俺じゃなくて
XML（eXtensible Markup Language）という名前をつけた人に
言うべきことでしょう？

XMLは拡張可能なマークアップ言語ですよ？

なんでも自在な機能がもてるとか誰が言ったんですかねぇ。

俺「XMLとは拡張可能なマークアップ言語です」

馬鹿「拡張といったな？」
俺「言ったけど？」

馬鹿「ぼくのかんがえたさいきょうの設定ファイルってことだな？」
俺「（そんなことなにもいってないけど？）」

馬鹿「スキーマを定義することにすぎないことをXMLの拡張なるものと思い込んでるな？」
俺「（そのとおりだろ？）

馬鹿「XMLの拡張というものは・・・・そのとおりだ」
俺「（思い込んみは間違いだ！って言うんじゃないのかよ？）」

馬鹿「拡張という言葉を使うと自在な機能を持ってると思ってるな？」
俺「（何言い出してるんだろうこいつ？）」

馬鹿「妄想も拡張しているようだ。」
俺「（それ言い出したの全部お前じゃん）

あー、>>267が言いたいことがわかったわｗ

XMLを拡張して作るXMLベースの設定ファイルのスキーマ
今のアプリの設定ファイルが間違ってると言ったろ？

>>267はその間違ったXMLベースの設定ファイルに
基づいて発言してる。

つまり>>267は、アプリケーション固有のスキーマを作る話をしてるから
スキーマを定義すると、アプリケーションを機能追加（拡張？）できなくなると言ってる。

あほやな。いや、大部分のXMLベースの設定ファイルは
アプリケーション固有のスキーマを作ってるから、
>>267も含めてみんな間違ってるなーっていうことか

汎用のXML設定ファイルっていうのは（どういうものかは上に書いたので探せ）
アプリケーション固有ではなく、スキーマを定めたところで、
アプリケーションの機能追加を妨げるものじゃない

固定するのは設定ファイルのスキーマだけ
そのスキーマにはアプリケーション固有のスキーマ定義はないから
アプリケーションは自由に「拡張」できる。

だいたいHTMLを参考にしてる点で気づかんかな？
HTMLなんかスキーマが定められてフォーマットが固定されてるのに
いろんなサイトやウェブサービスが作れるだろと

自在な機能を持つ能力は無いが任意のアプリ固有の機能追加できる

アプリ固有のスキーマは無いので好き勝手定義できるけど汎用の設定ツールを作成して設定できる

この短い中でこんな滅茶苦茶なこと言う奴も珍しいなあ

>>273
えとさぁ、お前、設定ファイルの話とアプリの機能をごっちゃにするの止めたら？
馬鹿らしい。

設定ファイルの形式なんて、レジストリとか見れば、固定でいいってわかるだろ。
固定っていうのは（最低限）キーとバリューの組み合わせが保存できればいいってこと

どうせお前は馬鹿だから、キーの名前を固定にするのと
ごっちゃにしてるんだろうけどなｗ

ともかく、HTMLのフォームが、inputとselectとtextareaとグループ分け程度の
少ないスキーマ定義で、実際にいろんなウェブサービスに
対応できてるんだから、現実を受け入れようね？