Re: [Cbor] Reminder and call for agenda: CBOR WG Virtual Meeting on 2022-06-01

[Christian Amsüss <[e-mail]>]

Hello Carsten,

thanks for the text, it adds important functionality.

> When reconstructing the original data item, such a reference is
> replaced by a data item constructed from the argument data item found
> in the table (argument, which might need to be recursively unpacked
> first) and the rump data item (rump, again possibly recursively
> unpacked).

This reads a bit like also the rump would be recursively unpacked first.
Is that the intention? (I think not -- with my understanding of
unpacking so far, the rump would be unpacked at the time it is
encountered in the reconstructed item, allowing the argument to alter
the dictionary).

> [...]; a type-0 reference is either a prefix reference or a
> type-0 function reference, while a type-1 reference is either a
> suffix reference or a type-1 function reference.

I find the type-0/type-1/"dominating tag" concept rather hard to
understand. It's neat how it allows symmetry between reference and
argument (which is especially pronounced when prefix/suffix becomes
concatenation), but I'm unconvinced that that symmetry is worth the
cognitive / implementation load of doing it that way, or even generally
present. (One can always swap the arguments of a two-argument function,
but not for all functions either argument makes sense in a dictionary).

Alternatives I'd like to suggest for consideration:

* Maybe the mechanism described in the branch can be explained in an
  easier-to-digest way. It may or may not become simpler by either of

  * giving names to the two arguments the of the function (arg1, arg2?
    A, B? tagged, other?)
  * calling prefix/suffix just "concatenation" (arg1 | arg2) and not
    treating it as an extra case but as the default

* Use a bit more separate tags for where there is real need for having
  both directions. (No type-0/type-1 distinction, and having the
  tag-that-indicates-function always in the dictionary. For string/array
  postfixes that'd need a tag already at dictionary setup).

* Decoupling the functions a bit more from the compression, and using a
  more general mechanism to fill them.

  There might not be much point in having `109(["example.com",
  ["https://", "/foo".html"]])` around explicitly in any document, but
  in a generalization the tag could mean "string-join arg2 with arg1",
  and all of a sudden `109([",", ["1", "2", "3"]])` or even `109([",",
  64('123')])` could be usable more generally even outside packing.

  In packing, they'd be used as

  ```
  113([[],
    [109(["packed.example", ARG])],
    [6(["https://", "/foo.html"]),
     ...
    ]
  ])
  ```

  or (in the other example's style)

  ```
  113([["packed.example"],
    [],
    [109([6(0), ["https://", "/foo.html"]]),
     ...
    ]
  ])
  ```

  (The first example here does beg the question the 'put the argument in
  here' placeholder ARG is best phrased; I don't have any definite
  answer here yet, but maybe it makes sense to shift up the index space
  inside the argument-item space by 1 and make 6(0) the argument --
  although that might be similarly hard to teach as type-0/type-1.)

BR
Christian

who is wondering whether indefinite-length strings / bytestrings really
needed to be in the original CBOR spec, or would not have been better
served with a "concatenate" tag around an indefinite-length array.

-- 
You don't use science to show that you're right, you use science to
become right.
  -- Randall Munroe