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

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

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.

> [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? 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 ()

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 ()

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

BR
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom