Re: [Cbor] cbor-packed: Circumfix expansion

[Carsten Bormann <[e-mail]>]

https://tools.ietf.org/html/draft-bormann-lpwan-cbor-template-02

is the most general form of this that I have written up.
This assumes that the SCHC environment does the referencing, so it only defines the referee (template), not the referent (invocation).
The example has only one parameter, but could have more.

Can we package that in a way that is useful for cbor-packed?

(I do see the complexity issue.)

Grüße, Carsten



> On 2021-02-01, at 12:57, Christian Amsüss <[e-mail]> wrote:
> 
> Hello Carsten, hello CBOR group,
> 
> it occurred to me that a variant of compression is unexplored. Suppose
> we have data like (please mentally replace strings with appropriate
> numbers) in SenML assuming draft-groves-core-senml-bto:
> 
> [{"bn": "urn:dev:ow:X", "bu": "V", "v": 1.992, "t": 1.6e9, "bto": 2},
> /* bto indicates all the following items are offset by 2 seconds each */
> {"v": 1.986},
> {"v": 1.874},
> {"v": 1.423},
> ...
> ]
> 
> It'd be tempting to write that as
> 
> TBD51([{"v": TBD(0)}], [], [],
>  [{"bn": "urn:dev:ow:X", "bu": "V", "v": 2.047, "t": 1.6e9, "bto": 2},
>   TBD6'(
>     5([-7, 64(h'feefb6...')]) /* [0xfe, 0xef, 0xb6, ...] x 2^-7 */
>   )])
> 
> which is combining bigfloats and arrays (if they, on their own, can they
> be combined that way; otherwise one might be tempted to use second-table
> units) to expand to
> 
> TBD51([{"v": TBD(0)}], [], [],
>  [{"bn": "urn:dev:ow:X", "bu": "V", "v": 2.047, "t": 1.6e9, "bto": 2},
>   TBD6'(
>     [1.986, 1.874, 1.423]
>   )])
> 
> and then would use circumfix expansion (a variant on the shared item)
> to expand the array into the original one-element dictionary sets. The
> rough rule could be that when the nth circumfix expansion is triggered,
> the rump is iterated over expanded into the nth shared item (or picked
> from another table -- details) with its occurrence of a given tag TBD
> replaced with the rump's item at that position.
> 
> One straightforward application is like in the example -- generating
> repetitive entries from data that can be sent right from some sampling
> buffer by using typed arrays.
> 
> The straightforward reason not to do this is that it's more complex even
> on the decompressor (let alone on the compressor, but that might usually
> use manual compression anyway).
> 
> I'm not saying we *should* do this (that's what I hope to get from
> starting discussion here) -- but if nothing else, it could help shape a
> "what kind of compressions are in scope and what's out of scope"
> paragraph.
> 
> BR
> Christian
> 
> -- 
> To use raw power is to make yourself infinitely vulnerable to greater powers.
>  -- Bene Gesserit axiom