[pvg]

I'm curious what drove decisions like no top-level arrays and strict conditions on set members. It's not mentioned explicitly in the spec but if the object syntax is the same as JSON, multiple field names would be allowed in that case.

[bascule]

TJSON requires arrays be homogenous, and this is presently accomplished by specifying the types of arrays up-front in object member names and rejecting the array if any of the contents don't adhere to the type signature.

With toplevel arrays, in absence of this type information being explicitly specified in an object, implementations would have to rely on detecting homogeneity at decode time.

This is certainly possible, and in fact the serialization logic does it. But it seems like a sharp edge to include in deserialization logic in a security-oriented format. The format aims to keep the deserialization logic free of any sort of "guesswork".

[pvg]

Ah of course, you need the names to specify types, that makes sense. And by the same no-ambiguities token, presumably repeated names in an object would be rejected by the parser.

[bascule]

> And by the same no-ambiguities token, presumably repeated names in an object would be rejected by the parser.

Correct:

https://github.com/tjson/tjson-spec/blob/master/draft-tjson-... https://www.tjson.org/spec/#rfc.section.3.8