Merge branch 'feat/366-docu-changes' into 'main'

Doku anpassung set-payload-schema (planning#366)

See merge request !154

docs/changelog.md

@@ -84,7 +84,7 @@ Das Format dieser Datei basiert auf [Keep a Changelog](https://keepachangelog.co
   ([Bug](https://git.fitko.de/fit-connect/planning/-/issues/303))
 
 ### Zustelldienst 1.3.1
-- Die Reihenfolge der Ereignise im Ereignis-Log für einen Einreichungsvorgang wurde von "Aufsteigend basiert auf der
+- Die Reihenfolge der Ereignisse im Ereignis-Log für einen Einreichungsvorgang wurde von "Aufsteigend basiert auf der
   Ereignis Id und gruppiert basierend auf der Einreichungsid" zu "Aufsteigend basiert auf der Ereignis Id" geändert
   ([Bug](https://git.fitko.de/fit-connect/planning/-/issues/279))
 - Security Feature: Der Zustelldienst wird über einen Docker Container ausgeliefert. Dieser Docker Container nutzt

docs/getting-started/event-log/set-creation.mdx

@@ -5,19 +5,22 @@ title: Erzeugen eines Security-Event-Token (SET)
 import Tabs from '@theme/Tabs'
 import TabItem from '@theme/TabItem'
 
-# Event
+# SET Erzeugung
 
-Je nach Event ist ein Payload für das Event vorgesehen.
-Auf der Seite [Ereignisse](./events.mdx) finden Sie eine Liste der Ereignisse und deren Struktur.
+## Ereignis Payload {#ereignis-payload}
 
-Derzeit ist es weiterhin möglich, Events ohne Payload zu senden.
-In diesem Fall darf kein Schema (`$schema`) angegeben werden.
+Je nach SET ist ein Ereignis-Payload für das darin vorkommendes Ereignis vorgesehen.
+Auf der Seite [Ereignisse](./events.mdx) finden Sie eine Liste der Ereignisse und deren Struktur.
 
-## Event Payload
+:::caution Warnung
+Derzeit ist es möglich, Ereignisse auch ohne Ereignis-Payload zu senden.
+In diesem Fall darf kein SET-Payload-Schema (unter `$schema`) angegeben werden.
+Denn sollte ein SET-Payload-Schema verwendet werden, das ein Ereignis-Payload vorschreibt, wird das SET ohne diese Ereignis-Payload vom Zustelldienst mit einem Fehler zurückgewiesen.
+:::
 
-### Authentication Tags
+### Authentication Tags Ereignis Payload
 
-Die Struktur der "Authentication Tags" sieht wie folgt aus.
+Die Struktur der `Authentication Tags` Ereignis Payload sieht wie folgt aus.
 
 ```json
 {
@@ -83,9 +86,9 @@ values={[
 
 </Tabs>
 
-### Problems
+### Problems Ereignis Payload
 
-Die Struktur der "Problems" sieht wie folgt aus.
+Die Struktur der `Problems` Ereignis Payload sieht wie folgt aus.
 
 ```json
 {
@@ -165,17 +168,30 @@ values={[
 
 </Tabs>
 
-## SET Claims
+## SET Claimset/Payload
 
-Der SET Payload ist wie folgt aufgebaut.
-Die Elemente der obersten Ebene sind bei allen SETs vorhanden.
-Der Claim `events` enthält als Schlüssel das eigentliche Event, das ggf. einen Payload (hier: `authenticationTags`) enthält.
+Die SET Payload ist wie folgt aufgebaut.
+Die Elemente der obersten Ebene sind bei allen SETs vorhanden (Ausnahme `$schema`).
+Der Claim `events` enthält als Schlüssel das eigentliche Ereignis, das ggf. einen eigenen Ereignis Payload (hier: `authenticationTags`) enthält.
+Mehr zu der Ereignis spezifischen Payload finden Sie auf dieser Seite under [Ereignis Payload](#ereignis-payload) und auf der [Ereignisse](./events.mdx) Seite
 
-:::info
+:::caution Warnung
+Für die SET Payload wird unter `$schema` ein Schema zur Validierung definiert.
+Entspricht ein SET Payload nicht dem definierten Schema wird es z.B. vom Zustelldienst und vom Empfänger zurückgewiesen.
+Es ist aktuell noch möglich kein `$schema` an zu geben. Dadurch findet keine Validation auf Seiten des Zustelldienst und des Empfänger statt.
+Dies wird in unspezifizierter Zukunft `deprecated` und alle SETs müssen dann ein valides Schema verwenden und angeben.
 
-Derzeit ist die Version 0.1.0 des SET-Payload-Schemas aktuell.
-Die in den Beispielen genannte Version 1.0.0 wird im Zuge des Rückkanals veröffentlicht.
+Derzeit ist es auch noch möglich, Ereignisse auch ohne [Ereignis Payload](#ereignis-payload) zu senden.
+In diesem Fall darf kein SET-Payload-Schema (unter `$schema`) angegeben werden.
+Denn sollte ein SET-Payload-Schema verwendet werden, das ein Ereignis-Payload vorschreibt, wird das SET ohne diese Ereignis-Payload vom Zustelldienst mit einem Fehler zurückgewiesen.
+:::
 
+:::info
+Derzeit ist die Version [1.0.0](https://schema.fitko.de/fit-connect/set-payload/1.0.0/set-payload.schema.json) des SET-Payload-Schemas aktuell.
+Mit diesem Schema `1.0.0` stellt auch der Zustelldienst seine SETs aus.
+Bis auf weiteres kann auch noch die Version [0.1.0](https://schema.fitko.de/fit-connect/set-payload/1.0.0/set-payload.schema.json) verwendet werden.
+Inhaltlich ist sie deckungsgleich mit der Version `1.0.0`.
+Diese Version `0.1.0` wird deswegen in noch unspezifizierter Zukunft mit Ankündigung `deprecated` und sollte nicht mehr verwendet werden.
 :::
 
 ```json

docs/receiving/process-and-acknowledge.mdx

@@ -47,7 +47,7 @@ Weiterhin ist es notwendig, dass die Id der Einreichung (`submissionID`) und des
   String transactionId = "case:f73d30c6-8894-4444-8687-00ae756fea90"; // caseId
   ```
 
-  Die Payload- und Header-Attribute des SET müssen wie oben beschrieben definiert werden (siehe markierte Zeilen).
+  Die Payload- und Header-Attribute des SET müssen wie oben beschrieben definiert werden (siehe markierte Zeilen). Mehr Informationen zu dem SET Aufbau finden Sie unter [SET Erzeugen](../getting-started/event-log/set-creation.mdx)
   Im dritten markierten Block wird das SET mit dem Schlüssel signiert. Anschließend kann der serialisierte Wert an den Endpunkt <ApiLink api="submission-api" to="/v1/cases/{caseId}/events" withMethod="post" /> gesendet werden.
 
   ```java {3-10,12-16,22-24}