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

エディタは、多くの人は、本格的なプログラミングのために使ってるわけではなく、
設定ファイルやスクリプトファイルの簡単な修正程度に使っているのかもしれない。
だから、使用者の数で言えばvimが多くても、ちゃんとしたプログラムに使ってい
るとは限らない。

>>107
生産性考えなくて良いからな。

>>107
出産後にすぐ死ぬ確率は劇的に減ってるはず
生殖についても人工妊娠、中絶や栄養状態がよくなったことによる妊娠しやすさの向上もある
さらには男女の出会いの多様化で近親が減り、例えば過去にはほぼ例がなかった国際結婚が増えて強靭な種となっている

>>116
＞エディタは、多くの人は、本格的なプログラミングのために使ってるわけではなく、

これはその通りやけど

＞設定ファイルやスクリプトファイルの簡単な修正程度に使っているのかもしれない。

これだって少数派やろ
いまどき設定ファイルなんか直書きする人がどんだけおるんや
「設定ファイルを勝手に書き換えないでください」と注意書きしてあるソフトのほうが多いくらいや

テキストエディタの使い途の最大多数は文章執筆やろ

いや、Linuxの世界では設定ファイルは
テキストエディタで修正するんや

だから XML 方式が流行らない。

XMLって何がうれしいんだ？
Markdown は適当に使うが。

設定ファイルのXML方式はやり方を間違えたからな。
そもそもXMLというだけではタグの種類は定義されておらず
タグと属性を使ってデータを表現しますっていう縛りにすぎない。

例えばOpenOfficeとかはXMLをベースにした
ODFというフォーマットを採用している。
このフォーマットに相当するものが設定ファイルになかった

標準化せずに各アプリがそれぞれ独自のフォーマットを作成してしまった。
そのせいでXMLを使いながらも、汎用の設定変更アプリが出現することはなかった

>>120
なぜGUIが流行らないの？
親切なフリーソフト作者が作ってくれそうなもんなのに
なかなかそういうのないよね

そういうの求める層はLinuxなんか使わないから

>>123
XML ってそういうものじゃないの？
タグの種類定義なんかしたら XML 違うだろ。

偏見かもだけれどXMLとか文系的で凄く面倒くさい。
定義ってよりもルール作りで出来てるイメージ。

独自フォーマットは、一応は過去の流儀を踏襲してたりしてるのは順応できるかなだな。

クラスの内容をそのまま書き出すのとかすごい便利だけどな。
エディタでいじることが前提になってるから面倒に思うんじゃないの？

メタフォーマットであることを理解してない>>123

>>128
「クラスの内容をそのまま書き出す」というのは、何を使えば出来るの？

うんこブリブリ

変に規格化された煩雑なXMLより、ドキュメント付きのJSONのほうが楽な気はする。
>>128の「クラスの内容をそのまま書き出す」はXML形式でオブジェクトを吐き出すことを言ってるんじゃないか？
文章作成はtexでいいよｗ

GUIの設定画面はないわけじゃないよね？
apt-get upgradeしてたらたまにGUIの設定画面出てくるし

>>130
.NET のシリアライズの話なんだけど、知らないならいいよ。

「GUIの方がユーザーフレンドリー！」とか勘違いしちゃってる人は、メールもお絵描きで作ってるの？

お前はマウスとキーボードの使い分けもできないのか？

>>135
Linux はこういう基地外が多いのがなあ……

>>137
内容に反論出来ない奴はWindows触って欲しくないなあ・・・

>>138
unko

テキスト入力とCUIの区別がつかない無知無能なLinux信者が存在するらしいｗ

あ、Linux信者じゃ珍しくないか、そういう無知無能は。

>>26
開発環境が遅れた元凶だな。

能書きと思想だけ一丁前に垂れて、OSすらまともに作れない無能なFSFというカルト団体がリヌス・トーバルスの批判しかしないから遅れたんだよ。

LinuxではなくGNU/Linux？
何を偉そうに言ってんのかw
どっちでも良いだろ。

OSを作れないカルト団体が巨額な寄付いや御布施で成り立っている思想も見た目もメタボ野郎の集まりに過ぎん。

あと、GPLv3だな。

そもそもイチャモンスレだし。

40年前から同じなのか、すげえ安定してるな

40年前に「とりあえず動く」になった状態から、誰も弄れないってことじゃんｗ

>>143
停滞してるの間違いだろ

このスレ、一時期プログラム板やLinux板でやたらとGPLを批判してた(仕事がなくなるのが気に食わないらしい)
奴と同一人物のような気がするな。口調や改行の仕方が似てる気がする。

【オープンソース】Linuxの思想【GPL】
http://mao.5ch.net/test/read.cgi/linux/1413704137/

↑のスレのID赤めの奴ね。

こんな記事が出たのがもう10年以上前か
結局立て直せず衰退していったな

GPL3で対立が深まるオープンソースコミュニティー--協調か分裂か - CNET Japan
https://japan.cnet.com/article/20270448/

　「公平性の観点からはGPL3はもはやその機能を果たしていない。その内容はまったく扇動的であり、
FSFの過激な方針にしか寄与しない。GPL2は多くの個人に受け入れられ、
一度説明すれば多くの企業からも支持を得られる優れたバランスを持っていたが、
GPL3にはそれがない」--Linus Torvalds、Linuxファウンダー

やっぱ船頭多くしてってヤツじゃないのかね。

まわりからチヤホヤされたいんだろ、メタボのおっさんが。

僕の知り合いの知り合いができた副業情報ドットコム
関心がある人だけ見てください。
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

C4U3V

emacsもかなり使いにくいのに偉そうな事言ってた。

新人のころの上司がvi信者で最初の１年プログラムは全てviで書かされた。今考えるとイジメだよな。その後、windowsプログラミングでVC使ったとき、死ぬほど感激した。
GUIで直感的、makeも書かなくて良い、MFCでクラスも揃ってる、作業効率が果てしなく違った。
まあ、viのほうがキーボード叩くから仕事してるように見えるって利点ばある。

viのいいところは環境気にせずにssh越しにテキスト編集できるところだから新人に教えるの間違ってないけど、（いざというときに使える。）
その上司はやりすぎ。

vimにプラグインで補完機能とか入れてるけど、ideの方がいろいろ捗るのかな？

普段vim使ってても面白半分でviインストールして使ってみると軽く死ねる

ideは開発環境をサーバーを汚さずに整えられるし、インストールも楽だし、使い方も楽なところかな。
でも勉強にはならないかもね。>>155僕はnvim使ってるけど、最近のディストリはviコマンドがvimになってない？
archとかはもちろん素のviなんだけどさ。

viコマンドがvimになってたらそれは只のvimだろ

freeBSDはただのviだったような、、それか、そもそも入ってないんだっけ？

autotoolsは確かにしんどい。
今だに使ってるソースツリーは塩漬けされてるだけの感はあるな。
LLVMはconfigureからcmakeに完全移行してたっけな。
cmakeのが階層化できる分、見る領域を絞れるから楽かな。

新しいビルドツールでもリンクの段階だけ数ギガバイトのメモリを必要する類の
ものはなんとかして欲しいな。

【ツイッター】小学2年生の道徳教科書 ポンタ君の「ご褒美がなくても仕事を続けたい」が物議 ブラック企業を肯定することにならないか★3
https://asahi.5ch.net/test/read.cgi/newsplus/1527658126/

ポンタくんがご褒美を貰わないでお仕事をするおかげで
ご褒美をもらってお仕事をしている他の動物さんたちは批判されるようになりました
ポンタくんはご褒美がなくても働いているのにお前たちはずるいぞ！

だって、被災地で空き巣に入って十分儲かったから、安いご褒美なんていらない！
被災地でまた仕事しながら物色したい

とポンタ君

【道徳の教科書】
ストールマン君は、
「プログラミングは楽しいんだから無償でやればいい。」
と言いましたとさ。仕事とはお金のためにやるわけではないのですね。

105名無しさん＠１周年2018/05/30(水) 15:07:11.46ID:Y6aUHfuN0
＞最後に、「だって、」以下にご褒美をもらわなくても仕事を続ける理由について、授業中に児童らに書いてもらう内容になっている。

ご褒美を貰うべき理由を書いたら0点で
より社畜的な理由を書くほど高い点数なんだろうな
この国の道徳教育は狂ってる

117名無しさん＠１周年2018/05/30(水) 15:10:52.11ID:9/ern7d+0>>157
無償で働きたいというのは構わんけど、ポンタくんは何で生計を立てているんだろう？
資産や不労所得があるのならいいけど。

人間は何も食べなくてもありがとうを食べれば生きていけるんです
byワタミ

51名無しさん＠１周年2018/05/30(水) 11:38:11.31ID:1aWoC9+D0>>74
>>19
たしか、だっての理由がみんなの喜ぶ心が生きがいだからって言うのが
正しい答えだって言っていた　奉仕の心らしいが

コレ、二人ぶっ殺したワタミも全くおんなじこと言ってるんだよな

無料ウェアをただで使ってるだけのお前らが心配してるのが滑稽だな
だったらたまには寄付してやれよ

linux使いならお前にも、ないなら作れのDIY精神が根底にあるだろ！
目の前のキーボードとgccは何のためにあると思ってんだ！

>>168
gccの存在理由： ストールマンの売名行為

亀レスだけどカーネルのビルドなんてめっちゃ簡単だろ
難易度☆一つレベル
あんなんビルドじゃなくてコンパイルだね
Apacheやphp,perl,pythonのビルドと同じレベルだよ
ちな、gccのビルドが☆2つ、pen4で10時間くらいかかるqtやVirtualBoxのビルドが☆3つ
もっと☆彡多いのもある

かかる時間で☆が増える評価軸すか

そりゃわかってれば簡単だろうよ。
そこまでの努力はすごいと思うけどさ。

age

age

あげ

そういうところがあるから潰しは効く。
パッケージ管理を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とグループ分け程度の
少ないスキーマ定義で、実際にいろんなウェブサービスに
対応できてるんだから、現実を受け入れようね？

どうも齟齬があるなあと思ったら「設定を記録するのに必要なスキーマの」機能の話を
アプリの機能と勝手に思い込んでるわけね

オレオレさいきょうキーバリューだかなんだかしらないXMLを作成したいって話か？そんな低レベルの話？
オレオレ設定XMLじゃ困る人は切り捨てりゃいいなら楽だよなあ

キーバリューの話しかできないならなんでこいつはXMLにこだわってるのか謎

また>>220をコピペすればいい？

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

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

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

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

>>275
俺は最初から、設定を記録するのに必要なスキーマの話しかしてない
世の中のアプリは、アプリ固有のオレオレスキーマを作成して
単に編集しにくいだけで、XMLを使用する意味をなくしてしまってる。

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

キーバリューならCSVで十分だ運動すれば？
あと多彩なWebサービスの話はinputとかフォームに関係ない部分だから
わかってないことは使わない方がいいぞ（あとHTMLはXMLじゃないのはいいのだろうか）

そして馬鹿は極端だから、
「固定っていうのは（最低限）キーとバリューの組み合わせが保存できればいいってこと」

と書いていても、（最低限）の部分を
もうすっかり忘れているｗｗｗ

>>279
設定を記録するXMLと他のデータを記録するXMLを混合できるXMLなんて誰も話してないと思うがね
ところで設定ファイルの設計ミスした具体的アプリ名とかないの？

>>281
最高値はどこまで機能持たせるの？

>>280
CSVだったら入力インターフェースが作れない
設定の値しか書いてないから、設定が取りうる値などがわからない
例えば、sambaのmap to guestという項目は「Never」「Bad User」「Bad Password」の
いずれかの値を入れることができるが、そのことが設定ファイルには書かれていない
（コメントとして書かれている場合があるかもしれないぐらい）

設定ファイルでありながらHTMLのフォームと同じような
スキーマを採用することで、設定ツールを作ることが可能になる

あー、何度言えば良いんだろうｗ

スキーマにはアプリ固有のものは含まれないから、
HTMLが、まさにHTMLがそうしているように、
汎用の設定ツールで設定が可能になる。

アプリ開発者は単に設定ファイルにHTMLフォームライクな
XMLを拡張して作った汎用のXML設定ファイルを採用するだけ
アプリ開発者は設定ツールを作ること無く、
初心者は汎用の設定ツールを使って設定できるようになる。

何度言えば理解しますかね？

>>283

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

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

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

今の設定ファイルはコメントで、設定方法が書かれているが、
まあこれがまさにテキストエディタ用のインターフェースなわけだが

設定値のみ書かれていればいいならコメントは要らない
コメントはまさにテキストエディタで編集する人が
読むためのもの

でも設定ファイルのコメントは英語でしか書かれていない。翻訳の仕組みがないからだ。
あるとすれば設定ファイルにずらーっと何カ国後もコメント書くぐらいだなｗ

こういう問題も、まともなXML設定ファイルを作れば多言語対応も可能になるだろう

HTMLがブラウザが設定入力インターフェイスだというなら
ExcelはCSVの入力インターフェイスだと主張できるなあ

しかもHTMLは選択肢がつくれる

HTMLがブラウザが設定入力インターフェイスだというなら
ExcelはCSVの入力インターフェイスだと主張できるなあ

しかもHTMLは選択肢がつくれると言ってんのはデータはどこに入れるの？
そしてお前のさいき

>>287
主張できるが？

だからなに？

>>288
上に例を書いた。探せ

HTMLがブラウザが設定入力インターフェイスだというなら
ExcelはCSVの入力インターフェイスだと主張できるなあ

しかもHTMLは選択肢がつくれると言ってんのはデータはどこに入れるの？
そしてお前のさいきょうXMLで表現できない設定記述機能要望（アプリの機能じゃねえぞ）はどうするの？

例えば、sambaのmap to guestという項目は「Never」「Bad User」「Bad Password」の
いずれかの値を入れることができるが、そのことが設定ファイルには書かれていない
いやコメントでこう書かれているかもしれない

# ○○をするための項目です（という英語）
# 「Never」「Bad User」「Bad Password」のいずれかの値を入れられます。
# デフォルトは「Never」です。
map to guest=Never

というものが書いてあってもここから設定ツールは作れない
CSV形式でも設定ツールは作れない。

HTMLのフォームライクなXML設定ファイルにすれば設定ツールを作れる

<label for="map-to-guest" >"○○をするための項目です（という英語）</label>
<select id="map-to-guest" name="map to guest">
　<option selected default>Never</option>
　<option>Bad User</option>
　<option>Bad Password</option>
</select>

この中には設定値、設定の候補、デフォルト値が含まれている。
今までどおりテキストエディタで編集もできる

> そしてお前のさいきょうXMLで表現できない設定記述機能要望（アプリの機能じゃねえぞ）はどうするの？

ない

>>289
CSVだったら入力インターフェイスが作れないという文章どこに行った

>>294
あ、その事（笑）
ExcelでCSV編集しても、値しか入れられないだろ。
取りうる値なんかわからない

>>293
えっ？世の中数百万以上のアプリがあってこれからも生み出されるのになんで無いって言えるの？

>>296
アプリの機能じゃねえぞ

どんなアプリが増えようが、設定はすべて
キーとバリューだけで表現できる
（便利だと思うならその他の形式をいくつか増やしてもいいが）

ほんとなぁ、設定の値の話をしてるのに
結局、ID:3OE6BV46 自身が、アプリの種類が増えたらどうするの？
なんて言ってるんだもんなぁｗ
アプリの機能を気にしてるのはお前じゃん

>>292
それどこかのアホが
<option selected default>ほげ</option>
とか書くのどーやって防ぐの？

>>297
アプリが未来永劫設定項目の記録表現としてさいきょうの設定XMLでは
不十分だと言うとこは無いとどうやって証明したのですか？

>>299
え？テキストエディタを使った場合の話？

アプリ独自にテキスト形式で、map to guestをmap to guestoooooと書くのを防ぐ方法あるんですか？
CSV形式で、以下同文


テキストエディタを使っている以上不可能でしょｗ
そんなの当たり前。

だから設定ツールが重要になるわけですが？
でもアプリ独自のテキスト形式やcsv形式だと、その設定ツールを
アプリごとに作らなければいけない
あぁ、無駄無駄。時間の無駄


HTMLのフォームライクなXML設定ファイルなら、
その設定ツールで間違った値を設定することはありませんね。
そして汎用で使えるから、アプリ開発者の負担が減りますね。

今のXMLはアプリ固有のスキーマになって、汎用の設定ツールなんか
作れないから、世の中はXMLの使い方を間違ったよなーって話をしてるだけ

設定記述機能の話しかしてねえのに
アプリ本体機能と勘違いしてる馬鹿がいるんだと
必死で藁人形打つのやめろよなあ

>>300
バイナリデータを含む全てのデータは、
エンコードすることで、テキスト文字列で表現可能だから
（必ずしもそうしろと言ってるわけじゃない）

>>303
証明はあるのかと言ったんですよ

>>302
それお前なｗ

アプリがどんな機能を持ってようが
設定は（最低限）キーとバリューの組み合わせが保存できれば十分

>>304
証明どころか実装がある。

Base64はどんなバイナリデータであっても
テキスト文字列に変換できる

>>305
設定表現にはキーバリューで必要十分なのか他に表現が必要なのか
他に必要なら必要十分な範囲は決められるのか
決められないのか適当に逃げ回るなよ

>>307
頭が悪いなｗ

バイナリデータをテキスト文字列に変換できるのなら、
お前が不安に思ってる、どんな表現であっても
単一のテキスト文字列に変換できるってことだよ

>>306
お前のさいきょう設定XMLで全てのアプリの設定記述要望を満たす
証明はあるのかと聞いたんだよ
誰かがバイナリのアスキー表現の話してるんだよ。答えられないのわかるけどさ。

JSONなんか、文字列、数値、真偽値、配列、連想配列
たったこれだけのもので、どんな複雑なものでも表現できるからな。

一体何が表現不可能だと思ってるのか
わけがわからない

>>309
やっぱりさ、お前
まーた、アプリ固有のスキーマの話してるだろｗ

アプリ固有のものなんて無いんだから、
どんなアプリのものだって対応可能

いい加減アプリの機能と設定をごっちゃにするの止めたら？

>>310
質問はお前のさいきょう設定XMLで全てのアプリの
設定記述機能を満たす証明はあるのか？です
関係ない話に逃げるのはやめましょう

>>311
そういう勘違いしてる人に仕立て上げたい気持ちはわかる（笑）

>>312
なんで実装があるのに証明にこだわってるの？

Base64でエンコードすれば、どんな設定だって
文字列で保存できるじゃん

>>314
テキストファイルとテキストエディタがあればどんな設定でも記述できるという主張かね？

元の証明はできないということだね。理解できてなさそだけど。

>>313
だって>>312でまた「全ての」アプリの設定記述を満たすものがあるのかとか言ってるじゃん

つまり「一部の」アプリ設定記述を満たすものはあるって
納得してるんでしょ？

そして「一部」に含まれない、もっと別の高度なアプリの機能の
設定記述を満たすものはあるのかー！！！って
アプリの機能を気にしてるじゃんｗ

>>315
> テキストファイルとテキストエディタがあればどんな設定でも記述できるという主張かね？

そりゃそうだろうね
使いやすいかどうかは別として

最初からそう言ってるんだが。
どんな設定だろうが、テキストに変換できる以上
テキストエディタで編集は可能。

ただし便利なインターフェースを作るためには
設定値だけでは無理。

メタ情報が必要。XML設定ファイルであれば
そういうメタ情報を入れることはたやすいが、
世の中間違って使い方をして、独自のXML設定ファイルばっかり作るから
汎用の設定ツールを作ることができない

今日はあと一時間切ったぞ。
100レスまであと45もあるじゃないか

>>228ですでに書いたこと（わざとなのか知らんが、すでに答えたことを繰り返されるのは面倒だ）

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

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

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

もう少し便利にするならば、レジストリを参考して「複数行文字列」「変数展開が可能な文字列」や
キーバリューのリスト型みたいなものがあるといいだろう
で、開発の初期段階であれば、どんなに複雑な項目であっても
最悪JSON形式の文字列でテキストエディタで保存すればOKということ。
JSON設定ファイルなんてものがあるんだから、それぐらい苦じゃないだろう？ｗ

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

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

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

俺は面倒だから、基本的にIDを見てないんだが、
みてみたら同じやつじゃんｗ

なんで繰り返しおんなじ質問するのかね？

言い方を変えてもいいな

どんな荒唐無稽な設定データを想像してるのか知らんが、
テキスト形式の設定ファイルでは設定できないデータが
あるというのなら諦めればいいだけだろう。

バイナリデータでさえBase64で保存できるというのに
それがどんなものが設定ファイルに書けないのか、
俺にはわからんが、それは諦めるという方向でいい。

で、諦めなければならないもの例をあげてくれ。
俺には全く思いつかない。まあ無いんだろう。

そういや今はCSSファイル（当然テキスト形式）に
画像データをBase64エンコードして入れられることを思い出した。

おとなしくなったようなので、続き（？）を

汎用のXML設定ファイル形式（おれのかんがえたさいきょうってやつｗ）は、
HTMLのフォームを参考にすれば良いと言ったが、欠点もある

そこはHTMLフォームを厳守しろっとは言ってないので変えればいいだけだが、
リストやハッシュデータの扱いが難しい。もちろんできないわけじゃない。

PHPやRubyはフォームの名前を工夫することでリストやハッシュを表現している

例えばこんな感じだ

<form>
　名前：<input type="text" name="personal[name]">
　住所：<input type="text" name="personal[address]">
　電話：<input type="text" name="personal[telephone]">
</form>

これで少なくともJSONなみの表現力は得られるわけだがやっぱりダサいと思う

<form>
　<fieldset name="personal">
　名前：<input type="text" name="name">
　住所：<input type="text" name="address">
　電話：<input type="text" name="telephone">
　</fieldset>
</form>

こんな感じで直感的な仕様にしたほうが良いだろうな

>>267
こんなひどいストローマン久しぶりに見たわｗｗｗ
「xmlの拡張」の文節はどうとでも解釈できるのに最終的にスキーマを新しく作るってことを「xmlの拡張」と呼ぶらしいぞwwww

普通、「xml（の言語仕様）の拡張」と受け取るよな。

で、間違ったxml使ったアプリの例はいつ出してくれんだろう。
具体的なアプリ名はスレのどこにもなさそうだけど。

ていうか、文章能力なさすぎだろ、間違ったxmlって同じ属性が2つ書かれてるとかぐらいしか思いつかないけど、なにを指してるんだろ。
あとjsonの例は、xmlが文章以外にもデータ記述子として使われることもあるので、設定ファイルに置いてjsonと比較されるのはなんの不思議でもない。

設定ファイルに直接コメント書きたいらしいが、ドキュメント書いてくれればなんの問題もない。
一つのファイルに書くことがそんなに重要ならテキストファイルの中にjson書いて、jsonだけ受け取れば十分だろ。

>>323
まあ全体的に ID:3OE6BV46 は何を言ってるのかよくわからんよ。
わかってないからいろいろごっちゃにして勘違いしてるんだろうさ。

XMLの拡張、なにがいいたかったんだろうね

俺は、XMLは eXtensible Markup Language（拡張可能なマークアップ言語）の
略だと言っただけなんだよね。だからこの文脈では名前に入ってる「拡張可能」の
意味で解釈してもらわないと

XMLを拡張してXML 2.0を作るとか言う話じゃなくて
そもそもがXMLは拡張可能なマークアップ言語として作られたものなんだよって
話をしてるだけなんだが、基本がわかってないからいつもずれてしまって話が通じない。
XMLは言語を記述するための言語とも言われてるね

ってかお前か、いつものキチガイｗ

まーた、わざとらしい間違いしてくるし、

俺が、XMLの間違った使い方といったら、
お前は、XMLの文法ミスのことなんだって
まーた間違えるし、本当に話が通じない

説明済みのことを何度も聞いてくる

> で、間違ったxml使ったアプリの例はいつ出してくれんだろう。
間違ってないXMLベースの設定ファイルを使ってるアプリなんて存在しないよ。

> 設定ファイルに直接コメント書きたいらしいが、
はい、また。そんなこと言ってない。

> ドキュメント書いてくれればなんの問題もない。
ドキュメントは設定ツールとして生かせない

> 一つのファイルに書くことがそんなに重要なら
はい、また、そんな事も言ってない

> テキストファイルの中にjson書いて、jsonだけ受け取れば十分だろ。
jsonでは機能不足だってすでに説明済み

ほんとなーずーっとXMLベースの汎用的なXMLスキーマを作って、
設定ツールで設定するという話をしてるだろうに一体いつになったら
嘘吐くのやめてくれるんだろう？

俺が言ったことにして、話を混乱させてる

こいつの設定XMLでできないことは無いと断言しながら
できないことがあったら諦めろとかどんな神経したら書けるんだろうな

バイナリバイナリってバリューの話だけでデータ構造の話は出てこないのか（笑）

>>327
敵味方の二元論しか受け取れないのやばいけど、レスの内容が理解できてないから勘違いするんだ。
ちゃんと読めよ。

>>330
> こいつの設定XMLでできないことは無いと断言しながら
> できないことがあったら諦めろとかどんな神経したら書けるんだろうな

また、嘘書いてる。
そんなことは一言も言ってません。

もし本当にできないことがあるというのなら諦めるよ？
だからできないことがあるというのなら、言ってみろ
まああるわけないけどね、って書いてるんだ。

>>328
>XMLの間違った使い方
>>248
>アプリ独自の設定ファイルは間違った拡張をされている
表記ゆれが紛らわしいんだが、これらは同じ意味か？文法ミス以外で言語で間違うってなに？
それは主観的な間違いなんじゃないの？間違いと感じただけ？

>>331
> バイナリバイナリってバリューの話だけでデータ構造の話は出てこないのか（笑）
それも>>322で書いた。

いくら俺がいないすきを狙って、嘘をついても、
こうやってばれるんだからいみないよ？

>>334
ほんとお前に日本語の読解力がないのなｗ

道具の間違った使い方だっていってんだろう

設定ファイルをXMLにする意味がないから、間違った使い方

>>336
「XMLの間違った使い方」って書いてたのを「道具の間違った使い方」って書いてたことにするのか？
XMLは物理的な道具じゃないからXMLをなにかの道具に例えたんだな。さあ、教えてくれ、XMLはなんの道具なんだい？
ちなみに「道具の間違った使い方」の文節は初めて出てきたよ。びっくりだよ。

>>337
このレスは君のレスかい？
>>919
>HTML風XMLの設定ファイルは開発者が作成するもの
君はXMLを設定ファイルにするのは諦めたってことかい？

アプリの設定ファイルをXMLにされるのはおかしいと思ってたから伝わっているならそれが何よりだよ。

>>339
>>191の間違いだ。

お前らが熱い討論してる間、俺は洪水の電柱が危険だということを知ったから、お前らにも教えといてやるよ
https://gfycat.com/gifs/detail/unacceptableangryfossa
お前らも有事には気をつけろよ

>>338
道具と言われて、物理的なもの限定って思うのか・・・
Officeソフトは道具じゃないんですねーｗ
ほんと日本語のレベルであやしいや

>>339
> >HTML風XMLの設定ファイルは開発者が作成するもの
> 君はXMLを設定ファイルにするのは諦めたってことかい？

HTML風XMLは、XMLだろ・・・
和風ハンバーグはハンバーグじゃないっていう理論か？
日本語のレベルで（ｒｙ

あれでもおかしいぞ〜。
>設定ファイルをXMLにする意味がないから、間違った使い方
って意味なら
>間違った拡張
の拡張の意味が浮いちゃうな〜。拡張はxmlの<拡張可能な>から取ってきたんじゃなかったんだっけ？
表記ゆれが激しくて、それぞれが突っ込まれると微妙に違うことを言ってるから矛盾してきちゃったな〜。

単純に
>アプリ独自の設定ファイルは間違った拡張をされている
>設定ファイルをXMLにする意味がないから、間違った使い方
が同じ意味だと思っているなら文章能力も読解力もないって言われて当然。

普通になにを言ってるかなぞ。せめて訂正とかしてほしい。

>>340
> アプリの設定ファイルをXMLにされるのはおかしいと思ってたから伝わっているならそれが何よりだよ。

別にアプリの設定ファイルがXMLでも問題ない。
ただXMLにするメリットがない使い方ばっかりされてる

他の形式に比べて冗長なのは言うまでもなくわかってること
その冗長さを上回るメリットを見つけていない

汎用的なXML設定ファイルのスキーマ
（HTML風のXML、どういうものかは上の方に具体的に何回も書いた）
を作れば、XML設定ファイルは大きなメリットを得られる

具体的には、汎用の設定ツールで設定可能になる。
アプリ開発者がわざわざ手間ひまかけて設定ツールを作る必要がなくなる。

アプリ開発者はXML設定ファイルを選ぶだけで恩恵が得られる
ユーザーも難解な設定ファイルをテキストエディタで間違えないように
修正する必要がなくなる。GUIから簡単に設定できるようになる
作り込めば、より便利なインターフェースを作ることもできる
それでいながら、初期段階はテキストエディタで簡単に修正することもできる

もう何度同じことを言っただろうか？

xmlくんはなにが言いたいのやらさっぱりわからん。
>>343
officeは文章作成のための道具だろ？
xmlはなんの道具だよ？

>>344
だから「拡張可能」の拡張だって何度も言ってるだろ
そして、お前は自分でXMLをベースとして新しいタグを作ることが
拡張だって理解したはずだよな？

> ODFなど様々なXMLベースの仕様が作れるほど拡張可能な素晴らしいマークアップ言語だろ
> ただ世の中XMLを間違った拡張をした独自の設定ファイル形式が多いってだけ
↑
世の中のアプリは独自でタグを作りまくってるから、それが間違った拡張だと
最初からずーっと書いてある。

>>346
> xmlはなんの道具だよ？

マークアップ言語を作るための道具

拡張可能という意味を持つXMLが可能な
拡張を行って独自のタグ（スキーマ）を作るための道具

いいか！みんな！！xmlくんは「間違い」ってことを
>別にアプリの設定ファイルがXMLでも問題ない。ただXMLにするメリットがない使い方ばっかりされてる
と表現し直した！
>設定ファイルをXMLにする意味がないから、間違った使い方
>アプリ独自の設定ファイルは間違った拡張をされている
>設定ファイルをXMLにする意味がないから、間違った使い方
と散々意味不明な言い分で「間違った」と言っておきながら「メリットがない」と変更した。
これが典型的なストローマン論法だ。「間違った」と「メリットがない」が内を平気で混同する主観的な主張を繰り返してるだけだ。

これ以上価値のないレスをするな。

こいつはXMLはタグでデータ構造を作るってだけで、
タグの種類は定義されてないってことも知らないんじゃないだろうか？

みんなXMLを使ってなにかのデータ構造を作るときは
XMLを拡張して使ってるんですよ？

>>350
ん？ 確かにより適切な意味に変更したが？
違う意味に変更したわけじゃないから問題ないだろ

なに重箱の隅ばかりついてるんだよｗ
その行為に意味はないぞ。

> と散々意味不明な言い分で「間違った」と言っておきながら「メリットがない」と変更した。

メリットが無いから間違った使い方だって書いたろ？

やっぱり日本語の時点でおかしいんだよな。

権力のある人が他人の作ったアプリの構造の「メリットがない」と「間違った」を言い間違えたら訴訟レベルだな。
>>352>>353
その理論は流石にゴリ押しできないぞ。素直に訂正といえばいいのにｗ

>>348
さっぱりわかんないぞ。officeはアプリでツールで道具だけど、XMLは言語だろ。XMLはXMLのための道具なのか？

なんで「メリットがない」と「間違った使い方」をごっちゃにしてるんだろう？
根拠と結論の関係なんだが？

まあここでネタバレすると
ID:rkXy/Ofn がやってるのは議論じゃない
俺への攻撃だ。

この指摘だけでも、読む価値がないとわかるだろう？

XMLが文章のための道具とかXMLがデータ交換のための道具とかXMLがフィードのための道具って言うならわかるけど、
XMLはマークアップ言語のための道具ですか、理解に苦しむわ。

>>355
> XMLはXMLのための道具なのか？
はい、もう10回目ぐらいかな？
そんな事は言っていない

XMLは言語を作るための言語

http://www.atmarkit.co.jp/ait/articles/0012/23/news002.html
> XMLを用いて新しい言語を作る場合

http://www.atmarkit.co.jp/ait/articles/0005/22/news009.html
> XMLはメタ言語である。メタ言語とは、言語を記述するための言語という意味である。

http://park18.wakwak.com/~little-box/xml_basic/1-002.htm
> XMLは、"何をどう表現するか自由に定義できることから、"住所録用のXML"、"Webページ用のXML"、
> "論文用のXML"といったように、新しい言語を作ることができます。

https://www.milk-island.net/document/xml/kihon/b1/
> XMLとは言語を作るための言語。

>>357
お前が理解できてないだけだよｗ

>>358を読んで反省したら？

>>356
攻撃じゃない。アホだからからかってやろうとも思ってるけど、
さんざん「間違い」って言ってきたやり取りを、いきなり「メリットがない」に変えたら、今までのやり取りの意味がなくなる。
もっと言えば、「メリットがない」ってことを「間違い」って書いてたらそりゃ意味が通じるわけがないでしょってこと。受けての問題じゃない、発信側の問題。

https://www.ibm.com/support/knowledgecenter/ja/ssw_i5_54/rzakl/rzaklintro.htm
> XML を使えば、名前、肩書き、住所、郵便番号などのように特定の必要に応じた方法で
> 情報を記述する一連の規則やタグを含む独自のマークアップ言語を作ることができます。

http://www.techscore.com/tech/XML/Basic/Basic1/1_1.html/

> 　ひとつめの特徴は、SGMLが「言語を作る言語」、メタ言語と呼ばれるものであることです。
> SGMLそのものは、言語ではありません。SGMLにより、ユーザの環境に合わせた”フォーマット”を
> 作成することができます。
> HTMLはSGMLにより作成された、代表的な言語です。
http://www.techscore.com/tech/XML/Basic/Basic1/1_1-2.html/
> XMLはインターネットの標準としてW3C(*1)より勧告されたメタ言語です。SGMLをよりシンプルに、
> 利用しやすく発展させたものが、XMLです。XMLは、SGMLの2つの特徴 (「メタ言語、マークアップ言語)で
> あることを受け継いたため、インターネット上でのデータ交換に非常に適した技術であるといわれています。

>>360
> さんざん「間違い」って言ってきたやり取りを、いきなり「メリットがない」に変えたら、今までのやり取りの意味がなくなる。

だから、メリットが無いから間違いだって言ってる。
間違いを撤回などしてない

正しくは「XMLにするメリットが無い」から「XMLの間違った使い方」
だと言ってる。

こいつは中途半端に文章をぶった切って
違う意味にしようとするからな。用心のため

「メリットが無いから間違い」この命題は間違ってるだろ。論理性のかけらもないだろ？

クソめんどくさい。
もう寝るからxmlについて重大な誤解をしてるxmlくんに忠告だけど、
xmlスキーマは名前空間を定義しないとタグが重複するから定義するだけで、重複がない独自タグをアプリ内で使うのは自由。
独自タグを使っただけで間違いとは言えない。独自タグを使うメリットはアプリ独自の解釈ができるからでこれも間違い。
主張は間違ってる。

ちなみに名前空間の設定だけでは他のアプリが解釈できるわけじゃないから、スキーマに加えてオントロジーを定義する。
これでやっと独自タグが他のアプリからも読める。（アプリがオントロジーとスキーマを参照して機能を割り当てることによって。）
でも設定ファイルは特定のアプリから読むだけだから不要。
話の発端の設定ファイルを編集する汎用ソフトはめんどくさいし不要。
誰一人、設定ファイルのためだけにxmlスキーマもオントロジーの定義もしない。そのほうが面倒くさいからだ。

>>365
> 独自タグを使っただけで間違いとは言えない
XMLの文法的に正しいか間違っているかの話なんかしてない

設定ファイルにアプリ独自のタグを量産するのは
XMLの間違った「使い方」だって言ってるの

使い方の話
やっぱりまた日本が通じない

>>365-366は意味不明なことを言ってるから誰も理解できないと思う
だから代わりに俺が言ってることをまとめよう。

今のアプリでよく行われてるようにXMLを独自で拡張して
オレオレタグを作るというやり方は間違ったXMLの使い方
なぜならそんなことをしてもメリットがなにもないからだ。

XMLを拡張して汎用的な新しい言語を作れば、
汎用の（例えばGUIの）設定ツールを作ることができる
そうすれば、ユーザーは設定が簡単になるし、アプリ開発者はいちいち自分のアプリのために
設定ツールを作らなくてすむし、それでいて今までどおりテキストエディタで編集も可能

>>222 と >>224 に、今の間違った使い方と、あるべき使い方の例を書いておいた
>>292にも別のパターンを書いた。
>>228ではどんなデータでもこれで扱えるという話、そしてUIの作り方を書いた。
>>322ではリスト構造、ハッシュ構造を作る方法を書いた

222の間違った使い方では、アプリごとに独自のタグを作るから、どうしても汎用の設定ツールが作れない
せいぜいXMLエディタというXMLの形で編集するツールが作れるぐらいだ。それは何も使いやすくない

224の例からは、アプリごとの独自のタグはない事、独自のタグの名前がname属性になっていることが読み取れるだろう

292の例では何が選択可能で、今どんな値が設定されていて、デフォルトの値が何かが
設置ファイルにかかれており、それを汎用の設定ツールから読み取ることができる
独自のタグを作っていたらこんな事はできない。

なにか意見を言うのなら、ここまで具体的に書いてほしいものだ

とりあえず掲示板の使い方間違えるのやめてほしいな。

>>369
良い皮肉だ。


やつなら、掲示板に文法ミスでもあるんですかーとかいいそうｗ
書き込めるならどんな使い方でも、正しい使い方ですってな。

>>370
すり寄ってくんな。

どっちに対しての皮肉かも理解できないのか。。

理解してるからこうやってかけるんやで？ｗ

xmlくんは自分への皮肉を他人への皮肉だと受け取った模様。

案の定理解できてない（笑）

まあXMLくんは抽象論ばかりじゃ嫌になるだろうから具体論として
とりあえずsmb.conf、DNSゾーンファイル 、cron、bashrcぐらいを
さいきょうの設定XMLで書き直してどれぐらい便利かアピールしてくれよ

>>376
smb.confは上で書いた

DNSゾーンファイルであれば

例えばこんなインターフェースが作れる
https://www.dejavuz.com/wp-content/uploads/2015/05/onamae02-3.jpg

他にもミスしやすいシリアル値を自動入力できるようになる

cronだと日本人には分かりづらい日時の並び順を
分かりやすくすることができる

barshrcは設定ファイルでなくスクリプト。引っ掛けかな？ｗ
まあスクリプトでもtextariaを使うことはできるし
シンタックスハイライトぐらいやれるだろう

textareaの間違い

XMLを見せて欲しいと書いたんですよ？
UIじゃない。
smbも一項目じゃなくてそれなりに動きそうなもの示してくださいよ。

>>378
引っ掛け問題のつもりはないですがどんなソフトの設定ファイルてもかけると豪語してるのだから
bashrcが書けないとは思えないので設定XMLのサンプルよろしく。

>>381
<textarea>
ここに好きなbashrcのコードを書け
</textarea>

>>382
久しぶりにこんなひどいウンコードみたｗｗｗｗｗ

>>386
bashrcの中身見たことある？
こんなコードだよ。設定じゃない。
そんなこともわからないレベルなんだろうなーとしか思わんさｗ

# System-wide .bashrc file for interactive bash(1) shells.

if [ ! -e "$HOME/.sudo_as_admin_successful" ] && [ ! -e "$HOME/.hushlogin" ] ; then
case " $(groups) " in *\ admin\ *|*\ sudo\ *)
if [ -x /usr/bin/sudo ]; then
cat <<-EOF
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

EOF
fi
esac
fi

>>388
textareaの中にbashのコードがあるとどうやったら解釈できるの？

>>389
質問の意味がよくわからんがシンタックスハイライトの話かな？

<textarea lang="bash">
bashのコード
</textarea>

とすればいいだろう。

もちろんこれは設定ファイルであって、bashrcとして実行可能にするには
設定からコードを生成しなくてはいけない。
でもそれは別のツールの話

まあいまざっくりと考えながら書いてるんで
穴とかあると思うけど結構面白いな。

XML設定ファイルでありながら、汎用の設定ツールの
たたき台のたたき台ぐらいにはなりそうｗ

今ひらめいたけど、>>392のレコードを追加可能にする仕様
テーブルの最後に追加するか、途中に追加できるのか？は
設定ファイルに書く必要はない

それは設定ツールの実装に任せればよい。
間に追加してもいいし、最初や最後にしか追加できなくても良い
ツールによっては、レコードを絞り込むフィルタ機能や並び替え機能も
つけてもいいだろう。

所詮、テキストである設定ファイルの項目を
増減したり並び替えたりするだけだから問題は起きないだろうし。
本質的には設定ツールはテキストファイルの内容を
（使いやすく）書き換えるだけに過ぎないしね

>>391
UIの話してんの？htmlでホームページ作れるよってこと？

>>395
設定ファイルの話。

設定ファイルをXML形式にする・・・というのは
それなりに行われているが、単に冗長になっただけで
テキストエディタで編集しづらく、大したメリットがない。

だけどそれはXMLの使い方を間違えているからの話。
（他の形式に比べて）冗長なのはXMLである以上どうしようもないが、
メリットを出すことはできる。

それが汎用のXML設定ファイル形式（XMLを拡張してスキーマを定義する）
HTMLを参考にしてXML設定ファイルはタグが定義されているため
汎用の設定ツールを作ることが可能になる。

アプリの作者は単にその汎用のXML設定ファイル形式を採用するだけで
設定ツールの作成は他に任せることができる。

汎用の設定ツールはユーザーフレンドリーなツールで
例えば選択項目であれば選択候補を表示したり、
もちろん実装次第だが、ウェブサイトで見たことがあるような設定画面を
設定ファイルから作り出すことができる。多言語対応なども可能

ブラウザで表示したHTMLファイルのフォームの値を変更して、
そのまま元のHTMLに保存できるような感じ

そのような高度な設定ツールを使うことが可能な、
汎用のXML設定ファイル形式を作る・・・というふうに
世の中がなっていたら良かったのにという話
つまり、世の中はXMLの使い方を間違ったよなーって話をしてるだけ

>>396
単にホームページを作ってカスタムしたい設定ファイルをDLできるようにすれば良いんじゃね？

>>397
意味不明

なんでも表現できる君なんだから
欲しいと思う人は各々スキーマなりスクリプトなり勝手にこしらえればいいんじゃね
って事じゃないかな

もう
<textarea>
ここに〇〇の設定ファイルを書け
</textarea>
でいいんじゃね？
スーパーGUI設定ツールにハイライトや補完他色々して貰えばOK

>>400
必死にならなくていいよｗ
お前のアイデアはクソ
汎用XML設定ファイルの足元も及ばない

汎用設定XMLを使って専用GUIも使うと言ってるのに何が不満なんだろ

そりゃGUIからの設定がしづらいからだろ？
HTMLのフォームに似た要素ががある汎用XML設定ファイルなら
設定しやすいGUIが作れる。

GUIだったらどんなものでも満足するんだろ？
みたいな考え方じゃないんだよ

汎用XML設定ファイル専用GUIをもっと高機能にすれば解決ですね！
開発頑張ってください！

いや全然よくわかんないんだけど、
>ブラウザで表示したHTMLファイルのフォームの値を変更して、
>そのまま元のHTMLに保存できるような感じ
これはjavascriptでhtml生成して保存とかでいいんじゃ。。<textarea>で何でもかけるとか言い出したらもうタグの意味さえないけど。

>>405
> これはjavascriptでhtml生成して保存とかでいいんじゃ。。
変更したいのはフォームの値だけなのに、面倒くさいだけじゃん

> <textarea>で何でもかけるとか言い出したらもうタグの意味さえないけど。
それは設定ファイルの話をしてるのに、
実行可能コードをどうやって設定ファイルに含めるのか？とか
言い出したやつへの皮肉だな

>>404
GUI（設定ツール）の開発とXMLスキーマの定義は別々に考えよう

>>406
えｗxml君の言うとおり、フォームの値を入れるだけだろもちろん。
ブラウザにそんな機能ないからjavascriptで足してやればいいじゃん。それともブラウザを一から開発するのか？

>>408
開発する必要があるのは設定ツールだよ
ブラウザ技術を応用する。さすがにブラウザそのものは機能が多すぎる

そしてその設定ツールを作る前段階のXMLの使い方の話をしている。

汎用のXML設定ファイル（XMLをベースに拡張して独自のタグを定義したもの）は
設定ツールがなくてもテキストエディタで修正できる。だから設定ツールの存在は必須ではない
設定ツールの存在は必須ではないが、XMLをテキストエディタで修正するのは面倒

設定ツールがあれば設定は楽になるが、今のいろんなアプリの設定ファイル（XMLを使ったもの）は
独自のタグを定義しているため、アプリ専用の設定ツールを作る必要がある。つまり開発コストが高い
だから設定ツールはなくXMLファイルをテキストエディタで修正するにとどまっている

もし汎用のXML設定ファイル（XMLをベースに拡張して独自のタグを定義したもの）があれば
そんな状況は変わっていただろう。今頃はどんなアプリでも同じ設定ツールを使って
初心者でも簡単に設定できていた

つまり、世の中はXMLの使い方を間違ったよなーって話をしてるだけ

さて、無理やり軌道変更しようとしていたようだが、
世の中はXMLの使い方を間違ったよなーって話に
軌道修正できましたかね？ｗ

突っ込まれるとややこしくなりそうな問題から逃げ回るのを軌道修正というのか

ん？ >>220のときから書いてあるように
「世の中はXMLの使い方を間違ったよなーって話をしてるだけ」に
戻しただけですが？

何度言っても理解しないで、
俺にツール作れとか言い出すからね
ちゃんと言っておかないと

単純な話なんだけど、世界中で使われてるxmlの応用例を間違ってると言って自分が考える正しい使い方を披露しても、スタンダードの方が効率的で合理的だと思われるのは自然。

設定ツール無しでこんな複雑なXMLを手で編集しろと言われても
メリット無いだろ

設定ツールが無いとまともに扱えないようなXMLをテキストエディタでも大丈夫と
設定ツールの話を避けられても
ODFはLibraOffice使わずともviで書けますと言うようなもんだ

>>414
思うとかじゃなくて、ちゃんと理由をいいなよｗ
それじゃ素人の意見じゃん

>>415

> 設定ツール無しでこんな複雑なXMLを手で編集しろと言われても
> メリット無いだろ

だって手で（テキストエディタ）で修正するのは、開発者や技術者のために
そういうことも可能ってだけだから。普段は設定ツールで設定すれば良いんだよ

開発が進んで育てれば、設定ツール用のUIが追加されていくが、開発の初期段階とか
設定ツールのことは考えないって決めれば、設定項目を羅列するだけでも良い

例えば上の方で「設定ツールでユーザーが候補から選べるように<select>を使用する」と言って
以下のようなタグを書いたが、
<select name="item" value="a">
　<option>a</option>
　<option>b</option>
</select>

開発の初期段階とか設定ツールのことは考えないのであれば、以下のように書いてもいいわけだ
<input name="item" value="a">

どちらも設定内容としては同じ。これは複雑なXMLではない。
複雑なXMLになるのは設定ツールのためにそうするのであって、
それなら設定ツールでやれるようになるわけだよ

>>416
あまりにもクソコード過ぎて素人でも説得力ないってわかるって言いたいだけだよ。
selectにしろ、inputにしろ、それがどの設定における値なのかわからないってことぐらいわかるだろ。

開発者でもツールが無けりゃこんなもの扱う気なくすわ

まあだからxmlは今人気がないわけで。
xmlはあくまで文章なんで、officeに使われてるのもそれが理由だろ。昔はバイナリだったが。

こんなXMLはひどいと言われたらツールの支援があると逃げ
ツールの話になるとXMLの使い方の話だと逃げ
立場を変えるなあと思ったら
ついにはXMLの悪口言い出したか

>>418
> selectにしろ、inputにしろ、それがどの設定における値なのかわからないってことぐらいわかるだろ。

いや、名前で見分けろよｗ

<select name="url"> とかでわかるだろｗ

>>421
同じことを繰り返すな >>396ですでにまとめてる

設定ファイルの話。

設定ファイルをXML形式にする・・・というのは
それなりに行われているが、単に冗長になっただけで
テキストエディタで編集しづらく、大したメリットがない。

だけどそれはXMLの使い方を間違えているからの話。
（他の形式に比べて）冗長なのはXMLである以上どうしようもないが、
メリットを出すことはできる。

それが汎用のXML設定ファイル形式（XMLを拡張してスキーマを定義する）
HTMLを参考にしてXML設定ファイルはタグが定義されているため
汎用の設定ツールを作ることが可能になる。

アプリの作者は単にその汎用のXML設定ファイル形式を採用するだけで
設定ツールの作成は他に任せることができる。

汎用の設定ツールはユーザーフレンドリーなツールで
例えば選択項目であれば選択候補を表示したり、
もちろん実装次第だが、ウェブサイトで見たことがあるような設定画面を
設定ファイルから作り出すことができる。多言語対応なども可能

ブラウザで表示したHTMLファイルのフォームの値を変更して、
そのまま元のHTMLに保存できるような感じ

そのような高度な設定ツールを使うことが可能な、
汎用のXML設定ファイル形式を作る・・・というふうに
世の中がなっていたら良かったのにという話
つまり、世の中はXMLの使い方を間違ったよなーって話をしてるだけ

本人は何も考えてないだろうけど
この設定記述XMLには
設定値の保存のみではなく、
構造の定義やスキーマ他メタ情報、
データ型、バリデーションの記述、
UIやフォームのインターフェイス作成、
オブジェクトマッピングの定義など（まだまだあるかも）の機能や規格が必要で
規格書が電話帳のようになり実装可能だとしてもフットプリントは巨大になるのは間違い無いな

そりゃ規格なんだからある程度の量にはなるが、
基本はXMLなのでXMLとしての仕様は不要
タグ一覧があれば十分だろ
少なくともHTMLの仕様よりは大きくならない

> 設定ファイルをXML形式にする・・・というのは
> --- (中略) ---
> 汎用の設定ツールを作ることが可能になる。

ここまでは、まあ分かるが

> アプリの作者は単にその汎用のXML設定ファイル形式を採用するだけで
> 設定ツールの作成は他に任せることができる。

これが分からん。

現状のwel-formedなだけのXMLでも可能でしょ？
設定ツールやスキーマなど必要なものの作成は他に任せりゃいいだけで
アプリの作者は今のまま何の負担もない。

なぜ作者にとって本来不要な手間のかかる俺ルールを押し付けるのか意味が分からない。
一ユーザーの立場からするとそんなつまらんものに時間を割くぐらいなら
他の事をやるなり体を休めてくれとか思うな

>>426

> 現状のwel-formedなだけのXMLでも可能でしょ？
> 設定ツールやスキーマなど必要なものの作成は他に任せりゃいいだけで
> アプリの作者は今のまま何の負担もない。

それだとアプリごとに設定ツールを開発しなければいけなくなる。
今度は設定ツールを開発する側の負担が大きい（だから設定ツールは作られない）

> なぜ作者にとって本来不要な手間のかかる俺ルールを押し付けるのか意味が分からない。

必要最低限の使い方でいいなら使用するタグは<input>タグだけで成り立つよ
<input>タグのname属性が設定項目名になる。

今はほとんどが設定項目の名前をタグにしてるが、
それをname属性に変えるだけなんだよ。
アプリ作者の手間にはならない。

そしてHTMLライクなXML設定ファイルだから、プログラマじゃない人でも手伝える。
アプリ開発者がアプリ本体を開発間に、他の人が使いやすい設定ファイルを
作ってくれることも期待できる。

> それだとアプリごとに設定ツールを開発しなければいけなくなる。
そうならないような設定ツールを作るなり
スキーマなりスクリプトなどで扱える形なり
工夫すればいいだけじゃないの
> 今度は設定ツールを開発する側の負担が大きい（だから設定ツールは作られない）
ようするに設定ツールの作者個人のスキルが足りなかったり手間を掛けたくないから
全てのアプリ作者に無駄な作業を強いるって事ね

> 今はほとんどが設定項目の名前をタグにしてるが、
> それをname属性に変えるだけなんだよ。
そんな程度なら相互の変換スクリプトでも噛ませばいいだけの話
> アプリ作者の手間にはならない。
ゼロじゃなければ意味ないよ

> そしてHTMLライクなXML設定ファイルだから、プログラマじゃない人でも手伝える。
プログラム側でやってる全てのチェックをスキーマなりに落とし込む作業だからコードが読めないと無理では

> そうならないような設定ツールを作るなり
だからツールを作れるようにするために、汎用のXML設定ファイル
というのを作るべきだってって言ってるんだが？

現状、どんなアプリの設定ファイルも設定できるツールないでしょ
現実に不可能だったという実例があるのに、そうならないように〜とか言っても意味ない

> 全てのアプリ作者に無駄な作業を強いるって事ね
無駄じゃない。アプリの作者は自分でXMLの設定ファイルを考える必要がない
設定ツールを作る必要がない。というメリットが有る。

> ゼロじゃなければ意味ないよ
言葉遊びかな？ゼロじゃなければ意味がないというなら、
自分で独自形式を考えるのも時間がかかるからゼロじゃないってことになるね。
最初から汎用のXML設定ファイルを使うなら、
そこから別に物に変える必要がないのでゼロとも言えるｗ

> プログラム側でやってる全てのチェックをスキーマなりに落とし込む作業だからコードが読めないと無理では
プログラム側でやってるというなら、それに任せればいいだけだろ。
だからこの処理に相当するものはスキーマ（タグの定義）に入れる必要はない。
設定側でチェックをする必要はない。っていうかスキーマで設定値までチェックするとか勘違いしてるな？ｗ
スキーマにそんなものを入れるなんて言ってない。せいぜいどんなタグがあるかとその親子関係ぐらいだ
スキーマで設定値のチェックまでやっていたら、設定ファイルごとにいろいろ作らなきゃいけなくなるだろ（頭が硬いぞｗ）
HTMLの<input>タグの値だってスキーマで値のチェックまでやってないだろ。

まあこれは具体例を言わないと理解できないだろうから説明すると
ある設定項目は、A、CNAME、AAAA、MX、という文字列のいずれかの値を設定できますってことなら
そのチェックをプログラム側でやってるはずなので、設定ファイルにそんなものは不要。

設定ファイルの内容はこれ。現在設定されている値はAで、A、CNAME、AAAA、MXのいずれかを選択できる事がわかる

<select name="type" value="A">
　<option>A</option><option>CNAME</option><option>AAAA</option><option>MX</option>
</select>

繰り返すが「いずれかを選択できる事がわかる」と言ったんだ。この値以外を設定したときのチェックまでするとは言っていない。
だってそうだろう？テキストエディタで変更すればなんでも設定できるんだから、
そんなものを設定ファイルに入れることなんてできやしない。

これは、コメントを発展させたものと考えれば良いんだよ

# type: Select one of A, CNAME, AAAA, MX
type=A

ほら、typeにはBでもCでも好きなものを入れられてしまう。だから値のチェックはプログラム側でやることだしやってるはずだ。

そして英語がわかればどんな内容を設定できるかはわかるが、コメントから設定ツールのインターフェースは作れない
しかし設定ファイル自体がXMLであれば、それを読み取って設定ツールのインターフェースとすることができる。

汎用のXML設定ファイルというのは、テキストエディタで変更可能という特徴も残しながら、
ユーザーに設定しやすいインターフェースを提供する設定ツールを作れるようにするのが目的

XML文化の汚点の一つだよな。
なんでもXMLでやろうとしてしまったことだな。

XMLはデータだけを扱っていればいいのに
そのデータが正しいかどうかの検証もXMLでやりましょうとか

XMLはデータだけを扱っていればいいのに、
別の形式にデータを変換する処理もXMLでやりましょう（XSLTのこと）とか

俺はXMLSchemaやそれ相当のものを使うとは一言も言ってないよ。
面倒だから使わないと言い切ってもいいやｗ
現状使わないでやってきてるんだから。

>>425
タグ一覧だけ作って…って馬鹿だろ
何指摘されているのか意味わかってないんだろ？
口だけの無能と言うのがますますバレますなあ

あるアプリケーションの特有値は出来ないだろ。
例えばゲーム中に登場するキャラクターの変数とかどうすんだ？
全部nameにつめこむのか？もはやそれは独自タグと変わんないぞ。
nameの名前空間にカカロットとかベジータまで定義すんのかw

>>429
> だからツールを作れるようにするために、汎用のXML設定ファイル　> というのを作るべきだってって言ってるんだが？
繰り返しになるけど
ようするに設定ツールの作者個人のスキルが足りなかったり手間を掛けたくないから
全てのアプリ作者に無駄な作業を強いるって事ね

> 現状、どんなアプリの設定ファイルも設定できるツールないでしょ　> 現実に不可能だったという実例があるのに、そうならないように〜とか言っても意味ない
存在しないから不可能だと決めつけるのは短絡的だよ、需要がないからだとか面倒だからとか他にも理由は考えられる

> > 全てのアプリ作者に無駄な作業を強いるって事ね　> 無駄じゃない。アプリの作者は自分でXMLの設定ファイルを考える必要がない
多くのアプリの作者は手近なシリアライザの書き出しがXMLというだけで気にしちゃいないと思うぞ
> 設定ツールを作る必要がない。というメリットが有る。
元々設定ツールは必須じゃないし
設定弄るのなんてほとんど最初だけだから
テキストエディタでの編集しやすさってのはさほど重要じゃない

> 言葉遊びかな？ゼロじゃなければ意味がないというなら、> 自分で独自形式を考えるのも時間がかかるからゼロじゃないってことになるね。
XMLの使い方を間違った世の中を正す
よりは
XMLの使い方を間違った世の中に対応する
ほうがよほどマシ
と言えば分かるかな
どんなに素晴らしいものであろうが、使い方を間違っていると因縁つけ続けようが
他人は思い通りに動いてくれないからね

> プログラム側でやってるというなら、それに任せればいいだけだろ。
> 設定側でチェックをする必要はない。っていうかスキーマで設定値までチェックするとか勘違いしてるな？ｗ
静的チェック可能ならメリットあるかと思って賛同したけど
素通りとなるとenumなどの設定が安全簡単になりますよってなぐらいで魅力は薄れるね

>>430
> そして英語がわかればどんな内容を設定できるかはわかるが、コメントから設定ツールのインターフェースは作れない
# type: Select one of A, CNAME, AAAA, MX
type=A
を
<select name="type" value="A">
　<option>A</option><option>CNAME</option><option>AAAA</option><option>MX</option>
</select>
と解釈すればいいだけの話だと思うけど

>>431
> 俺はXMLSchemaやそれ相当のものを使うとは一言も言ってないよ。

>>426 は >>423(ID:29LJB/lv) に向けた書き込みで

> 423 名前：login:Penguin [sage]： 2018/09/16(日) 17:54:48.62 ID:29LJB/lv (5)
> 設定ファイルをXML形式にする・・・というのは
> それなりに行われているが、単に冗長になっただけで
> テキストエディタで編集しづらく、大したメリットがない。
> だけどそれはXMLの使い方を間違えているからの話。
> （他の形式に比べて）冗長なのはXMLである以上どうしようもないが、
> メリットを出すことはできる。
> それが汎用のXML設定ファイル形式（XMLを拡張してスキーマを定義する）
> HTMLを参考にしてXML設定ファイルはタグが定義されているため
> 汎用の設定ツールを作ることが可能になる。

つまり

設定ファイルをXML形式にする・・・というのは
大したメリットがない。
メリットを出すことは
スキーマを定義する

とはっきり書いてあるぞ。
もし 427(ID:4205k3sJ) ≠ 423(ID:29LJB/lv) だとするなら
なぜアナタが回答してきたのか疑問

>>432
なにか言い返せってｗ
ほんと何も言えないくせにとりあえずなにか言い返そうとするよな

>>434
> ようするに設定ツールの作者個人のスキルが足りなかったり手間を掛けたくないから
> 全てのアプリ作者に無駄な作業を強いるって事ね

意味がわからん。その理屈で言えば、素人はプログラミングできないから
プログラミングを勉強するのは、無駄な作業であるということになるぞ？
プログラミングできるなら、そのスキルは当然ありますよね？

> 存在しないから不可能だと決めつけるのは短絡的だよ、需要がないからだとか面倒だからとか他にも理由は考えられる
だから「面倒」ってことだよ。ずーっといってるじゃん。
アプリごとに設定ツールを作るのは面倒。だから作られないと。
でも汎用のXML設定ファイルというのがあれば、アプリごとに設定ツールを作らなくてよくなる

> 多くのアプリの作者は手近なシリアライザの書き出しがXMLというだけで気にしちゃいないと思うぞ
はい、だからそれも同じで、単なるXMLのシリアライザではなく、
汎用のXML設定ファイル用のシリアライザを使えば気にしなくて良くなりますよね？
アプリ作者の手間なんて殆どないよ。最低限<input>を覚えるだけですむ。（普通はそれ以上のことを知ってる）

> 静的チェック可能ならメリットあるかと思って賛同したけど
> 素通りとなるとenumなどの設定が安全簡単になりますよってなぐらいで魅力は薄れるね
えとさぁ、もう少し柔軟な思考持ったほうが良いよｗ
「設定側でチェックをする必要はない」と言ったんだよ？
プログラム側で今チェックしてるでしょ？愚直に値の範囲チェックとかしてさ
それをプログラミングしてる側がXMLSchemaを使ってやるのは構わないよ
必要がないと言っただけで、やってはダメなんて言ってない。

理解すべきことは、設定ファイルを書く側は、チェック内容まで書く必要はないってこと
役目をしっかり分けて考えよう。

・汎用のXML設定ファイル・・・アプリの設定値は仕様に含めない（含められない）。ただしタグの種類や親子関係は仕様として定義する
・設定ツール・・・汎用のXML設定ファイルを元に設定変更のユーザーインターフェースを提供する
・アプリ作者・・・読み書きは専用のシリアライザを使うだけ。読み取った設定値のチェック（やり方は自由）を行う。

>>436
XMLSchemaってなにか知ってる？

仕様として考えたスキーマを
XMLで記述するための言語の名前がXMLSchema

https://ja.wikipedia.org/wiki/XML_Schema
> XML Schema（XMLスキーマ）は、XML文書の論理的構造を定義する為に
> 開発されたスキーマ言語の一つ。現在、W3Cが開発・標準化にあたっている

スキーマ　＝　スキーマ（笑）
スキーマ言語　＝　スキーマを記述する言語

この2つをごっちゃにしてはダメ

同wikipedia
> しかし、複数の業界有力企業が仕様の策定に参加して、各社の思惑が絡み合い、
> あまりに多くの機能を取り込んだ為に、標準化は難航し、複雑な仕様となってしまっている。

複雑な仕様のものを使う必要はない

汎用のXML設定ファイルのスキーマは必要
汎用のXML設定ファイルにアプリ固有の情報（設定値の範囲などの）は
含まれない（というか汎用なんだから含められない）

だけど

それを利用したアプリ固有のXML設定ファイルのスキーマは必要ない
アプリごとにスキーマの定義はしなくて良いんだよ
そんな無駄で面倒な作業、誰がやるんだｗ
（必要ないと言っただけで、やったらダメとは言ってない）

理想的な世の中

アプリ作者「設定ファイルの形式どうしよう？
ini？JSON？YAML？XML？アプリ独自形式？」

アプリ作者「汎用のXML設定ファイル形式というのがあるのか？
よし使って設定ファイルを書き出してみよう」

<?xml version="1.0" encoding="UTF-8" ?>
<configurations>
<input name="foo" value="1">
<input name="bar" value="item1">
<input name="baz" value="true">
</configurations>

アプリ作者「ほうほう。これが汎用のXML設定ファイル形式というやつか
シンプルで使い方も簡単だが、なにが便利なのかな？」

設定ツール作者「我々が開発した設定ツールでGUIで設定できますぜ」

アプリ作者「単にインプットボックスで変更できるだけではないのかな？」

設定ファイル利用者「設定ファイル改良してみました。使いやすいインターフェースになります！」

<?xml version="1.0" encoding="UTF-8" ?>
<configurations>
<input name="foo" type="number" min="0" max="100" value="1">
<select name="bar" value="item1><option>item1</option><option>item2<option></select>
<input name="baz" type="checkbox" checked="true">
</configurations>

アプリ作者「いいね！」

お前さんこんなギャグセンスがあるとは思わなかったぞ
目指せIT系漫談家

425 login:Penguin sage 2018/09/16(日) 20:03:57.41 ID:29LJB/lv
そりゃ規格なんだからある程度の量にはなるが、
基本はXMLなのでXMLとしての仕様は不要
タグ一覧があれば十分だろ
少なくともHTMLの仕様よりは大きくならない

そんなどうでもいいところにしかレスできないのか

いやいや、xmlの仕様は不要で、htmlの仕様よりは大きくならないタグ一覧
が理解できる人がいたら教えてくれ。本人以外でな。俺は意味がわからん。

>>433は見逃してたわｗ

433が何を言ってるのかよくわからない
アプリの設定と（セーブ？）データをごっちゃにしてるようにしか見えないな。
ゲームは特殊で基本的に、アプリ（つまりゲームない）で設定変更するものだから
例えに使うと分かりづらくなるからやめたほうが良い

そうだな。ユーザーがアプリの動きを変更させるためのもので、
ユーザが作成したいデータではないものってことでいいかな？

>>444
> いやいや、xmlの仕様は不要で、htmlの仕様よりは大きくならないタグ一覧
> が理解できる人がいたら教えてくれ。本人以外でな。俺は意味がわからん。

XMLの仕様はW3Cが作ってるんだから、わざわざ作る必要はない。
作る必要があるのは、汎用のXML設定ファイルの仕様

https://ja.wikipedia.org/wiki/Extensible_Markup_Language
> XML の仕様は、World Wide Web Consortium (W3C) により策定・勧告されている。

ここ何のスレ？

XMLガイジのスレ

必死に設定XMLの機能、使いやすさ、展望を語るたびに
>>425
が光り輝くのであった

そもそも、xmlは独自タグ多くて、読みにくいし書きにくいからめんどくさいわ。
っていう共通認識から始まってるのに、xmlの運用を変えれば便利になるよっていう意味わかんない蛇足をつけるからややこしくなるんだ。
>htmlの仕様よりは大きくならないタグ一覧
ってなんだよｗブラウザよりは小さいアプリで足りるってことかよw
世界中でまともに使えるhtmlエンジンは2~3ぐらいしかないんだぞ。

ほんといい加減にしてくれ、知識をつけてから話に参加してくれ

> そもそも、xmlは独自タグ多くて、
XMLにタグは定義されてない。一つもない。タグが定義されてるのは
XMLを拡張して作ったXMLベースの言語でタグが多いかどうかは、その言語によるだろ
これぐらいの知識もない状態でからんでくるから、わざわざ説明しなきゃいかん

> >htmlの仕様よりは大きくならないタグ一覧
> ってなんだよｗブラウザよりは小さいアプリで足りるってことかよw
> 世界中でまともに使えるhtmlエンジンは2~3ぐらいしかないんだぞ。

まずな。引用してる部分がおかしいから。
「htmlの仕様よりは大きくならないタグ一覧」は俺が言った言葉じゃない
俺が言ったのは>>425だ

> そりゃ規格なんだからある程度の量にはなるが、
> 基本はXMLなのでXMLとしての仕様は不要
> タグ一覧があれば十分だろ
> 少なくともHTMLの仕様よりは大きくならない

>>424が不要なものまでごてごてに付け加えて、あーたいへんだーって言ってるから
「汎用のXML設定ファイル」の仕様はタグ一覧程度で十分だって言ってんだよ
UIとかフォームのインターフェースとか仕様に要らねぇよ。
汎用のXML設定ファイルの仕様なんだから。
設定ツールをどう実装するかは、設定ツールに任せればいいこと

んで、なんだ？汎用のXML設定ファイルの話をしてるのに、
お前は、それに対応した設定ツール（HTMLエンジン）の話してんのか
話にならない。設定ツールの実装をどうしろとか何も言ってねぇから
小さなツールも大きなツールも、大きさは設定ツール次第だろ
lynxやw3mといった小さなブラウザだってあるし、そもそもHTMLエンジンである必要もない

w3mやlynxが小さなブラウザだって？

425 login:Penguin sage 2018/09/16(日) 20:03:57.41 ID:29LJB/lv
そりゃ規格なんだからある程度の量にはなるが、
基本はXMLなのでXMLとしての仕様は不要
タグ一覧があれば十分だろ
少なくともHTMLの仕様よりは大きくならない