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

[Bret Jordan <[e-mail]>]

In regards to the timestamp, please understand I was just giving an example, not _actual_ spec text. I could see us defining a “timestamp” type and then saying that the “timestamp” type is an ISO 8601 / RFC 3339 timestamp that follows some very specific rules.  Just as an example.  Then in the property tables we should use “timestamp” instead of “strings”.  

I am not against also building a CDDL definition for this in an appendix or separate document.  But as of yet CDDL is not used en mass and there are not very many tools (other than your really cool ruby tools).  So for now it would be best to use property tables since that is what people understand today.


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…
>