Minor trivial changes to documentation

diff --git a/spec/design.texi b/spec/design.texi
index f32a450f5252383eb3724b73609f6e63edfc19965270b4ea6002f5d7fa07f82a..57ff2428967016f1f1c80ccb5093615d25c47886abac492cc02e0c583cfce9b0 100644 (file)
--- 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 9e1bdc121d52f29a2b148eb9aa34e6f2f637b72562301666669b2577e891bc09..9003ad52ad2ac30c517eb272d54ea0d5c05354b31ced476f023dd9d71c3d2f83 100644 (file)
--- 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 d049d43e3de9aefce6e94c627c6ed2ddcf53eeb1ad405cf01c9466e2608f2046..031e0c3a6ed370440afcea172d28f7b6b660a330cc7483708185961a50fe71dc 100644 (file)
--- 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.