Re: [Json] Update Standard to support ECMA-262 BigInt

[Pete Cordell <[e-mail]>]

On 30/04/2021 21:53, Carsten Bormann wrote:
> On 30. Apr 2021, at 21:36, Daniel P <[e-mail]> wrote:
>>
>> Do you mean in the context of a schema specification?
> 
> CDDL (RFC 8610) can already do much of what is probably needed here.
> If there is anything else to be added, CDDL has an extension point (control operators) that is rather flexible.


Hi Daniel and Carsten,

I was speaking in very general and abstract terms.  More along the lines 
of "one could imagine that ..." with no specific work item in mind.

But....

Since you raise the issue of JCR vs CDDL, here are my thoughts...

Firstly, Carsten, do you or anyone else knows of any IETF WGs using CDDL 
to define JSON data?

As for what I think JCR offers that I don't think CDDL currently offers:

1.
JCR has a simple way to combine multiple rulesets.  In one ruleset you 
might have:

    #ruleset-id org.ietf.example1

    $foo = int32

Then in another ruleset:

    #import org.ietf.example1 as ex1

    {
       "id" : $ex1.foo
    }

Here, $ex1.foo refers to $foo defined in the ruleset with id 
org.ietf.example1.


2.
Although possibly not formally released, we were considering a way of 
declaring that a string had to adhere to an arbitrary format.  This was 
a way of adding additional string based types (as there is no other 
option in JSON for extended types!) without adding new base types (like 
int32, date-http etc).  So, in a ruleset you could specify something like:

    #ruleset-id org.ietf.extended-types

    $rfc2822-date-time =
          @{format org.ietf.extended-types.rfc2822.date-time} string

Then use it as:

    #import org.ietf.extended-types as iet

    {
       "start-time" : $iet.rfc2822-date-time,
       "end-time" : $iet.rfc2822-date-time
    }

The spec for the "org.ietf.extended-types.rfc2822.date-time" format 
might read something like:

    Formatted according to the RFC2822 date-time ABNF but omitting
    the trailing [CFWS] term.

So, "org.ietf.extended-types.rfc2822.date-time" is not machine 
resolvable to a specific format on its own.  It is just an opaque 
character string used as an identifier for the format.  A validator 
would either know about strings formatted according to 
"org.ietf.extended-types.rfc2822.date-time" (possibly via inbuilt hard 
coding or using some plugin arrangement) or just issue a warning saying 
I don't know what the format "org.ietf.extended-types.rfc2822.date-time" 
is so I'll check it is a string but leave it to other layers to verify 
that it is the right format.

Such a feature may not be something so useful for CBOR but I think it is 
very useful for JSON strings.

In conclusion, I need to revisit things in more detail, but currently my 
gut feeling is that if those sorts of features are supported in CDDL, it 
would be worth adopting CDDL for JSON format specification.  Primarily 
because it has a formally published spec!

Many thanks,

Pete.
-- 
---------------------------------------------------------------------
Pete Cordell
Codalogic Ltd
C++ tools for C++ programmers, http://codalogic.com
Read & write XML in C++, http://www.xml2cpp.com
---------------------------------------------------------------------