From 77c445068170563fa6fec975f8d4b32c7ddffd6783d51e73aed24be5a269e7ec Mon Sep 17 00:00:00 2001 From: Sergey Matveev Date: Wed, 25 Dec 2024 12:00:42 +0300 Subject: [PATCH] Minor trivial changes to documentation --- spec/design.texi | 2 +- spec/index.texi | 2 +- spec/schema.texi | 16 ++++++++-------- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/spec/design.texi b/spec/design.texi index f32a450..57ff242 100644 --- a/spec/design.texi +++ b/spec/design.texi @@ -68,7 +68,7 @@ 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 very +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. diff --git a/spec/index.texi b/spec/index.texi index 9e1bdc1..9003ad5 100644 --- a/spec/index.texi +++ b/spec/index.texi @@ -121,7 +121,7 @@ Note about CBOR: @itemize @item Hardly you will find wide range of CBOR libraries supporting strict validation of deterministically encoded CBOR structures. -@item I can not take tagged string/integer as a viable first-class +@item Tagged string/integer can not be taken as a viable first-class bigint/datetime data support, because many decoders do not support tags and won't be able to interpret/validate them. @end itemize diff --git a/spec/schema.texi b/spec/schema.texi index d049d43..031e0c3 100644 --- a/spec/schema.texi +++ b/spec/schema.texi @@ -6,12 +6,12 @@ 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 map's keys ordering. Remember that it is length-first one. +worry about @ref{MAP}'s keys ordering. Remember that it is length-first one. -By default binary data is expected to be encoded as BIN. If you expect -to deal with huge amounts of data, then probably you should use the BLOB -type. Generally you have to differentiate field names for ordinary -strings and blobs. +By default binary data is expected to be encoded as @ref{BIN}. If you +expect to deal with huge amounts of data, then probably you should use +the @ref{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 @@ -20,7 +20,7 @@ consisting of algorithm identifier and (obviously) signature value can be made that way: @verbatim -sig: {"a": "ed25519", "v": bytes(...)} +sig: {a: "ed25519", v: bytes(...)} @end verbatim @code{"t"} can be used as short name for the "type". @@ -31,5 +31,5 @@ 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 LISTs. Non-present -values can be indicated by NIL tag. +definitions, then think about replacing MAPs with @ref{LIST}s. Non-present +values can be indicated by @ref{NIL} tag. -- 2.50.0