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

Re: Introducing CBOR-LD...

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Fri, 24 Jul 2020 10:34:15 -0400
To: public-credentials@w3.org
Message-ID: <a3899cdb-30a1-f369-8bf8-a627d41dfbdc@digitalbazaar.com>
On 7/23/20 10:22 PM, Liam R. E. Quin wrote:
> How does it compare to using EXI?  (server-side parsing with a
> compressed parsee event stream)

Just like all compressions schemes, there are many similarities...
encoding tags as bytes, building a compression dictionary for tags and
values, optimizing for streaming, etc..

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 resulting in larger
  data sizes, CBOR-LD builds it's compression dictionary
  using a stable external resource. This matters for very
  small payloads < 1KB in size.

* 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.

Other than those two (key) items, there are a lot of similarities
between CBOR-LD and just about any other structured data format
compression technique. For example, you can apply LZ-compression
(gzip/Deflate) on top of CBOR-LD and get further compression for
repeated binary/string values... IF you have repeated content in your
data (like a DID Document would).

-- manu

[1]
https://docs.google.com/presentation/d/1ksh-gUdjJJwDpdleasvs9aRXEmeRvqhkVWqeitx5ZAE/edit#slide=id.g866980c4a6_2_146

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches
Received on Friday, 24 July 2020 14:34:29 UTC

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