W3C home > Mailing lists > Public > public-credentials@w3.org > July 2020

Re: Introducing CBOR-LD...

From: Liam R. E. Quin <liam@fromoldbooks.org>
Date: Fri, 24 Jul 2020 11:32:57 -0400
Message-ID: <defb611273060123b152e4b71c8751ffbbff9e0f.camel@fromoldbooks.org>
To: Manu Sporny <msporny@digitalbazaar.com>, public-credentials@w3.org
On Fri, 2020-07-24 at 10:34 -0400, Manu Sporny wrote:
> Here are just a few of the differences that I know of between EXI and
> CBOR-LD (you'll have to forgive me, I'm not an EXI expert):


> * EXI embeds its compression dictionary 

yes, although it's pre-filled froman external schema where available.
Very small packets was an EXI use case - IoT uses EXI.

> * EXI doesn't attempt to compress data, CBOR-LD will do
>   compression for values it understands. For example,
>   EXI will put DateTimes "2018-04-12T14:23:13Z" (39 bytes with
>   tag in XML) in a compression dictionary WITHOUT converting
>   them to binary formats, where as CBOR-LD will
>   compress that down to a 7 byte binary value... a 557%
>   compression ratio. See[1], slide 14.

This is not in general true - data model types can be transmitted in
binary - and tags are not transmitted where they can be deduced. In
fact, tags are not transmitted at all with EXI, as what is transmitted
is parse events, the *result* of parsing. As a result, less memory is
needed to decompress an EXI stream than for example zip.



Liam Quin, https://www.delightfulcomputing.com/
Available for XML/Document/Information Architecture/XSLT/
XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
Barefoot Web-slave, antique illustrations:  http://www.fromoldbooks.org
Received on Friday, 24 July 2020 15:33:33 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:01 UTC