From 94abb6b0993a1406fffc0afbc15e22edc993ff30 Mon Sep 17 00:00:00 2001 From: Adrian Cole Date: Sat, 12 Dec 2020 18:51:59 +0800 Subject: [PATCH] Fixed some typos Didn't address another thing, which I found confusing. In the "Message schema extension example", three versions are discussed, but only 2 version numbers are used. It could be more clear to use a different word if "a new message is added" is intentionally mutating an existing version. For example, instead of saying "Second version - a new message is added", you could say "First change - a new message is added to an existing version". This reduces the pressure on the word "version" used for different reasons in the same section. If on the other hand it was a typo to not increment the version, we should fix that :D --- v2-0-RC3/doc/05SchemaExtensionMechanism.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/v2-0-RC3/doc/05SchemaExtensionMechanism.md b/v2-0-RC3/doc/05SchemaExtensionMechanism.md index 883ad42..775f27b 100644 --- a/v2-0-RC3/doc/05SchemaExtensionMechanism.md +++ b/v2-0-RC3/doc/05SchemaExtensionMechanism.md @@ -106,7 +106,7 @@ encoding. Message headers and repeating group dimensions carry a count of the number of repeating groups and a count of variable-length data fields on the wire. This supports a walk by a decoder of all the elements of a message, even when the decoder was built with an older version of a schema. As for added fixed-length fields, new repeating groups cannot be interpreted by the decoder, but it still can process the ones it knows, and it can correctly reach the end of a message. -## Comaptibility strategy +## Compatibility strategy *This suggested strategy is non-normative.* @@ -153,7 +153,7 @@ Second version - a new message is added - +