Re: [Cbor] Some comments on cbor-cddl-05 and cbor-7049bis-02

[Carsten Bormann <[e-mail]>]

Hi John,

I’m still processing all your useful comments from the last message.
Here are quick answers for the new points:

On Sep 12, 2018, at 16:43, John Mattsson <[e-mail]> wrote:
> 
> Hi,
> 
> Two additional comments
> 
> /John
> 
> --------------------------------------------------
> 
> Should’t [], {}, and () be in Table 1?

These are not “operators” in the traditional sense.
But it might sense to include them in the table just for completeness.

> --------------------------------------------------
> 
> Would it be possible to allow the << >> notation also in CCDL? The CDDL notation for wrapping things in byte strings are very different from the diagnostic notation. Realising which diagnostic notation expressions matches bstr .cbor type1 and bstr .cborseq type2 are not obvious. I think that allowing the << >> notation in CDDL would make it easier for users of CDDL (e.g. writers of internet-drafts and developers). 
> 
> def1 = << int >>
> 
> def2 = <<
>   x: float,
>   y: float,
>>> 

This would definitely be possible.
There is a little snag in that it wouldn’t be clear whether a group or a type would be used, but we could go for the semantics of .cborseq always and just make use of the fact that when a group always creates a single entry the semantics is the same as for .cbor.
(The existing controls also allow the left hand side type to add some restrictions on the byte string, e.g., on their size; the new notation would not provide that capability.)

The reason we were happy to just introduce .cbor/.cborseq was that adding new syntax is more heavy weight for the spec; that new syntax as well as new matching rules would have been a larger change than just using the existing extension point (controls).  If people do agree this syntactic sugar is good, we could shoehorn it in.  (We are in IESG processing already, so a change of this size might create some delay.)

Grüße, Carsten