Thanks Stephen, One important message from EXI developers/community that is not mentioned there is: “Use EXI only when it is found absolutely necessary. Instead, use XML more.” Takuki Kamiya Fujitsu Laboratories of America From: Stephen Cameron [mailto:steve.cameron.62@gmail.com] My EXI ignorance is even less excusable! EXI is explained to potential users very well here: On Tue, Jun 10, 2014 at 10:22 AM, Takuki Kamiya <tkamiya@us.fujitsu.com> wrote: I’d like to set the facts straight on EXI, which is W3C’s standard binary representation of XML. EXI, by default, does not leverage redundancy-based compression such as DEFLATE. EXI more often than not surpass ASN.1 PER’s utility, and it was not possible if compression was mandatory in EXI because compression not only is useless for very small documents (i.e. < 100 bytes) but also often it even increases sizes for small documents. The optional (in the sense of use) feature of EXI, “EXI compression” integrates not at the mere byte sequences, but into EXI's grammar system. This makes EXI compression a lot more efficient than gzip both in terms of compactness and processing efficiency. EXI compression feature has a parameter "block size" configurable for each document. Block-size is the number of XML events that are collectively used as a chunk in EXI compression. Setting the right block-size value makes it amenable for streaming use cases. EXI uses a schema-informed grammars for its grammar system. You can deviate from schema in any way you want, EXI can still process those documents. Schema in its entirety is optional, and EXI’s self-calibrating built-in EXI grammars can process schema-less documents very efficiently. Lastly, parsing EXI does not involve a separate step of decompression. Parsing EXI is one step regardless EXI compression feature is leveraged or not. Thanks, Takuki Kamiya Fujitsu Laboratories of America From: Stephen Cameron [mailto:steve.cameron.62@gmail.com]
Having EXI should have solved such issue but did not. As I understand its more a compression format and needs to be decompressed for parsing. On Tue, Jun 10, 2014 at 12:31 AM, Simon St.Laurent <simonstl@simonstl.com> wrote: On 06/09/2014 10:24 AM, Costello, Roger L. wrote: Loac says that a data format should have these properties: For my purposes, binary imposes more costs than benefits. I don't give a damn about types, but extensibility is crucial.
The first signs I saw of trouble for XML were all around that conversation, as I got into the mapping space. At that point, XML's doubling or tripling the cost of storage was a problem. Today it's more about bandwidth.
|