I'm not sure that we want to customize JSON that significantly. I am
thinking that we should currently do #1 (allow the consumers to
use/abuse the string type to do this) which is no change.
If we are talking about doing this much customization to the JSON, we
should be talking seriously about just switching to a protocol that is
better suited to our needs.
On Thu, 2015-04-30 at 13:07 -0700, Thiago Macieira wrote:
> On Tuesday 28 April 2015 12:29:30 Thiago Macieira wrote:
> > Two options I can think of here:
> >
> > 1) accept it and punt the problem to a higher level of the stack. The user
> > of OCRepresentation needs to check what the encoding of the payload was so
> > they can decode the base64url back into binary data.
> >
> > 2) "augment" JSON with metadata. For example:
> >
> > {
> > "field1": "AAEjRQo", "$field1": "binary",
> > "field2": "/a/light", "$field2": "url",
> > "field3": "2015-04-28 12:23:11-07:00", "$field3": "datetime",
> > "field4": "Hello World"
> > }
> >
> > Another format:
> >
> > {
> > "field1": "@binary:AAEjRQo",
> > "field2": "@url:/a/light",
> > "field3": "@datetime:2015-04-28 12:23:11-07:00",
> > "field4": "Hello World"
> > }
> > [this would require escaping the string if it does begin with @]
>
> Any reactions?
>
> CBOR has a way to tag types, but the repertoire is also limited. See the
> table
> at <http://tools.ietf.org/html/rfc7049#section-2.4>.
>
