Schemas: Consider if Journal schema should be split per event

[Athanasius]

With the way the schema validation, performed on the Gateway, is specified it might start getting convoluted to disallow some fields only for some events and not others.

One proposal is to just split the Journal schema out into a schema per event that is allowed.

We don't allow that many events over EDDN so it's not like this will explode out into 10s more schemas, let alone 100s.

[Athanasius]

Obviously we will need to continue to support the current Journal schema during a transition period whilst senders switch over to using new per-event schemas.

[Tkael]

Works for me, though I imagine most journal schemas are likely to still be quite similar to one another.

[Athanasius]

Works for me, though I imagine most journal schemas are likely to still be quite similar to one another.

All it takes is one key present/not present as a difference and it can be worthwhile the event having its own schema. Then you can properly define the acceptable messages rather than technically leaving the door open for "that doesn't belong in this event" data in a message.

For example Docked should most definitely contain the name of the dockable asset you're now at, but that's never going to be on an FSDJump event.

Every time I look at the schemas in detail this sort of thing sticks out like a sore thumb.