世界を動かす技術を、日本語で。

マイクロソフトオフィスはロックインツールとして人工的に複雑なXMLスキーマを使用している

概要

  • ドキュメントフォーマット は知識共有のための手段であり、内容の複雑さに応じて シンプルかつアクセスしやすい べきである。
  • XMLスキーマ は理論上相互運用性を実現するが、実際には 意図的な複雑化 がロックイン戦略として利用されることが多い。
  • Microsoft 365 のドキュメントフォーマットは、開発者にとって実装困難なほど複雑である。
  • 技術的ロックイン によって、ユーザーや組織は選択肢を失い、結果的にベンダーに従わざるを得なくなる。
  • シンプルさと明確さ が自由をもたらすという教訓。

ドキュメントフォーマットの複雑性とベンダーロックイン

  • ドキュメントフォーマット の本質は知識共有手段であり、 内容の複雑さ に見合ったシンプルさとアクセス性が必要。
  • XMLスキーマ は、画面上では隠されている場合でも、内部的には構造・データ型・ルールを定義する仕組み。
  • XML Schema Definition (XSD) ファイルによる厳格なデータチェック機能。
  • 理論上は XMLとXSD の組み合わせで相互運用性を実現可能。
  • 実際には、 不必要な複雑化 によって実装が困難となるケースが多発。

人為的な複雑化の特徴

  • タグ構造の過剰なネスト と抽象化。
  • オプション要素やオーバーロード要素 が数十から数百存在。
  • 直感的でない命名規則 の多用。
  • 拡張ポイントやワイルドカード の乱用。
  • 名前空間や型階層 の多重インポート。
  • ドキュメントの量が膨大 (Microsoft 365の場合は8,000ページ超)。
  • 開発者にとって 実装がほぼ不可能 なレベルの複雑性。

Microsoft 365におけるロックイン戦略

  • Microsoft 365 のドキュメントフォーマットは、意図的な複雑化によるロックイン戦略の典型例。
  • 鉄道システムの例え: 線路は誰でも使えるが、制御システムが複雑すぎて主メーカーしか運用できない 状況。
  • 利用者(パッセンジャー)は、 技術的制約に気付かず、結果的に主メーカーの条件を受け入れざるを得ない。
  • Windows 10からWindows 11 への強制移行も同様のロックイン事例。
  • 技術的な正当性がない移行 による顧客囲い込み。

独占とその影響

  • プロプライエタリ技術 への無批判な依存が、ユーザーや組織をロックイン状態に導く。
  • 数百万のMicrosoftユーザーが 批判的な視点を持たなかった ことが、現在の状況を招いた要因。
  • 政府機関や国際機関 までもがロックイン戦略を許容。
  • Microsoft 365のXMLスキーマ が戦略的な役割を果たしている現状。

XMLベースシステム選定時の注意点

  • 複雑性は人々を束縛し、シンプルさと明快さが自由をもたらす という原則。
  • XMLベースのシステム開発や選定 時には、複雑性の罠に注意する必要性。

Hackerたちの意見

この人、XMLシリアライザーのことわかってないのかな…?

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

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

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

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

残念ながら、XMLスキーマはシンプルな場合もあれば、不必要に複雑で、膨れ上がって、難解で、特定の機能の知識がないと実装が難しいこともあります。今、そのままの文を使って、最も人気のあるオープンドキュメントフォーマットであるHTMLとCSSを説明することもできるでしょう。

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

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

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

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

これは面白い視点だね。私はコアバンキングAPIにどっぷり浸かっていて、WSDL/XSDからサービスリファレンスを生成してるんだけど、生成されるコードの中には数十メガバイトになるファイルもある。ドキュメントのページ数を数えるなんて無理だよ。これはアメリカの中規模なバンキングドメインの話だからね。Microsoft Officeは文字通りどこでも、何にでも対応しなきゃいけない。8000ページのドキュメントがあるだけでも奇跡だと思う。XSD形式のXMLスキーマを使っているなら、コード生成が最適(唯一の)方法だよ。古くて新しい世代には混乱を招くのは理解できるけど、昔ながらのやり方でやれば、15分くらいで仕事が終わるよ。XMLインターフェースに手書きでコードを書くのは、電源が入ってない丸鋸で板を切るようなもんだ。

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

Hacker Newsで議論の続きを見る