> its effectively a subprofile of a profile specified in a W3C note of ISO8601, but that relationship is mostly of historical interest, since it isn’t specified an a (sub)profile, but independently. It also has a UTC default.
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?
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?