現在、EXIを扱っています。
EXI を処理するための優れた汎用ツールはありません。EXI の中身を理解すると、バイナリ ストリームに不要な区切り文字がたくさんあることがわかります。これらは、スキーマでは絶対的かつ完全に不要です。それのいくつかはユーモラスです。
両方の値が指定されている場合、以下は EXI でどのようにエンコードされると思いますか?
<xs:complexType name="example">
<xs:sequence>
<xs:element name="bool1" type="xs:boolean" minOccurs="0" />
<xs:element name="bool2" type="xs:boolean" minOccurs="0" />
</xs:sequence>
</xs:complexType>
最大4ビットだと思いますか？bool1 が定義されているかどうかを示す 1 ビット、および bool1 の値と、bool2 が定義されているかどうかを示す別のビットが続く場合、bool2? の値
いいよね！
さて、男の子と女の子に教えてあげましょう！これが実際にエンコードされた方法です
+---- A value of 0 means this element (bool1) is not specified,
| 1 indicates it is specified
|+--- A value of x means this element is undefined,
|| 0 means the bool is set to false, 1 is set to true
||+-- A value of 0 means this element (bool2) is not specified,
||| 1 indicates it is specified
|||+- A value of x means this element is undefined
|||| 0 means the bool is set to false, 1 is set to true
||||
0x0x 4 0100 # neither bools are specified
0x10 8 00100000 # bool1 is not specified, bool2 is set to false
0x11 8 00101000 # bool1 is not specified, bool2 is set to true
100x 9 000000010 # bool1 is set to false, bool2 is not specified
110x 9 000010010 # bool1 is set to true, bool2 is not specified
1010 13 0000000000000 # bool1 is set to false, bool2 is set to false
1011 13 0000000001000 # bool1 is set to false, bool2 is set to true
1110 13 0000100000000 # bool1 is set to true, bool2 is set to false
1111 13 0000100001000 # bool1 is set to true, bool2 is set to true
^ ^
+-encoding--+
Which can be represented with this tree
0-0-0-0-0-0-0-0-0-0-0-0-0 (1010)
\ \ \ \ \
| | | | 1-0-0-0 (1011)
| | | |
| | | 1-0 (100x)
| | |
| | 1-0-0-0-0-0-0-0-0 (1110)
| | \ \
| | | 1-0-0-0 (1111)
| | |
| | 1-0 (110x)
| |
| 1-0-0-0-0-0 (0x10)
| \
| 1-0-0-0 (0x11)
|
1-0-0 (0x0x)
どちらも定義しないための最小 4 ビット。デリミタを含めているため、少し不公平です-まったく不要なデリミタ。
私は今、これがどのように機能するかを理解しています。仕様は次のとおりです。
https://www.w3.org/TR/exi/
それを読んで楽しんでください！とても楽しかったです!!!!@@##!@
現在、これはスキーマのみを使用しており、EXI 仕様では、スキーマに準拠していない XML をエンコードできると具体的に述べています。これは、小さな小さな Web デバイス用であると想定されているため、陽気です。組み込みデバイスで処理する準備が整っていない予期しないデータをどうしますか?
もちろん、あなたはただ死ぬだけです。予期しないものに対する回復はありません。これらに画面があるわけではないので、シリアル ポートからログインできれば幸いです。
4 つの異なる XSD ジェネレーター/パーサー/XML ジェネレーターを使用しました。そのうちの 3 人は、私が使用しなければならないスキーマで窒息します。C および C++ のデータ マーシャリング (メモリと CPU パワーが非常に少ない EMBEDDED システム用であることを思い出してください) はひどいものです。
XSD は基本的に構造またはクラス アーキテクチャを記述しますが、クラスを作成するだけのツールは 1 つもありません。上記の XSD の例では、4 つのブール値を持つ構造体を作成する必要があります。2 つのブール値は値であり、2 つのブール値はそれらが定義されているかどうかを示します。
しかし、それは存在しますか？いやいや。
ドキュメントを記述するための XML が好きです。本当にそう思います - しかし、XML について私が嫌いな点はここにあります - 広く採用されている標準に対して、利用可能なツールはまったくひどいものです。スキーマが複数の名前空間とドキュメントにまたがっている場合、スキーマを読み取るだけでは困難です。
暴言、ハフハフ
私たちがこれを使用している唯一の理由は、標準化委員会がそれを主張したからです。それが行ったことは、すでにこれを実装している少数の企業グループの独占を作成することです。それが唯一の目的です。
EXI は広く採用されている標準ではなく、XML は数値データのカプセル化には不十分であり、XML を実装するのは面倒であり、適切なツールはありません。EXIP はバージョン 5.0 です - オープン ソースで動作するものはすべて Java です - 少なくとも私はそれを持っています。
私の仕事の分野では、EXI は単に悪い設計上の決定です。私は、さまざまな組み込みシステムで大量の通信プロトコルに取り組んできました。私は、最新のすべてのケーブル モデムが使用する DOCSIS に取り組みました。認識されていないタイプを処理するための規定を備えた、シンプルで拡張可能な Type/Length/Value プロトコルを使用します。これが、Length が常に含まれる理由です。スタック全体を実装するには文字通り数日かかります。
EXI はコードを扱うのが非常に難しく、適切なプロセッサがありません。最悪の場合、実際にそれでうまく動作することがわかったプロセッサはすべて、EXI<->XML から変換するだけです。これはまったく役に立ちません。
私は独自の XSD パーサーを作成することに頼りました。つまり、少なくとも XML 仕様を使用するこの設計の部分について、XML 仕様全体を理解する必要があります。合理的な仕様で2週間かかるところを、10時間かかりました. 私の世界では、喉に押し込まれない限り、これを使用する人はいません.