Draft-3 Freifunk JSON Schema, zwar valide, aber problematisch #152
Description
Unabhängig wie lange die draft-3 Freifunk JSON Schema noch im Einsatz sein werden, sollte diese nicht nur schematisch valide JSON Schema sein, sondern auch noch unproblematisch in der Handhabung werden.
Egal ob eine Soft-Migration zu draft-7 stattfinden wird (siehe auch #151) oder wie lange diese dauert, sollten wir die aktuellen draft-3 Freifunk JSON Schema Datei von Usability Problemen befreien.
Freifunk draft-3 JSON Schema sind aktuell problematisch
Unsere Freifunk JSON Schema sind zwar gemäß http://json-schema.org/draft-03/schema# valide JSON Schema Dateien, jedoch sind diese gleichzeitig "empty schema". Was ist das?
Ein "empty schema" ist ein JSON Schema das auf root-ebene keine der folgenden Schema Keywords enthält: https://tools.ietf.org/html/draft-zyp-json-schema-03#section-5
Nicht in der Spezifikation aufgeführte "Schema Keywords" werden ignoriert. Das steht in der Spec vom draft-3 zwar nicht explizit ist aber üblich unter den gängigen Validatoren - oft sogar ohne ein Hinweis auf das etwas ignoriert wurde. In der aktuellen draft-7 Spezifikation ist das Ignorieren aber explizit erwähnt: https://tools.ietf.org/html/draft-handrews-json-schema-01#section-4.3.1, was wirklich gut ist.
Da die Freifunk JSON Schema Dateien auf der Root-Ebene nur das Keyword "schema" (nicht verwechseln mit "$schema") verwenden und dieses nicht zur Spezifikation gehört wird es oft ignoriert und damit auch das eigentliche Freifunk JSON Schema welches sich eine Ebene tiefer befindet. Das führt dazu dass eine Validierung mit diesem JSON Schema zwangsläufig immer erfolgreich verlaufen ("empty schema"; da keine Regeln ausgewertet werden). Oder zumindest in einigen Validatoren anderes.
Einige Freifunk-Scripte (API Generator und o.g. Travis-CI Script) extrahieren daher den Teil unterhalb des "schema"-Feldes und bringen das damit auf Root-Ebene. Beispiel:
https://github.com/freifunk/directory.api.freifunk.net/blob/master/tests/test.py#L28
Ein unerfahrener Entwickler oder Anwender aus einer lokalen Gruppe könnte gar nicht bemerkt haben das unser Freifunk JSON Schema einen "wrapper" in sich hat, der es zu einem "empty schema" macht, und alle seine Dateien damit immer als valide ausgibt, obwohl sie es nicht wären, wenn man den "Extract" als JSON Schema verwendet.
Alle Scripte die nicht kurzfristig auf draft-7 umgestellt werden können (z.B. fehlende unterstützung für draft-7) sollten von uns zumindest semantisch-saubere draft-3 Dateien bekommen. Auch hier würde ich diese gerne zunächst Zusätzlich im Repo ablegen um eine Soft-Migration bis z.B. 31.12.2019 zu ermöglichen.
(dieses Ticket wird dann für die Commit-Message und den PR verwendet)
Was haltet Ihr davon?