From 396a2f0b3a46c9531675805b45284e846d597bc7 Mon Sep 17 00:00:00 2001 From: Athanasius Date: Sun, 30 Jan 2022 12:38:32 +0000 Subject: [PATCH] docs/schemas: Improve "what must be present or removed" --- docs/Contributing.md | 22 ++++++++++++++++++++++ schemas/README-EDDN-schemas.md | 9 ++++++--- 2 files changed, 28 insertions(+), 3 deletions(-) diff --git a/docs/Contributing.md b/docs/Contributing.md index 2a2cddc..dee05f7 100644 --- a/docs/Contributing.md +++ b/docs/Contributing.md @@ -281,6 +281,28 @@ include: 6. All Schema files MUST be accompanied by a MarkDown formatted [README file](#schema-readme-requirements). +#### Data that should be allowed in a new Schema + +The default is to define the new Schema such that all possible data in the +source Journal event is allowed. + +However, you **MUST** consider which source data constitutes information +personal to the player, e.g. their credit balance, or the specific amount they +paid for something after the applicable discounts and mandate its removal in +the Schema. + +Furthermore, the Schema **MUST** mandate removal of all keys (and thus their +values as well) where the key name has the suffix `_Localised`. These +key:value pairs should be accompanied in the source data by a non-Localised +version which will remain, unless otherwise elided. + +You should gather as many examples as possible of actual game Journal events, +and then define the Schema such that anything (after mandated elisions as +above) that is always in the source data is *required* in the new Schema. + +Anything that does not always occur in the source data, and is not defined and +as a mandatory elision, should be defined, but remain optional. + #### Schema README requirements The per-Schema README **MUST** give both Senders and Listeners sufficient diff --git a/schemas/README-EDDN-schemas.md b/schemas/README-EDDN-schemas.md index e65ac59..f69d9d9 100644 --- a/schemas/README-EDDN-schemas.md +++ b/schemas/README-EDDN-schemas.md @@ -273,9 +273,12 @@ So, be sure you're checking the live versions and not, e.g. those in the 3. EDDN is intended to transport generic data not specific to any particular Cmdr and to reflect only the data that every player would see in-game in station - services or the local map. To that end, uploading applications MUST ensure - that messages do not contain any Cmdr-specific data (other than "uploaderID", - the "horizons" flag, and the "odyssey" flag). + services or the local map. To that end: + 1. Uploading applications MUST ensure that messages do not contain any + Cmdr-specific data (other than "uploaderID", the "horizons" flag, and + the "odyssey" flag). + 2. Uploading applications MUST remove any data where the name of the + relevant key has a `_Localised` suffix. The individual Schemas will instruct you on various elisions (removals) to be made to comply with this.