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@g...]
Sent: Monday, June 09, 2014 3:52 PM
To: Simon St.Laurent; xml-dev@l...

Subject: Re: Percentage of web services supporting XML versus JSON

 

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.

http://www.w3.org/XML/EXI/

 

On Tue, Jun 10, 2014 at 12:31 AM, Simon St.Laurent <simonstl@s...> wrote:

On 06/09/2014 10:24 AM, Costello, Roger L. wrote:

Loac says that a data format should have these properties:

        - Hyperlinks and link relations
        - Binary, explicit sizes, efficient to parse
        - Small, exponentially smaller the larger the data gets
        - Good type coverage, extensible
        - No NULL value
        - Fully specified

Do you agree with those properties? Would you add other properties? Would you remove some of the properties?

 

For my purposes, binary imposes more costs than benefits.  I don't give a damn about types, but extensibility is crucial.

The piece that's deeply intriguing here, though, is:

"Small, exponentially smaller the larger the data gets"

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.

If there's a way around that, it's a HUGE selling point.

Thanks,
Simon

 

-----Original Message-----
From: Simon St.Laurent [mailto:simonstl@s...]
Sent: Monday, June 09, 2014 10:00 AM
To: xml-dev@l...
Subject: Re: Percentage of web services supporting XML versus JSON

Okay - Loic's talk is up, though he's in the middle of a conference.

<http://ninenines.eu/talks/bed/bed.html>

Why Not JSON? is slide 19. Why Not XML? is slide 22.

He sketches out his (binary) alternative from 23 on.  I want to see a
lot more detail, but I wish this had existed a decade ago if only for
conversational use.

Thanks,
Simon



On 06/09/2014 09:49 AM, Simon St.Laurent wrote:

On 06/09/2014 09:44 AM, Costello, Roger L. wrote:

Loic says that JSON is "a terrible format" because:

I am so confused to see JSON defended on xml-dev... ;)

I'll check in with Loic and see what he's actually proposing, then try
to bring something more complete back here.

Thanks,
Simon

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php