Well the erlang term format is strongly typed, so, why not? ^.^
But still, what kind of type checking would you prefer, and what style? Hmm, let me ask these questions (I know a lot of different formats):
Do you want a free-form format (where you can add/remove structures to it as you wish) or do you want it fully specified ahead of time (think like a struct)?
Do you need it to be versioned so it will be compatible with changes?
If versioned do you want it to be both forwards and backwards compatible or just backwards?
How ‘fast’ do you want de-serialization to be and what features would you be willing to give up for it (such as micro-integer packing and such)?
How ‘packed’ do you want it to be and what features would you be willing to give up for it (such as giving up the ability to read the data from the stream directly instead of being required to parse it out)?
After I had some time to actually think more about it, I cam to the conclusion that I actually do not need a formal way to specify types, I can just start out informally and let the types grow and evolve over time as we discover necessity.
So actually I can use one of the binary serialisation formats I’ve at least heard of so far:
BSON, which sells itself as binary JSON, therefore I do fear the same problem with numerical values as in JSON itself, but it lists distinct types for double and integer, so I’m not really sure about that, still BigInt is missing…
Protocol Buffers, which do not seem to support BigInt.
Protocol buffers. Protocol buffers is a good bit slower than most but it is very reliable and can ‘pass through’ untouched things.
However if you are wanting big integers, well I think the erlang term format is about the only one that has that unless you want to encode them as a binary blob or so. ^.^;