+++ /dev/null
-@node Schema
-@unnumbered Schema
-
-KEKS can be decoded without any schema definition. But semantic meaning
-and constraints of various fields are expected to be written in a human
-readable language somewhere nearby.
-
-For being able to streamingly generate the serialised data, you have to
-worry about @ref{MAP}'s keys ordering. Remember that it is length-first one.
-
-By default binary data is expected to be encoded as @ref{Strings, BIN}.
-If you expect to deal with huge amounts of data, then probably you
-should use the @ref{Blobs, BLOB} type. Generally you have to
-differentiate field names for ordinary strings and blobs.
-
-For relatively small structures it could be wise to use reasonably short
-key names. However it may be difficult and not obvious to keep the
-balance between compactness and understandability. For example signature
-consisting of algorithm identifier and (obviously) signature value can
-be made that way:
-
-@verbatim
-sig: {a: "ed25519", v: bytes(...)}
-@end verbatim
-
-@code{"t"} can be used as short name for the "type".
-
-You should use more or less human readable strings instead of object
-identifiers. OIDs database can be considered as an external schema.
-Lacking it, or lacking its actual state, you probably won't be able even
-guessing the context of the data inside.
-
-If you really desire more compact encoding, even agree to use schema
-definitions, then think about replacing MAPs with @ref{LIST}s. Non-present
-values can be indicated by @ref{Primitives, NIL} tag.