+++ /dev/null
-@node Design
-@unnumbered Design
-
-@itemize
-
-@item
-No ASCII decimal parsing. That is not trivial code, not fast, not
-compact. Although it is human readable and understandable.
-
-@item
-No varints (where most significant bit means continuation) and
-zig-zag-like encoding. That is not trivial code.
-
-@item
-No formats where maps and lists need to know their lengths/sizes in
-advance. That means no streaming possibility. Complicates encoder and
-requires more memory usage.
-
-@item
-No formats without ability to store maps/dictionaries/tables. Of course
-they can be emulated by reassembling lists, but that is manual action
-after the codec did his job.
-
-@item
-Differentiation of binary and human-readable strings (UTF-8 for example)
-is a must for a format that is intended to be looked and analysed by a human.
-
-@item
-No ISO-based (string) representation of datetime: it requires complex
-parsing and takes much space. Naive UNIX timestamp representation raises
-questions about its length and dealing with the dates before 1970.
-Moreover they are not suitable for tasks requiring monotonous clocks,
-because of UTC.
-
-@item
-No tagging ability, context specifying, marking, hinting, extension
-mechanism or anything like that. That brings complications to the state
-and questions with unknown entities. Any unsupported data type must be a
-string, possibly enveloped in a map with additional data.
-@code{@{"cp": "koi8-r", "str": BIN(...)@}}.
-
-@item
-Large (>2GiB) strings support is a must. Nowadays even a single
-multimedia file can easily exceed that size. General-purpose codec
-should be able to send it without complication of inventing your own
-chunked format.
-
-@item
-Is not embedded strings length, like in KEKS and CBOR, is a more
-complicated code? Definitely. But there are so many short strings in a
-schemaless format for specifying map/structure keys. So many algorithm
-identifiers, that are also relatively short human-readable strings. So
-that is a compromise between slightly larger code and much shorter
-resulting structures.
-
-@item
-There should be clear distinguishing of continuous strings and
-streamable ones (BLOBs). ASN.1 CER does not do that, making
-representation of every string in memory far from being convenient and
-easy to work with. Different tasks have different constraints: many of
-them do not need streamable strings at all, some of them may use it
-solely.
-
-@item
-Only string keys are allowed in maps, eliminating huge number of
-problems when keys like int/bigint/float collide.
-
-@item
-More compact strings encoding is more important than more compact
-integers. Short strings are often used as a keys in maps and as
-algorithm identifiers. Huge quantity of integers can be met only in a
-specialised use-cases, where you will likely use own specialised format
-with fixed integers for faster loading. For example in most cases
-cryptography related tasks do not involve integers at all in their formats.
-
-@end itemize