Earlier quoted context omitted.
Similar, yes, but Ion repeats a number of mistakes from the past: * The text format doesn't have a version specifier, so any future changes to the text format will break existing codecs and documents. * Uses ISO 8601, which has bad defaults (local timezone) and doesn't support real time zones (only offsets). ISO 8601 is also too big for what it does and non-free, resulting in inconsistent implementations (and thus se…
> Uses ISO 8601, which has bad defaults (local timezone) and doesn't support real time zones (only offsets). ISO 8601 is also too big for what it does and non-free, resulting in inconsistent implementations (and thus security problems). Ion doesn’t use ISO8601; it has its own timestamp specification, which is free, and much smaller than ISO8601; its effectively a subprofile of a profile specified in a W3C note of ISO…
Oh good, that's an improvement. Unfortunately, nobody thought to include real time zones :/
> You’d have to process the entire list before starting to write it to the final format, because the format is optimized for read efficiency not write efficiency.
Knowing how many objects are in the list won't help efficiency because you still don't know how big each element is. So you still need to walk through the list regardless. With that in mind, there's no advantage to a size field over an end marker, but there are disadvantages.
> Length prefixing variable length data values is kind of important though; I’d consider it a major strike against a binary format if it didn’t do that. (Though Ion does have the problem that its length records are also variable length.)
I did add typed arrays to CE to support efficient storage of monosized data types such as bool and int and float. Those have chunked size prefixes.
> You can, since it supports type annotations and has formats that can with annotations communicate that. (List would probably be the normal choice.)
I'm just not a fan of requiring users to massage data structures and annotations to get basic type behaviors. Technically you can get everything you need from XML too, but the costs...
>> Doesn't support arbitrarily long scalar values.
> Yes, it does, which is why the length fields for most values, including most scalars, in the binary format use VarUInt.
Ah cool, didn't know that, thanks!
>> Doesn't support NaN or infinity.
> Yes, it does. (It doesn’t, in text format or data model, distinguish different NaNs, but it supports NaN, +Inf, and -Inf.)
As I understood it, the text format didn't have "nan" or "inf" literals... unless I missed it somewhere?