- no 128-bit integers (including IPv6 addresses or UUIDs)?
- no 80-bit long doubles (native on x86 FPU) ?
- not all IEEE number types are supported ?
- no native vector formats (AVX/SSE/GPUs...) including for OpenCL and similar APIs
- no support of variable-length lengths (using unary encoding like in several audio-video codecs) for integers of arbitrary lengths ?
- no support for differential encodings (also used on several audio-video codecs) ? including for length prefixes (note that the mantissa part can always strip the most significant bit which is always 1, except for encoding zero with a specific length value, that bit is replaced by a sign bit): integers become then encoded much like variable length floating points.
- And why do you still need space separators between EVERY item? that space counts for an incredible size in the generated stream. We can certainly imagine a format that does not require ANY separator, using distinct prefixes only, given that you already expect 8-bit clean bytes without restriction on their values, you are already building a binary format.
- no support for subtable backward references (allows non-tree structures, including recursion and common subbranches) ?
Note that this last point is different from classic dictionnary-based Lempel-Ziv compression, whose decompression creates a copy and does not imply shared data (and is then usable to compressing long "strings"). For data compression there's only a too limited repetition prefix, but I think that classic compression (like zlib) would perform better.
Or may be you assume that the result of your encoding will pass through a downstream compressor, but this adds an other layer used for everything, and requiring its own internal buffering (so performance and memory and CPU usage increases as well as the use of internal CPU caches with lower cache hits; if the two passes are chained ane not parallelized, this requires external buffering, so increases the memory or I/O footprint and this can be a limitation for use in small embedded systems like IoT: a streamable format working in one pass would be preferable)
For subtable backward references we have to choose if we want to mark specific items that will be referenced downstream (to avoid maintaining a large backward lookup buffer) and a way to remove old backward references no longer used downstream (this can be implemented by overwriting one of the previous markers; decoding them requires a dynamic dictionnary; if we don't mark, the dictionnary would be as large as the full size of the stream; but in most cases, cyclic structures are local to some subtables and no longer used later so a special mark to create a stack on which we would push and pop lookup-dictionnary contexts could cleanup instantly the past marks no longer referenced downstreams; this allows representing any kind of graph, not just trees)
