third-party-mirrors/EDDN
1
0
Fork 0
mirror of https://github.com/EDCD/EDDN.git synced 2025-04-17 09:12:21 +03:00
Code Issues Actions Packages Projects Releases Wiki Activity

docs/schemas: Improve "what must be present or removed"

Browse Source
This commit is contained in:
Athanasius 2022-01-30 12:38:32 +00:00
parent 3a2b1d0309
commit 396a2f0b3a
No known key found for this signature in database
GPG Key ID: AE3E527847057C7D
2 changed files with 28 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
docs/Contributing.md
View File

@ -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

9
schemas/README-EDDN-schemas.md
View File

@ -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.