XSLTはGoogleに殺されたのか？
引用元：https://news.ycombinator.com/item?id=45873434
XSLT.RIPサイトをcurlしてみたら、ちゃんとXMLドキュメントだったね。XML宣言とかXSLTスタイルシートへのリンクもあって、まさにXSLTって感じだよ。面白いじゃん！
XSLTのせいでウェブがめちゃくちゃ複雑になって、結局ブラウザが2つくらいしか生き残らなかったんだよな。記事のサイトが90年代っぽい見た目なのが、なんか皮肉だよね。あの頃は「全てが良かった」って言われてたのにさ。
XML技術スタックを完全に終わらせてくれたのは、ミレニアル世代のおかげだよ。マジ感謝。あと、ブラッドダイヤモンド産業もね。（皮肉）
これってブラウザがXSLTをサポートしてるか区別する、めっちゃ賢いやり方じゃん。実際のコンテンツはhttps://xslt.rip/index.xslにあるXHTMLだし。著者ってフロントエンドデザイナーで、https://dbushell.com/っていう素敵なサイトも持ってるんだよ。両方のページの個性的なスタイルが気に入ったわ。
へえ、https://dbushell.comって、「D-Bus Hell」のことかと思ってたわ。てっきり本人の名前じゃなくてね。
皮肉なことに、テキストブラウザ（Lynxとか）でサイトを読み込むと、このテキストがそのまま表示されるんだよね。＜noscript＞タグで「このサイトにはJavaScriptが必要」って表示されるのと大差ない気がするわ…
Googleが関わってないブラウザでXSLTが実装されてるのか、今ちょっと疑問に思ってるよ。
XSLTは全然死んでないって。XMLは多くの産業やスタックに深く根付いてるし、JSONより良いものが出てくるまで、今後何十年も残るだろうね。
著者の「No AI made by a human.」って免責事項には思わず笑っちゃったよ。最近はAIを使ってるWeb開発者が多すぎて、これに気づける人ってほとんどいないんじゃないかな。この夏にWeb開発者と話したら、AIのおかげで生産性が少なくとも2倍になったって言ってたわ。俺的には、これって「底辺への競争」だと思うけどな。
ああ、COBOLみたいに、もう死んだんだよ。
とんでもないよ。XMLベースのフォーマットやインターフェースを使った新しいプロジェクトは今でも常に実装されてるんだ。XMLはどこにも行かないよ。
FirefoxはまだXSLTのサポートを削除してないよ。
1990年代初頭まで新鮮なCOBOLコードが書かれてたみたいに、最盛期を過ぎた後でもね。2000年代にはXMLに当たらずに死んだ猫を振り回せないくらいだった。ほぼ全ての求人広告にXMLが必須スキルとして載ってたんだ。でも2010年代半ばからは、XML関連の作業を全くせずにキャリアを終えることもできるようになったね。
GitHub CoPilotを1年くらい試したけど、Claudeも近いうちに試すかも。半分くらいは邪魔に感じたな。唯一本当に良かったのは定型的なSQLコードだった…スキーマ移行ファイルを作るとき、俺が書いてる内容からいくつか良い感じにやってくれたんだ。それ以外は、あまり役に立った気がしない。Google検索結果のやつ、Geminiとかだろ…当たり外れがあるな…時々動くように見える関数とかいくつか返ってくるけど、必要なライブラリの参照がないし、エラーが含まれてることもある。AIを使ったコーディングがすごく得意な友達を見てたけど、エラーや間違いを食わせて修正させる、イライラする作業に見えたよ。まるでADD持ちの天才10歳児をジュニアデベロッパーとして雇ってるみたいだ。
言い方を変えるべきだったな。このウェブサイトの話では、GoogleがMozillaとAppleにXSLT削除のために「金払ってて」、だから両社はGoogleに「支配されてる」ってことになってる。個人的にはそんなに白黒はっきりしてると思わないけど、「オープンウェブ」っていう主張が、この前提を受け入れたとしても疑わしいって言いたかったんだ。
ウェブ上での話だろ。俺はAndroidアプリも作ってるんだけど、AndroidとXMLは一心同体だよ。XMLファイルに触れずにAndroid開発なんてありえない。
AppleのOSは今でも、plistっていう方法でXMLを多用してるよ。これなしではアプリは作れない。
https://en.wikipedia.org/wiki/Property_list
これは間違いだね。他のブラウザを殺したのはレンダリングじゃなかった。レンダリングは難しい部分じゃないんだ。レンダリングのほとんどが動けば、インターネットの約99％は動く。難しいのは、代替ブラウザを殺したものは、JavaScriptだったんだ。Reactは2012年に出て、その頃にはみんなすでに初期のJavaScriptフレームワークにどっぷり浸かってた。その直後、GoogleはV8エンジンをリリースして、遅かったウェブをある程度使えるようにした。同様に、Mozillaも「Firefoxは遅い」という人々の声から這い上がるために、その10年間JavaScriptエンジンの開発に費やさなきゃならなかった。アドブロックを使っていればFirefoxが本当に遅かったのか疑問だけど、面白い話だね。モダンなウェブブラウザは、管理可能で実現可能なレンダリングの複雑さだけに対処するんじゃない。GoogleやJavaの最高峰に匹敵するJITコンパイラ開発チームを編成する必要があるんだ。JavaScriptは何にでも使われるから、部分的成功は許されない。ページレンダリングをめちゃくちゃにしても、たぶん人にとってはまだ多少使えるだろう。JavaScriptについて何か間違えると、ユーザーはインターネットのほとんどとインタラクトできなくなる。100％正しくても少し遅いだけで「使えない」となる。HTML5がまだアイデアだった頃にはサードパーティのウェブブラウザはまだあった。Reactが必須になった時に彼らは死んだんだ。
…てことは、もっと仕事の要求は増えるけど、タブを閉じれば煩わされないってことかな。高校生や大学生は大変だろうな。
そうなるのかな？でも、俺が作った数少ないiOS/watchOSアプリでは、手動で編集したことは一度もなかったな。
俺も同じような複雑な気持ちだよ。複雑さってある意味、非民主的だろ。仕様が複雑になればなるほど、実装は減るし、少数のプレイヤーに簡単にコントロールされやすくなるんだ。これは「抱き込み、拡張し、排除する」の「拡張」の部分で、「排除」は小規模な独立したプレイヤーが「拡張」についていけなくなったときにやってくるんだよ。もっと直接的に言うと、採用させて、複雑さのコストを上乗せして、競争相手を締め出すってことだね。
都合の良いことに、主要なJavaScriptエンジン3つは、開発されたブラウザから取り出して他のプロジェクトで使えるんだ。Node.jsやBunはV8とWebKit系を有名に使ってるし、ServoはSpiderMonkeyを組み込んでるはず。もし新しいブラウザプロジェクトを始めるとして、JavaScriptエンジンを一から書きたくないなら、すぐに使える選択肢が3つもあるってことだね。
でも、それはまだ存在していて、OSとツールによるサポートが必要だろ。手動で編集するかどうかは関係ない（ちなみに俺はアプリでもlaunchdエージェントでもいつも手動でやってるけどな）。
これは過剰規制に対する議論でもあるな。少しならすごく良いけど、多すぎると最大手のプレイヤー以外はみんな締め付けられちゃうんだよ。
中には死ぬべきだったものもあるよ。ほとんどが誤用されたせいだ。＜![CDATA[ … ]]＞を手動で何度書かされたか分からないくらいだ。全てのマークアップ言語には癖があるけど、XMLは信じられないくらい複雑で分かりにくくなることがあったな。
問題は、AIにタスクを任せきりにできないってことだ。数時間で終わらせて「次は何？」と聞いてくるわけじゃない。ほとんど付きっきりで世話しないとダメなんだよ。
大規模なアプリケーションの一部として、UIコンポーネントとかバックエンドの複数の部分で、一人が2～3個のAIセッションを管理するならあり得るかもね。でも、AIリソースとかネットワーク使用量とかが2～3倍必要になるな。これは誰かのお金で試してみたいところだね。
うん、そうだよ。複雑さは逆進課税なんだ。
ブラウザからXSLTのサポートがなくなるのは大反対！JavaScriptの“XSLTProcessor”機能も“＜?xml-stylesheet …?＞”も使ってるんだ。Googleのセキュリティやメンテナンスの理由はわかるけど、あれは的外れだよ。GoogleがMozillaやAppleに金を払ってるとは思わないし、こんな煽り記事じゃなく、もっと建設的な議論をしないと決定者たちを怒らせるだけだよ。
[0]: https://www.maxchernoff.ca/tools/Stardew-Valley-Item-Finder/
[1]: https://www.maxchernoff.ca/atom.xml
[2]: https://github.com/whatwg/html/pull/11563#issuecomment-31909…
[3]: https://github.com/gucci-on-fleek/lua-widow-control/blob/852…
「なんで的外れなの？」libxsltは全然メンテされてなくて、セキュアな使い方なんて考えてなかったし、バグだらけだったって話だよ。使われてないセキュリティホールだらけの機能なんて、さっさと削除すべきだね。XSLTを使ってる人たちが本当に残したいなら、Rustで代替を書いてたらよかったのに。
ウェブページで「決定者を説得」なんて無理だよ。この記事の目的は話題への意識を高めることで、ウェブページでできることなんてそれくらいしかないんだから。
意識を高めるだけでいいって考え、よくあるけど、それはみんなが既に賛成してる問題にしか効かないんだ。絶滅危惧種を救うとかならいいけど、みんなが知ってて賛成してない問題には、意識を高めるだけじゃダメ。もっと良い議論が必要だよ。
もっとコメントを表示（1）
XSLTの変換はサーバーサイドでやればいいんじゃない？そうすれば最新で最高のXSLTツールが使えるし、その出力なら、XSLTサポートがないブラウザでも動くでしょ。
libxsltのメンテ不足はわかるけど、XSLTサポートを完全に削除するのは良くないよ。Chromeの開発者がlibxsltを組み込んだ拡張機能を作ったんだから、それをブラウザにデフォルトで入れればいいんだ。それなら、セキュリティも後方互換性も解決するし、実装もメンテも楽になる。この案はGoogleに却下されたけどね。Rustでの代替も既にある（[2]: https://gitlab.gnome.org/World/Rust/markup-rs/xrust）けど、ブラウザに統合するのは大変だよ。
[0]: https://github.com/mfreed7/xslt_extension
[1]: https://github.com/whatwg/html/issues/11523#issuecomment-315…
Googleは「セキュリティ上の理由」でXSLTを削除すると言ってるけど、彼らがセキュリティ問題を完全に解決するブラウザ拡張機能をすでに作ってるんだよね。これって「嘘」だよ。Googleにはこの件について厳しく追及すべき。もし「ほとんど使われてないから」っていう正直な理由ならまだ話を聞くけど、偽りの「セキュリティ」を盾にするなんて許せない！
(もし彼らの拡張機能が完全なドロップイン置換じゃないなら、訂正してほしい。)
From your [1] “rejected for vague and uncompelling reasons”:
＞＞ To see how difficult it would be, I wrote a WASM-based polyfill that attempts to allow existing code to continue functioning, while not using native XSLT features from the browser.
＞＞ Could Chrome ship a package like this instead of using native XSLT code, to address some of the security concerns? (I’m thinking about how Firefox renders PDFs without native code using PDF.js.)
＞＞ This is definitely something we have been thinking about. However, our current feeling is that since the web has mostly moved on from XSLT, and there are external libraries that have kept current with XSLT 3.0, it would be better to remove 1.0 from browsers, rather than keep an old version around with even more wrappers around them.
「この記事は誇張してる」って言ってたけど、ユーモアのつもりで意図的に誇張してるんだよ。
「意識を高めることだけが全てじゃない」って意見だけど、それって全体の目標を補完するものじゃないかな？説得の必要性を理解してないわけじゃないと思う。絶滅危惧動物の例は、意識が高まりすぎて効果が薄れるケースだよね。でも、XSLTはそれほど浸透してないから、「動物を救え」レベルには全然達してないと思うな。
俺は逆だと思うな。絶滅危惧動物はみんな共感するから、意識を高めるだけでいいのかも。でもXSLTの終焉は、そもそも意識してる人が少ないし、知ったところで「良かった、誰も使ってなかったでしょ？」ってエンジニアは思うんじゃないかな。
「意識を高めることだけが全てじゃない」って言ってるけど、そんなに多くの人がそう思ってるとは思えないな。意識を高めるのは最初のステップだし、そもそも特定の『あなた』が納得したところで、ほとんどのトピックでは影響なんてないでしょ。
俺が理解できなかったのは、「RSSはニュースを配信するのに使われてて、それをGoogleが潰すことでメディアを支配できる。XSLTは世界中の政府サイトで使われてて、Googleは法律を支配しようとしてる」って部分だね。Googleはロビー活動もするけど、XSLTの法律をロビーしてるの？「法律を支配する」って、政府サイトの情報公開ツールを廃止すること？挑発的なスタイルは好きだけど、これはレトリックのやりすぎだと思うな。
libxsltはXSLTとは違うものだよ。libjpgが安全じゃないからってJPEGのサポートを削除するようなもんだって！
個人的に納得しても影響はない。でも、俺みたいな人が大勢、まとめて納得すれば影響はあるんだ。
人は納得（つまり理性的に）したから動くんじゃなくて、感情的に揺さぶられるから動くんだよ。理性的な議論なんて後から、それもほとんど密室で行われるんだ。
うん、それは静的サイトジェネレーターの一部になるはずだよ。
オープンソース開発者として、俺もこの状況のGoogleにはかなり同情するよ。レガシー機能がプロジェクト全体の足かせになってるのに、使ってる人がごくわずかなのにすごく声が大きくて、無料のソフトウェアなのに開発者を罵倒するのが当たり前だと思ってるのは、多くのOSS開発者が共感する苦悩だと思うな。
え？静的サイトジェネレーターでRSSとRSSのHTML表示を同じファイルから出すってどうやるの？ブログに＜a href=”feed.xml”＞My RSS Feed＜/a＞リンクを置きたいし、RSS知らない人にもただのXMLじゃない表示を見せたいんだよ。
「control legislation（法律をコントロールする）」って、政府サイトで情報を公開するツールを非推奨にするって意味？
文脈的には「政府サイトで法律の原文を公開すること」って意味だと思うよ。
君の言うことはボランティアのオープンソースプロジェクトには当てはまるけど、Googleには全然当てはまらないと思う。
Googleは技術的に優れた製品で市場を獲って、今やウェブプラットフォームを彼らの好きなように動かしてる。ブラウザの維持コストなんて関係ない話だろ。
「JavaScriptの”XSLTProcessor”関数や”＜?xml-stylesheet …?＞”を個人のサイトで使ってるよ」
それって、超エリートなウェブ標準ユーザーチームにいるってことだね（笑）。
そうだね、僕の引用と君の補足は同じことを言ってる（少なくとも書いた時はそう考えてた）。
でも、「control the laws（法律をコントロールする）」と表現するのは、政策決定プロセスへの文字通りの支配を強く示唆する、僕が言ってるレトリックの言い過ぎで、また元の話に戻っちゃうよ。
彼らのロジックは理解できると思う。
セキュリティ上の懸念でサポートを削除してるし、ほとんど誰も使ってない機能だから拡張機能でサポートを戻すことはしない。
拡張機能での追加もタダじゃないからね。
もしそれが本当なら、今日中に別のライブラリで解決できるはずだよ。
そのライブラリが唯一使われてる実装だし、その機能にみんな頼ってるんだから。
それはもっともな意見だと思う。でも、「セキュリティを理由にXSLTは使えない」って言うのは意図的に誤解を招くし、正直じゃないって僕は言い続けるよ。
「コストがかからないわけじゃない」って言うけど、99.9%の作業はもう終わってるんだ。
Web Extensionsのインフラもあるし、C/C++からWASMへの移行も例がある。
インストーラーサイズ増加だけじゃない？それは知らないけど。
XSLTが削除された時の僕の感情的な反応は、「ついに！」だったよ。
この決定を歓迎する気持ちがあるのに、それが実は悪いことなんだって僕を納得させるには、よっぽどいい議論が必要だね。
「前回この話が出た時、libxstlはほとんどメンテされてないし、安全な目的で使うべきじゃなくて、バグだらけって意見が多かった」
ここHNだし、誰かRustで書き直せって言った？ :)
役立つはずなのにアクセスしにくい法律や、顔に突きつけられるような規制の法律があるよね。法律を”消費”できるようになれば、自分のアジェンダも押し進められるってことだと思うな。少なくとも、俺はそう読んだよ。
Firefoxはlibxsltを使ってないし、たぶんIEもそうだったと思う。WebKit系のブラウザだけがlibxsltを使ってるんだよ。
Googleだって人間が集まってて、一日の労働時間は限られてるんだから、レガシーなものなんてメンテナンスしたくないと思うよ。金持ちや大企業が俺たちと違ってルールが適用されないみたいな変な考えがあるけど、結局みんな人間なんだから、同じ制約が適用されるのが普通だろ。せいぜいちょっと押し広げられるくらいだよ。
XSLTが停滞して市場でほぼ消えたのは悲しいな。25年前のオープン標準だったXML+XPath+XSLTエコシステムのほとんどを、互換性のないライブラリで再現しようとするなんて、才能の colossal waste だよ。SOAPはHTTPを誤解した過剰設計システムだったか？そう。XMLスキーマの乱用で文書が読みにくくなったか？もちろん。初期のXMLライブラリは既存のプログラミング言語の現実を考慮して設計されてたか？ノー。でもJSONの初期実装、’eval()でメモリに読み込める’ってのは良いエンジニアリングだったか？ノー。JSONパーサーを書く頃には、XMLシステムも同様に改善できたはずなのに。委員会が過剰に飾り立て、エンジニアがすでに持っていたものを認識せず、他のものを作る興奮に駆られて殺された良い技術にRIP。
ここで俺は君の意見に賛同できないな。
JSONの仕様はたった2ページのWebサイトに収まってるんだよ https://www.json.org/json-en.html
それに対し、XMLの仕様はもはや本だよ https://www.w3.org/TR/xml/
「JSONの仕様は2ページ」ってのは完全に違う。最初の段落から「JavaScript Programming Language Standard ECMA-262 3rd Edition - December 1999」のサブセットだって書いてあるだろ？それは本だよ https://ecma-international.org/publications-and-standards/st…
さらにJSONは互換性のない実装が多すぎて、JSON実装のエラータは複数の本になるくらいだ。「XMLの仕様は本」って言うけど、それこそがXMLを理解するのに必要な全てなんだ。APIを実装してきた経験から言うと、XMLの実装はいつも完璧なのに、JSONの実装はいつも何か変なことに出くわすんだよ、作者がブログの2ページを読んで「概要を掴んだ」と思ってるからな。
他のコメンテーターが指摘するように、君の比較は誤解を招くね。XMLのエコシステムをゼロから作り直す必要はなかったんだよ、すでに機能してたんだから。JSONの大きな主張の一つは配列サポートがあるってことだけど、XMLにそれがなくても、同じ型のXMLノードのコレクションを配列として扱うシリアライザー＼デシリアライザーを作るのは不可能じゃなかったはずだ。もしかしたらもう存在するかもしれないけど、概念的に難しいわけじゃない。
もっとコメントを表示（2）
JSONの{}、{a: []}、{a:[1]}、{a:[1, 2]}、{a: 1}みたいなケースを、XMLで普遍的な方法で表現するのは不可能だよ。
君は「based on」というフレーズを誤解してると思うな。俺が思うに、それは「〜に由来する」とか「〜を起源とする」って意味であって、ECMAScript 262の仕様がJSONパーサーを実装する前提条件だってことじゃないんだ。IIRC、JSONの仕様はJavaScriptが同じオブジェクトを解析する方法といくつか異なる点もあったけど、これはその後どこかで修正されたかもしれないね。JSONは単体の言語として、あのページに書かれてる情報だけで十分だよ。
まだ良いXMLパーサーはほとんどないけど、良いJSONパーサーはたくさんあるから、君の主張は納得できないね。良いJSONパーサーならたいていの優秀なエンジニアは書けるけど、俺は良いXMLパーサーを使ったことがないんだ。これはRuby、Perl、Python、Java、KotlinでXMLをパースする個人経験に基づくけど、いつも大変だし、キャリアで少なくとも2回はパーサーのバグに遭遇したよ。でもJSONパーサーでは一度もないね。JSONパーサーを正しく実装する方が断然シンプルだよ。それに一般的にユーザーフレンドリーなんだ。
JSONの仕様書だけじゃなく、ECMAScript-262も読まないとJSON.parseの挙動は理解できないってこと？ブラウザがJSONの仕様通りに実装してないか、そのどっちかだよな。
XML実装は“いつも正しい”って言うけど、そんなことないね。この前も属性値のエンティティ参照をデコードしないXMLに出くわしたし＜https://news.ycombinator.com/item?id=45826247＞。DOCTYPEやエンティティも実装間で信頼できないんだ。JSONと違って、XMLはパース層を超えてドキュメントを解釈する部分でもっと問題が起きがちだよ。
C#や.NETを見てみてよ。2000年代初頭からあるXMLパーサーは最高だけど、JSONライブラリはイマイチなんだ。公式のJSONライブラリは物足りなくて、古いサードパーティ製の方が良かったりするんだよね。
XMLってデータシリアライズツールじゃなくて、言語ツールだよ。表記法を作るもので、フレーズみたいな構造を作るべきなんだ。だから、ユーザーが区別したいなら、それを表現する表記法を作ればいいんだよ。
ECMAScript-262ベースの言語でJSONパーサーを書くなら、もちろんECMAScript-262も理解しないとね。XMLパーサーでも同じだよ。Pythonで書くならPythonの理解が必要。つまり君は“JSONというフォーマット”と“ECMAScript-262で規定されたJSON.parse関数”を混同してるんだと思うよ。これらは別物だ。
数字は常に文字列として扱うべきっていうアドバイス、勘弁してくれ！扱えない入力はパーサーがエラーを出すべきだろ。XMLの仕様書だって、プラットフォームで表現できない値をどう扱うかなんて教えてくれないし、タイムスタンプの読み方も範囲外だ。JSONの唯一の共通問題はコメントだけ。SOAPの仕様はタイムスタンプの書き方を教えてくれるけど、それは一冊じゃないし、プラットフォームの制限や配列はカバーしてない。比較するなら、OpenAPIの仕様書はこんなに分厚いよ: https://swagger.io/docs/specification/v3_0/about/
ECMAScript-262ベースでXMLパーサーを書く場合も同じことが言えるね。ありがたいことにXMLは数値とは何かを規定してるから、それを間違えればXMLを実装してないことになる。すごくシンプル。だからXMLを実装する人たちとは問題が少ないんだ。JSON.parse()がJSONの実装じゃないっていうのは深刻な意味を持つ。ブラウザベンダーですら正しくできないなら、他はどうなるんだ？僕はそれらを同じものだと考えるし、JSONは思ってるよりずっと複雑だと考えてる。
JSONは表記法なしで即座に使えるのが特徴だよ。根本的な違いは、JSONは一般的なデータ構造（任意のアイテムの配列、文字列キーと任意の値を持つ辞書）と相性が良いことだね。XMLノードは属性が文字列キーと文字列値、名前が専用の文字列属性、子ノードがノードの配列という、ちょっと特殊な構造で、プログラミング言語のオブジェクトへのマッピングに手間がかかる。だからOXMフレームワークなんてものもあったくらい。JSONの方がずっと自然にフィットするんだ。
新旧のJSONライブラリは同じ人が書いてるよ。新しい方は意図的に低レベルになってるんだ。古い方は機能が多すぎて肥大化してたからね。
XSDを使えば、要素が1つか複数かを明示的に指定できるから、データ自体にその情報をエンコードする必要がないんだ。具体的な数値型にもアクセスできるから、1や2みたいな値を実装が実際にサポートしてるかどうかを心配する必要もないよ。
全てのXMLにXSDが関連付けられてるわけじゃないし、XSDを転送する必要がある。そのXSD用のコードジェネレーターを書くか、他の方法で使うか…って、JSONならJSON.parse(string)で済むのに、こんな無駄な作業がたくさんあるんだぜ。
JSONの仕様は2ページに収まる（https://www.json.org/json-en.html）って言うけど、愛されるミニマリストな仕様？そんなの絶対に変だろ。実際は、https://seriot.ch/projects/parsing_json.html を見ると、少なくとも半ダース以上の仕様が混乱を解消しようとして失敗してるんだぜ。
JSONで数値型を使ったり、キーを繰り返したりしようとすると、パースは悪夢になるって保証するぜ。これって別に珍しいことじゃないしな。みんなJSONでスキーマとか、ひどい時には名前空間を再実装し始めるけど、そんなことしたら大変なことになるぞ。頑張れよ。
そうか、だから良いレイヤーがないんだな。XMLのライブラリ（XmlReader, XmlDocument, XmlSerializer）はシリアル化に大体使えるし、APIもよく考えられてる。でもJSONのNewtonsoftやSystem.Text.Jsonには、低レベルなJsonReaderや mutable JObjectみたいなのが見つからないんだ。どちらも良いけど、XMLほど包括的じゃないんだよな。
XMLの仕様の”参考文献”セクションは、JSONの仕様そのものよりほぼ長いんだぜ。お前は都合のいい部分だけつまみ食いしてるだろ。
XMLは数値が何かって定義してないよ、そこは誤解してるかもな。XSDで定義しても実装次第で挙動が変わるし、JSONもJSON Schemaとかで同じことだろ。結局、JSONだろうがXMLだろうが、パースする時に複雑なエッジケースがたくさんあるのは一緒なんだよ。使うライブラリ、言語、そして仕様を理解しないと正しくできないってこと。
全くその通りだよ、パーサーは処理できない入力で失敗すべきだぜ。ブラウザの開発者にも分かってほしいよな。JSON.parse(”9007199254740993”)が9007199254740992になっちゃうとか、勘弁してくれよ。
まさにこれ。俺の経験上、XMLは落とし穴だらけだけど、JSONはすげーシンプル。選べるなら、いつもXMLよりJSON APIを選ぶね。
XMLはテキストのマークアップにすぐ使えるし、タグも自由に作れる。int myFunc(int a, void *b);みたいなフレーズ構造を書くのに向いてるんだ。特定の記法より書くのは不便でも、パーサー不要で汎用ツールで処理できるんだぜ。XMLは言語をパースするようなもんで、ニッチな記法を少数プロが書くのにすごくいい。インターフェース仕様とか、キーボードレイアウトとか、そういうところで今も使われてる。JSONはデータダンプには良いけど、人間が構造をオーサリングするならXMLの方が断然使いやすいってことだ。
