Edit

Page

Page title:

Page body:

[1] [DFN[[RUBYB[バイナリー]@en[Binary]] XML]] は、[[XML]] の[[バイナリー]]表現のことを指します。
[[テキスト]]ベースの[[マーク付け言語]]としての [[XML]] をそのまま用いるのではなく、
転送や構文解析の効率の良い[[バイナリー]]表現が好ましいと考えられる分野もあり、
様々な[[バイナリー]]表現が検討・提案されてきました。最終的には [[W3C]]
が [[EXI]] を標準化するに至り (そこに至るまで一体何年かかったのか)、
汎用的な [[XML]] の[[バイナリー]]表現の決定版と考えられていました。

[5] しかし、 [[XML]] を[[バイナリー]]で表現すること自体は一般的にはならず、
分野ごとに限定的に用いられたのみでした。[[バイナリー]]表現を取り入れていた分野では
[[EXI]] に移行するメリットがあったのかどうかは怪しく、 [[EXI]]
がどれだけ広く用いられたのかはよくわかりません。

[6] いずれにせよ、 [[XML]] 自体が廃れてしまったので、[[バイナリー]]表現形式も現在ではほとんど使われていません。

* 代替

[7] [[バイナリー]]形式の[[データ]]の交換には、 [[XML]] を使わない
[[Thrift]]、[[Protocol Buffers]]、[[MessagePack]]、[[CBOR]] などが用いられています。
これらのデータ形式の方がより[[プログラミング言語]]の[[データ構造]]に近かったり、
[[プログラミング言語]]の[[ライブラリー]]が整備されていたりして、
使いやすそうです。

* XBC

[4] [[EXI]] の仕様策定に先立って [[W3C]] の [[XBC WG]] において[[バイナリーXML]]の要件と性質が整理されています。
[[XBC]] の項を参照してください。

* バイナリー XML 仕様の一覧

[2] [[バイナリーXML]]を実現する仕様はたくさんあります。これらの中には [[XML]] 本体だけでなく、
[[XML名前空間]]や [[XML Schema]] の一部の機能も含まれていることがあります。逆に [[DTD]]
など [[XML]] 本体の機能で含まれていないものもあります。

[FIG(short list)[
- [[EXI]]
- [[BiM]]
- [[Fast Infoset]]
- [[Efficient XML]]
- [[EBML]]
- [[WBXML]]
]FIG]

* 関連

[8] [[XOP]] のように [[XML]] 自体は変更せず[[添付ファイル]]のような形で[[バイナリー]]データを扱うものもありました。

[9] より単純に [[Base64]] で [[XML]] に[[バイナリーデータ]]を埋め込むこともよくあります。

* メモ

[3] [CITE@en[Binary XML - Wikipedia, the free encyclopedia]] ([TIME[2013-09-17 20:26:59 +09:00]] 版) <https://en.wikipedia.org/wiki/Binary_XML>

[FIG(quote)[
[FIGCAPTION[
[10] [CITE@en[設定ファイルの仕様 | COCOA Open Source Project]]
([TIME[2021-11-25T07:16:26.000Z]], [TIME[2021-11-30T09:43:35.165Z]])
<https://cocoa-mhlw.github.io/cocoa/docs/appendix/preference_specification/#v100---v121>
]FIGCAPTION]

> 実体ファイルはBinary XML形式

]FIG]

[11] 
バイナリーXMLがなぜ失敗したのかって、思い当たる理由がいっぱいありすぎて逆に説明が難しいですよね。

[12] 
まあ当時から一部だけで盛り上がってて大多数の人は名前すら知らないみたいな感じだったしねえ。

[13] 
もともと
[[XML]] 
は[[テキスト]]で扱いやすいからと流行ってたところがあって、
それを[[バイナリー]]にしたいと思ってた人がそんなにいなかったというのが1つ。

[14] 
流行ってるからという理由でなんでも [[XML]] にぶっこもうとしてた人達がいて、
でもそうすると全部[[テキスト]]だと効率悪いことに気づいて、
じゃあ[[バイナリー]]化しよう、とかいうわけのわからない理由でバイナリーXMLが推進されてたのよね、
だから馬鹿馬鹿しいと思ってた人は食いつかなかった。

[15] 
[[XML]] は単体だと[[テキスト]]データの塊でしかないので、
[[バイナリー]]にしても[[構文解析]]の方法論が変わってくるくらいで、
正直あんまりメリットないんですよね。
だから[[バイナリーXML]]の提案や実現はどれも
[[XML]]
単体ではなくて [[XML Schemaデータ型]]などとセット売りになってる。
そうすると[[数値型]]とか諸々の[[データ型]]一式が入ってきて、
効率的にバイナリーデータ転送できるようになるから。
ところがそうすると簡単に使えるからと思って [[XML]]
を採用した人達は振り落とされてしまう。

[16] 
まあ流行ってるから何でも [[XML]] にぶっこもうとしてた人達は
[[XML Schema]] 万歳、
[[強い型付き]]万歳、
複雑プロトコルスタック万歳でやってたわけだから、
その[[プレゼンテーション層]]がバイナリー化されるくらい何でもないと思ってたのだろうけど

[17] 
まさかその複雑なプロトコルスタックのたくさんの技術がぜんぶ丸ごとなくなるとはさすがに思ってなかっただろうね。
あの [[XML]] の膨大な技術群とか、
全部で何個あるのか数え切れない [[WS-*]] とか、
作ってた人 & 使ってた人はいまどこで何してるんだろう。

[18] 
[[XML]] という前提がないと、バイナリーデータの効率的な転送手法っていくらでも転がってるし、
[[デジュール標準]]の世界にも [[ASN.1]] とか昔からあるわけだし、
わざわざ [[XML]] という枷をはめた[[バイナリーXML]]系のアーキテクチャーを選択する理由が何もないんですよね。
[[XML Schemaデータ型]]がなくても [[ASN.1]] データ型があれば十分だし。
ただ単にバイナリーデータをやり取りしたいだけのほとんどの[[プログラム]]にとっては、
好きなデータをそのまま転送すればそれで済むことだし。

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Errors

Page name(s)