Re: [Cacao] [EXT] Re: [EXT] RE: Charter

[Bret Jordan <[e-mail]>]

Thanks Carsten for pointing this out.. Please replace the following terms based on:

~=s/string/strings/g
~=s/integer/number/g

Also, we may define an “integers” property in the spec that uses the JSON numbers type. But that the spec itself limits the value to be an integer. 


Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

> On Jun 20, 2019, at 2:44 PM, Carsten Bormann <[e-mail]> wrote:
> 
> On Jun 20, 2019, at 14:06, Bret Jordan <[e-mail]> wrote:
>> 
>> The data model will consist of a series of property tables that are defined using JSON data types. 
> 
> JSON does not define that many data types (copied exactly from RFC 8259:
>   3.  Values  . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
>   4.  Objects . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
>   5.  Arrays  . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
>   6.  Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
>   7.  Strings . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
> “Values” includes the “three literal names” false, null, and true beyond the other four).
> 
> The example you just gave already shows that this is a bit limited:
> 
>> Example:
>> 
>> Property Name              | Type    | Description 
>> name (required)            | string  | The name of this action 
>> created (required)         | string  | The time that this action was created in RFC 3339
>> sequence_number (optional) | integer | The number ….. 
> 
> There is no such thing as an integer in JSON, so that is your own extension (JSON only has numbers).  If you think integers in JSON are a thing, you’ll be unpleasantly surprised at some point (the large number of surprises in this space led to RFC 7493).
> 
> Also, you seem to feel a need to qualify the second string as “RFC 3339”, which pollutes the “description” column with type information.
> (And what you wrote is very inexact, compare with “format described by the `date-time` production in {{RFC3339}}, as refined by Section 3.3 of {{RFC4287}}”, which is what turned out we needed to write in a similar context.)
> 
> If you want to stick with tables instead of machine-readable form, I’m not going to argue against that right now(*).
> I would still propose that you at least define the types used in these tables in a more well-defined way.  (RFC 8610 would work just about right for me here, but my point is more general: you want to have more structured information about the types employed, and you don’t want to mix it in, in an uncontrolled way, into the description.)
> 
> Grüße, Carsten
> 
> (*) In the long run, you will generate these tables from machine readable form.  
> But this discussion isn’t at that level of detail right now…
>