ほんとそれ。著者が「複雑すぎる」って思ってる理由が全然書かれてないし、ただの一人の愚痴だよね。

これで何を言いたいのか全然わからない。XMLやSOAPの信者に会ったことはないけど、XMLがシリアライズできるからって、XMLスキーマが人工的に複雑になることは不可能だって言ってるの？ XMLをシリアライズすることでデータモデルの表現が最適化されるのはどういうこと？

何かを解析することと、仕様を実装することの違いが分からないの？これらは全く別のことだよ。XMLを解析するのは明らかに簡単だけど、解析したXMLで何をするか、そしてその解析された構造が何を表すかが重要なんだ。

たぶん彼らはそうだね、XML構文の解析はOOXMLやXMLフォーマット全般の複雑さの問題じゃなかったし、XML ASTの上にあるすべてが問題なんだ。

もうちょっと具体的に言ってくれない？ HTMLとCSSはそんな風には説明できないと思う。確かに複雑だけど、難解ではないよ。ほんの少しの部分から始めて、数時間で使えるきれいなドキュメントが作れる。タグやルールはだいたい自己説明的で、簡潔だし、良いドキュメントやツールがたくさんある。標準の開発もオープンで、決定や理由を理解したいなら覗いてみることもできる。

でも、それはオープンスタンダードだよね。Microsoftだけが自分のXMLに関する真の知識を持ってる。

これに関しては全く似てないね。

そうだね、HTMLとCSSは間違いなく無茶苦茶になってる。その大きな理由は、一般的なアプリケーションUIツールキットとして使われることを想定して設計されていなかったからだよ。特にCSSは印刷可能な文書のために設計されていて、現代のウェブサイトには向いてないし、HTMLは「クラシック」な文書のコアな意味構造を表すために設計されてた（あまり派手じゃないものね）。最小限のフォーマット（例えば、太字、斜体、下線）で、古いウェブサイトでも全然そんな使い方されてなかったし（例えば、全体のサイトを作るために古いテーブルを使ってヘッダーやサイドバーを作るとか、今はHTML5やモダンCSSでよりきれいにできるけど）。だから、初期のインターネットの頃に選ばれたマークアップとスタイル言語が、すぐにウェブサイトが両方の言語のデザインとは全く違う方向に進化することを認識することになったのは面白いよね。でも、OOXMLの状況とはあんまり関係ないけど。

一般的には同意するけど、著者がXML仕様の複雑さについて文句を言ってるわけじゃなくて、むしろ基盤の構造をページにレンダリングするのが難しいってことだと思う。

そうそう、またバンカーな開発者がいるね。複雑なXSDは、業界の基準みたいになってるよ。仕様の役割がシンプルな1サーバー：1クライアントのユースケースを超えるとね。たまに使う例では、ほぼ1MBのXSDがあって、それはかなり小さな内部データツールなんだ。RESTful JSONバリアントもあるけど、あんまり使われてないし、複雑さはほぼ同じだよ（名前空間の地獄から逃れたり、XML文字をエスケープしたりするけど、JSON周りのツールはちょっと進化が遅れてる）。XMLからオブジェクトへのマッピングツールは必須だね。

インターフェースって、戦いの半分だけって感じじゃない？なんでこれが反論になるのか理解できないな。

XMLそのものだけじゃなくて、マイクロソフトがオープンソースが追いつくたびに標準を変えたがるのが本当に厄介なんだよね。大抵の場合、彼らはオープンスタンダードを使わずに、別のドキュメントタイプを使ってるし。人工的なベンダーロックインは現実だよ。

なんでそんなにダウンボートされてるのか分からないよ。2025年には全く合理的な意見だけど、大きな普及の壁に直面してるね。人々は、たとえそれがますます珍しくなっても（例えば法的な場面でも）、ドキュメントのページを印刷するという考えにしがみついてる。

じゃあ、みんなウィンドウマネージャーなしでArch Linuxに移行しようぜ。そしてWi-Fiを使うためには自分でドライバーを書かなきゃいけない。ユーザーフレンドリーさに死を！上級者だけの世界だ！/s

WYSIWYGが問題だとは思わないな。マークダウン用のWYSIWYGエディターもあるし。ドキュメント作成が紙の一部をデジタルで表現することだという前提が問題なんだよ。今のほとんどのドキュメントにとって、物理的な紙の表現として見るのは意味がない。ドキュメントをまるで紙のように表現するという言葉のパラダイムは、まだ使われている分野では時代遅れになってる。皮肉なことに、アトラシアンのConfluenceは、企業がドキュメントを紙の表現として使うのを遠ざける大きな力になってる。

HTMLのWYSIWYGエディタって、ベンダーロックインに繋がることってあるの？

LaTeXを見てると、毎回完璧な見た目になるまでパラメータを手動で調整するのって、あんまり良いユーザー体験じゃないと思うな。もちろん、見た目を気にしなくなれば、エネルギーと時間をかなり節約できるけどね。純粋なHTMLに戻って、JavaScriptやCSSなしでやればいいんじゃない？

コンテンツに集中するのは楽しい部分じゃなくて、そうすると顧客が BSな理由で権力を振りかざす場所に行き着くんだよね。見た目を完璧にするために、すべてをうまくやりたいと思う。だって、PDFレポートの見た目が悪いから交渉を下げてくる人が必ずいるし、「この見出しは正確にやってる競合がいる」って知ってるから。もちろん、意味不明なコンテンツは受け入れられないけど、小さなズレは許容されるべきだよ。残念ながら、正確な見た目を求める権力ゲームがいろいろあって、BSな問題で細かく突っ込んでくるクソ客から逃げる選択肢がないこともある。

これがうまくいくのは、コンピュータを使う人全員が技術者で、LaTeXとかを数ヶ月かけて学ぶ意欲がある場合だけだよね。もちろん、その2つの条件は現実には存在しないから、無理だね。

多くの非常に広く使われているLaTeX「エディタ」には、半ライブの「プレビュー」機能があって、WYSIWYGのような機能をプレビューで提供することが多い。例えば、誰かが非技術的な人として、見出し付きで5段落のテキストを書く必要があるとき、高度なフォーマットの要件もテンプレートも何もない場合、なぜ彼らにWYSIWYGを強制しないのか？それが彼らの使用ケースに完璧に合っているのに。Markdownも多くの執筆要件にはスケールしない。全くもってね。私は、大学時代にほぼすべての論文や大きなレポートをMarkdownで書いたから知ってる。Markdownから抜け出さなきゃいけないことが多かった。インラインLaTeXを使ったり、MarkdownをPDFに変換するテンプレートを調整したり（Markdownを多くの異なるファイルやフォルダに分割して、それぞれがMarkdownか他のもので、インラインLaTeXを使ってMarkdown以外のソースを取り込むなど）していた。いいパイプラインだったけど、実際にはもうMarkdownではなくて、Markdown、LaTeX、他のものの混合になっていた。プログラマーとしてはそれで良かったけど、一般的なオフィスアプリのユーザーには全くスケールしないよ。

完璧な見た目よりも、内容に焦点を当てるべきだよね。多くの文書は、内容よりも見た目のために作られてる。

XMLフォーマットは、レガシーの複雑さを扱うための余計なものが多くても、レガシーのバイナリフォーマットよりも解析や相互運用が絶対に楽だよ。OOXMLは、文書化された相互運用可能なフォーマットを持つ必要性に先んじようとした試みだったと思う。アメリカやEUとの法的和解の結果だったと思うけど、今は調べる気力がないな。

ごめん、でもXMLはこれにぴったりなんだよ。XMLを使ったことがない人は、実際にいくつかのことをうまくやってるなんて想像もつかないだろうね。要素の前後や中にテキストを重ねられるのは特に重要だし、HTMLの知識がある人なら分かるはず。OLEウィジェットをドキュメントに取り込んでもちゃんと動くように名前空間を使えるのも、さらに重要だよ。それに、会社が使ってるちょっとマイナーなサードパーティのコンパイルプラグインのメタデータも、ちゃんと埋め込まれて保存されるし、プラグインがインストールされていないツールとも互換性がある形でね。だから、これは「ブーム」じゃなかったんだよ。

このXML形式がzipに入ってdocx拡張子で存在するようになったのは、Office 2007からだよ。

その通り、邪悪な意図は必要ないよ。時間の制約や軽い無能さで十分だから。OOXMLフォーマットは、あまり深く考えられていないXMLシリアライズだと思う。時間に追われて作られたものだし（当時、Microsoftには法的なプレッシャーがあった）。

彼らは、まずクリーンなファイルフォーマットを考えて、それに合わせてツールを書くという贅沢はなかったんだよね。これは正しくない。彼らは（私の知る限り）その必要はなかったし、いくつかの特殊なケースでは古い文書をオープンフォーマットに完璧に変換することもできなかった。実際、彼らの独自フォーマットの異なるバージョン間での変換でも、時々壊れることがあったんだよね！（当時） > 1990年代後半から2000年代初頭にかけて存在した信じられないXMLブーム。（編集：実際には2006年だから、うーん、XMLブームか）2010年頃のことを話してるけど、その頃にはブームはほぼ終わってたし、彼らがそれを選んだ主な理由は、XMLをマークアップ言語として使う新しい標準化されたオープンオフィス文書フォーマットに対する「補完」として位置づけるためだったんだよね（ただし、実際にはXMLをマークダウン言語として使うのではなく、もっと複雑なJSONへのシリアライズみたいな感じだけど、それは関係ない）。彼らは「競争を妨げようとしていない」と人々を納得させる必要があったから、クリーンなデザインをする能力は十分にあったはずなんだ。古い「独自」の文書が変換時に微妙に壊れることがあっても、それは関係ないし（実際に壊れたし） - OpenDocumentフォーマットを採用すればよかったんだよ。

偶然にも、ページといくつかの段落のようなシンプルなレイアウトが、Markdownのようなフォーマットがなぜ可能なのか疑問に思わせることがあるんだ。なぜなら、ナンバーワンのテキスト処理ツールは、数段落のために巨大な粗い構文を投げつけてくるから。MSには感謝だね、彼らが灯りを保ってくれてる。人々は、MSフォーマット自体は存在しないことを理解する必要があるんだ。選べる異なる標準があるだけ。何年か前、OpenDocumentがかなり人気だった頃、MSはXMLフォーマットを使うのにちょっと躊躇してた。XMLは厳格なフォーマットで、構文に関係なくね。MSは、オープンソースプロジェクトがパーサーを開発して市場シェアを失わないように、そんな複雑なフォーマットを意図していたと思う。そんな戦略についての考慮が当時、Archive.orgに埋もれているはずだよ。一方で、MSはXMLの混沌を望んでもいなかったし、後にそれが起こることも見えてなかった。XMLはフォーマットで、求められるのは形式的に正しいことだけなんだ。アセンブラのように、固定された命令セットで自由度が高く、コンピュータだけがコードを「理解」すればいい。動けば、それでいい。何かを強制することはできない。JavaScriptはかつてウェブのアセンブリ言語だった。すべてが可能だったけど、地道な作業をして、すべての高レベルの機能を数百行のモジュールにカプセル化しなきゃいけなかった。数百行でできることを、Pythonの1行で達成できるのに。Babelが登場し、TypeScriptが出て、今では言語やその方言の変更や機能について把握できなくなってる。PHP、Java、C++、さらにはPythonも同じ。盛り上がった機能がたくさんあったけど、それでもこのクソを学ばなきゃいけないんだ。なぜなら、それが有効なコードだから。人間は安定した状態を耐えられない。何かを追加すればするほど、より活発で価値があるように見える。機能の増加にはうんざりだ — コンパイラの開発者たちには感謝だね、彼らは灯りを保ってくれてる。

これがどれだけ偶然の複雑さに関連しているのか気になるな（彼らの元々のクローズドフォーマットで）と、WYSIWYGが開発者がどうしてそうなったのか分からないようなダンプをしているのかも。これがOOXMLに持ち込まれたのかもね。はっきりさせておくと、MSは当時も最近も、オープンや標準化に関するほとんどのことにおいて「抱きしめて拡張して消す」というのが彼らの行動の核心であることを繰り返し示してきた。オープンなテキスト標準を「消す」ためのより良い方法は、彼ら自身が作った、うまく機能しないことが保証されたフォーマットを作ることだと思う。つまり、最初のMS製品以外にはほとんど機能しないようなものを作って、それを使ってオープンなテキスト標準は良くないというプロパガンダを押し進める。だから、彼らが非常に複雑で、実際に標準に準拠して実装するのが不十分なOOXMLの「オープンスタンダード」フォーマットを持っているのは、非常に意図的なことだと確信しているよ。でも、内部がすでに混乱しているなら、それを使ったり拡張したりするのは非常に良い手段だね。なぜなら、そうすることで物事がどうなったのかの言い訳ができて、実装時間を節約できるから。---- (1): 免責事項: その間に数年間、彼らはかなり友好的に行動していた時期もあった。特定のMSの開発者は、オープンソースを本当に愛しているし、いくつかの分野ではオープンソースも勝利を収めている。時には「拡張して消す」のには非常に悪い時期もあるから、まだ終わってはいない。時には非常にゆっくりと、じわじわと進んでいることもある。だから、良いMSのオープンソースプロジェクトや貢献も見つかるだろう。でも、どの方向を見ても、近くを見れば見るほど、ほとんどどこにでもあるのは確かだ。

正直なところ、OOXMLはまるで誰かが非XMLフォーマットを取って、XMLエンコーディングを与えたように見える。XMLはマークアップ言語だから、テキストフォーマット作業にはかなり「自然に」交互に配置されるべきなんだ（つまり、OpenDocumentの例や超シンプルな「古典スタイル」のHTMLを見てみて）。でも、OOXMLはまるで誰かが生のOOPオブジェクト階層を強制的にシリアライズしたように見える。循環参照や多くのサブクラスがあって。要するに、テキストエディタが内部でフォーマットされたテキストを表現する簡略化された形に似ている。w:rはテキストセクションのように見えるし、言ってしまえば、幅広の文字や単語の行のように見える。w:pは暗黙の型のサブクラスのように見えて、基本的にはVecだし、w:pPrはw:pの「プレゼンテーション」プロパティのように見える。同様にw:rPrもそうで、たぶん両方とも一般的なプレゼンテーションの基底クラスのサブタイプだ。w:tは一般的な.text: Stringプロパティのように見える。w:pStyleはプレゼンテーションのプロパティか、その段落プレゼンテーションのサブクラスのプロパティのように見えるし、w:valプロパティは「Para」というキーで参照できる共有リファレンスのように見える。w:bは、どんなコンテキストでも使えるプレゼンテーションの別のサブクラスだ。これで「彼らは内部アプリの状態をほとんどそのままダンプしているのか？」という疑問が生まれる。彼らは自分たちのフォーマットをそんなに複雑で「過剰」に柔軟にして、内部構造を変えてもダンプできるようにしたのか？それなら、約10年前の初期OOXMLの頃に自分たちの標準を「偶然」に間違って実装した理由も説明できるし、そうだとしたら、OOXMLは本当にオープンフォーマットではなく、ただの「見せかけ」のものだという「証拠」にならない？

同じ時期に、Word用のWordProcessingMLみたいな他のバリエーションもいくつかあったよ。https://en.wikipedia.org/wiki/Microsoft_Office_XML_formats