Re: [apps-discuss] Concise Binary Object Representation (CBOR)

[Nico Williams <[e-mail]>]

On Thu, May 23, 2013 at 2:42 PM, Phillip Hallam-Baker <[e-mail]> wrote:
> On Thu, May 23, 2013 at 12:13 PM, Nico Williams <[e-mail]>
> wrote:
>> I do agree that we need a schema-less encoding (which means we can't
>> get as good as PER and friends).  We probably don't need a
>> schema-capable encoding for JSON (though that might be nice).  We do
>> need schema-aware encodings for some protocols, but we have plenty
>> already, and none are nor need to be JSONish.
>
> What I think you intend here is that the encoding should not be
> schema-aware. Whether or not you have a formal schema is not the issue here,
> the issue is whether it is necessary to know the schema to make sense of the
> wire format.

Indeed, I meant that the encoding doesn't require a schema.  A schema
may still be used by the app, of course, but the codec has no
knowledge of if, and in particular the decoder cannot be required to
have knowledge of the schema.

> One of the main reasons that JSON and XML encodings are attractive is that
> you can look at the wire format and make sense of them. ASN.1 BER encoding
> can also be read with an appropriate dump tool. It has to be possible to do
> the same with Binary JSON.

Well, they make some sense.  Documentation really helps though :)

(And BER... can be dumped, but when implicit tagging is used you lose
plenty of type metadata and have to resort to heuristics.)

> Some of the compact XML representations used knowledge of the schema to
> improve packing density and some could be read using a dump tool but
> required knowledge of the mapping from the text representation to the binary
> to be able to convert from one to the other.

Right, like FastInfoSet (which uses PER).

> I think it is clear that any JSON binary coding has to be readable without
> knowledge of a schema and that a non-schema aware tool must be able to
> convert between the two formats.

Yes.  If we need further compression then use zlib or similar.

> Insisting on a single representation for a number seems much less important
> to me. Whether 7 is represented in one, two, four or eight bytes seems to me
> to be something that can be left to the implementations.

I agree that it's less important, and I won't insist on it.  It's just
a mild irritant to not have c14n, but maybe it's just me and I should
get over it for good.

Nico
--