From bc1618063ca7a76e33d0d395d0d9f61ff7ec346b Mon Sep 17 00:00:00 2001 From: Athanasius Date: Wed, 13 Oct 2021 14:21:03 +0000 Subject: [PATCH] schemas: codexentry: README: Also be specific for receivers They should expect to have to cope with any of the three scenarios, being free to just drop the data if they only get `BodyName`. --- schemas/codexentry-README.md | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/schemas/codexentry-README.md b/schemas/codexentry-README.md index f06fa96..69b6e4a 100644 --- a/schemas/codexentry-README.md +++ b/schemas/codexentry-README.md @@ -100,8 +100,19 @@ you MUST NOT include them. ## Receivers As per ['BodyID and BodyName'](#bodyid-and-bodyname) above be aware that -you are not guaranteed to reveice these values for any given event. Some -codex entries will be in space and thus they aren't even relevant. In +you are not guaranteed to receive these values for any given event. Some +codex entries will be in space, and thus they aren't even relevant. In other cases it may not have been possible to properly determine both of them. +So you might receive any of: + +1. Neither `BodyName` nor `BodyID` present in the message, not even the + key names. This SHOULD indicate a codex entry object which is not on a + body surface. +2. `BodyName` key present with a value, but no `BodyID` key. This SHOULD + indicate a codex entry object which is on a body surface, but probably + where there is a close-orbiting binary companion which has confused things. +3. Both `BodyName` and `BodyID` keys present, with values. This SHOULD + indicate a codex entry object which is on a body surface. + Adjust your local processing accordingly. \ No newline at end of file