Re: [Cbor] 🔔 WGLC with request for reviews on cbor-cddl-control-03

[Carsten Bormann <[e-mail]>]

Hi Christian,

> On 2021-06-16, at 12:24, Christian Amsüss <[e-mail]> wrote:
> 
> Signed PGP part
> Hello Carsten, hello CBOR group,
> 
>> The biggest confusion was created in one case where part of the spec
>> said
>> 
>> 	.feature “1.1”
>> 
>> while another said
>> 
>> 	.feature 1.1
>> 
>> (yes, the floating point number.)
>> The cddl tool treats these as different features (which they obviously
>> are), but generates exactly the same output for these.
>> 
>> This led to a little goose hunt…
> 
> The current draft text describes the features to "usually be a string",
> ands adds that arrays can make sense too.
> 
>> So my provisional thinking is that this should be handled by better
>> tool support and maybe adding a little warning text in the draft.
> 
> The text sounds good to me; a message produced by the tool ("Warning:
> CDDL feature {} is neither a string nor an array. This is allowed but
> unusual.") should catch floating features before they come into use.

Good point; a warning has been added in 0.8.25.

>> [on .det ]
>> 
>> Well, after some use it turns out that it is much more likely that one
>> needs both sides dedented, so maybe we switch to this [...]
> 
> This really sounds to me like it should be a unary control. We
> don't have them, so either of the current proposals is viable for me --
> but playing a bit with the unary control (more spitballing than actually
> suggesting): We *can* have empty groups on the RHS, right?

Unfortunately, the RHS needs to be a type (as does the LHS).
That is a limitation of control operators; they operate on types only.

> So could we
> emulate unary operators by adopting a method-call-like pseudosyntax?
> 
>  cbor-tags-oid = '
>    oid = 1*arc
>    roid = *arc
>    arc = [nlsb] %x00-7f
>    nlsb = %x81-ff *%x80-ff
>  ' .det ()

(Even [] doesn’t work with the current tool as .det complains about its RHS not being a string.  Creating a special case just so we can avoid ‘’ or “” doesn’t strike me as a great solution.)

> would read like any other language's method call. Granted, the same
> parallel would be seen as terribly confusing, and
> 
>    cbor-tags-oid-decrypted = cbor-tags-oid .det () .rot13 ()

Control operators are non-associative, so you'd have to spend a few pairs of parentheses, which give you control over:

> as I understand wouldn't even make the dedented text available to the
> obfuscating rot13 control.

Grüße, Carsten