Leere Objektlisten, deren Eigenschaft ZWINGEND ist

[sterni24]

Wie wird mit leeren Objektlisten umgegangen, deren Eigenschaft ZWINGEND ist?

Beispiele für die Eigenschaft meeting, wenn Daten vorhanden sind:

"meeting": "https://oparl.beispielris.de/meeting_of_organization/1"

"meeting": [
"https://oparl.beispielris.de/meeting/1",
"https://oparl.beispielris.de/meeting/2",
...
]

[sterni24]

Das Ganze wurde schon in #184 behandelt, wird jedoch am Ende m. E. etwas unpräzise.

Das vorstehende Beispiel mit der Eigenschaft meeting kann in der einen oder anderen Situation dazu führen, dass Listen leer sind.

Die Eigenschaft von ZWINGEND auf EMPFOHLEN zu setzen halte ich für keine Lösung. Der Client muss Klarheit darüber gewinnen, ob Termine vorhanden sind oder nicht.

[marians]

Ich gebe Ihnen Recht. Bei Pflichteigenschaften wäre es besser, eine leere Liste auszugeben, als die Eigenschaft komplett weg zu lassen.

[marians]

Formulierungsvorschlag für den Abschnitt null-Werte und "leere" Werte:

JSON erlaubt es grundsätzlich, Eigenschaften mit dem Wert `null` zu versehen.

Clients MÜSSEN eine Eigenschaft mit dem Wert `null` so behandeln, als
wäre die Eigenschaft nicht im Objekt vorhanden. OParl-Server SOLLEN die
Ausgabe von Eigenschaften mit dem Wert `null` grundsätzlich vermeiden.

Analog dazu SOLLEN Server vermeiden, leere JSON-Arrays und -Objekte 
(`[]` und `{}`) auszugeben. Auch hier sind Clients dazu angehalten, diese
wie nicht existierende Eigenschaften zu behandeln.

Ausnahmen bilden hier Eigenschaften, die ihrerseits als Pflichteigenschaften
("ZWINGEND") deklariert sind und die Kardinalität "1 bis *" besitzen,
also eine Liste als Wert haben können. Diese Eigenschaften DÜRFEN auch dann
gesetzt sein, wenn ihr Wert eine leere Liste ist.

Statt "DÜRFEN" könnte im letzten Satz auch "SOLLEN" oder gar "MÜSSEN" stehen. Was wäre das beste?

Ist das mit dieser Formulierung deutlich?

[sterni24]

@marians Mein Formulierungsvorschlag:

JSON erlaubt es grundsätzlich, Eigenschaften mit dem Wert 'null' zu versehen.

Dies gilt ausschließlich für Eigenschaften, die ihrerseits als Pflichteigenschaften mit ("ZWINGEND") deklariert sind und somit die Kardinalität "0 bis *" besitzen, also eine URL, eine Liste oder 'null' als Wert haben können.

Clients MÜSSEN eine Eigenschaft mit dem Wert 'null' so behandeln, als wären zu der Eigenschaft im Objekt keine Daten vorhanden.

Beispiele aus oparl:Organization:

"meeting": "null",
"meeting": "https://oparl.beispielris.de/meeting/1",
"meeting": [
"https://oparl.beispielris.de/meeting/1",
"https://oparl.beispielris.de/meeting/2",
...
],
"meeting": "https://oparl.beispielris.de/meeting_of_organization/1",

[sterni24]

@marians Als Ergänzung zur letzten Zeile aus den Beispielen gilt: ein Server darf eine URL nur ausgeben, wenn die damit verbundene Liste auch Daten enthält.

Gleichzeitg stellt sich an dieser Stelle die Frage, ob die Ausgabe von Objektlisten überhaupt noch Anwendung findet. Die Augabe einer URL in Verbindung mit #218 wäre hier m. E. die einfachste und performanteste Lösung.

[marians]

@stern24 "Ein Server DARF eine URL nur ausgeben, wenn die damit verbundene Liste auch Daten enthält." - das habe ich mir zuerst auch gedacht.

Dabei ist folgendes zu bedenken:

Zwischen dem Abruf des Objekts (z. B. oparl:Organization) und dem Abruf der entsprechende Liste (z. B. die Liste der Sitzungen, die über die Eigenschaft "meeting" verknüpt ist) vergeht in jedem Fall Zeit. Es ist möglich, dass zwischen den beiden Abrufen Elemente zur Liste hinzugekommen oder entfallen sind. Es kann also regulär vorkommen, dass der Server bei Ausgabe des einzelnen Objekts die URL der Liste ausgibt, weil diese gerade Elemente enthält. Dann fragt der Client die Liste über diese URL ab, diese enthält jedoch keine Elemente mehr.

Sollte man das als Verstoß gegen die Spezifikation werten? Ich denke nein, daher ist hier evtl. die weichere Form "SOLL" angemessen: "Ein Server SOLL eine URL zu einer Liste nur dann ausgeben, wenn die Liste Einträge enthält."

[sterni24]

Das von Ihnen aufgezeigt Scenario tritt natürlich nicht nur innerhalb einer Abfrage auf, sondern zieht sich durch eine gesamtes System. Um dieses zu vermeiden, veröffentlichen wir in Zyklen, die z. B.im 2-Stunden-Takt oder tageweise erfolgen. Mit dieser Verfahrensweise ist davon auszugehen, dass die Daten konsistent sind.

Aus Sicht des Servers ist es ein MUSS, weil die Ausgabe der Eigenschaft ZWINGEND ist. Wenn zum Zeitpunkt der Client-Abfrage Objektdaten vorhanden sind, erfolgt die Ausgabe einer URL, ansonsten 'null'.

[akuckartz]

Hier sind mehrere interessante Fragen aufgeworfen. Ich gehe auf ein paar davon in separaten Kommentaren ein.

1. Was bedeuten "leere" Eigenschaften?

Eine nicht vorhandene oder leere Eigenschaft eines Objekts bedeutet nicht mehr und nicht weniger, als dass zu dem betrachteten Abrufzeitpunkt kein einziges Tripel existiert, auf welches dieses Pattern passt (in dem die ersten beiden Positionen festgelegt sind wärend die letzte Position variabel ist):

<Ausgangsobjekt> <Eigenschaft> ?wert .

Welche Bedeutung hätte in einem solchen Fall die von @marians vorgeschlagene URL zu einer leeren Liste? Es wäre ein Query mit genau dem selben Pattern:

<Ausgangsobjekt> <Eigenschaft> ?wert .

Eine solche URL muss dem Client aber vom Server dann nicht mitgeteilt werden, wenn er derartige Abfragen selbst formulieren kann. Mit #165 ist genau dies möglich.

(Wenn aber im Fall leerer Eigenschaften auf die Übermittlung solcher URLs vom Server an den Client verzichtet werden kann - weil der Client die Query-URL bei Bedarf jederzeit selbst generieren kann - dann stellt sich möglicherweise die Frage ob dies bei nicht-leeren Listen auf die selbe Weise behandelt werden kann, also die (selbe) URL auch in dem Fall nicht an den Client übermittelt werden muss. Auf diese Frage und mögliche Antworten gehe ich hier aber nicht weiter ein.)

[sterni24]

@akuckartz Wenn ich ein Objekt mit einer ZWINGENDen Eigenschaften abrufe, erwarte ich ein Ergebnis in Form einer URL oder 'null'.

Beispiel für eine leere Eigenschaft aus oparl:Organization:
"meeting": "null"

Da muss ich auch keine Abfrage mehr formulieren; da weiß ich, dass zu diesem Zeitpunkt keine Termine zu dem Gremium vorhanden sind. Was das an dieser Stelle mit einem Tripel zu tun hat, verstehe ich zudem nicht.

[akuckartz]

1. Die Frage die sich hier wieder einmal stellt ist die nach der Bedeutung von "ZWINGEND". Semantisch gibt es keinen Unterschied zwischen Eigenschaft nicht da und Eigenschaft ist null. Da kann man fordern was man möchte.

An allen anderen Stellen wurde darauf geachtet, dass ZWINGENDE Eigenschaften auch automatisch getestet werden können. Wenn diese Anforderung nicht mehr gelten soll, dann kann man hier schlicht fordern, dass beim Vorhandensein von z.B. Terminen wie hier diese als Werte der Eigenschaft ausgegeben werden müssen und wenn keine vorhanden sind die Eigenschaft nicht vorhanden sein darf - oder nicht?

@sterni24 Die Tripel-Sicht sollte helfen die Semantik des Vorschlags von @marians zu illustrieren. Dieser besteht ja nach meinem Verständnis darin auch bei keinem bekannten Termin eine URL auszugeben.

[sterni24]

Ich gehe davon aus, dass ein Validator auch auf ZWINGENDe Eigenschaften testet. Das íst ja genau der Punkt. In Ihrem Fall wäre das Programm nicht valide, weil bei nicht vorhandenen Terminen die Ausgabe der Eigenschaft meeting unterdrückt wird.

Es geht mit hier darum, es für den Client eindeutig zu machen. Ein Client sollte sich nicht darum kümmern müssen, ob eine Eigenschaft ZWINGEND ist oder nicht. Semantik hin oder her, ich suche hier den praktischen Ansatz.

Anmerkung:
Aktuell ist die Eigenschaft meeting nicht mehr ZWINGEND, so dass ich der Meinung bin, solche Lisen nicht mehr auszugeben, siehe auch #167. Für den Client sind solche empfohlenen Eigenschaften irreführend.

[akuckartz]

@sterni24 Wir sind einer Meinung, dass der Client wissen können MUSS, ob ein Server eine Eigenschaft unterstützt oder nicht. Und ich halte es ebenfalls für notwendig solche Informationen dem Client maschinenlesbar zur Verfügung zu stellen. Dazu Objekte mit null-Eigenschaften zu füllen halte ich jedoch für keine gute (oder praktische) Lösung. Ein Client muss vorher wissen können was er erwarten kann. Wir haben hier also nur unterschiedliche Auffassungen über das wie.

Ich bin gegenwärtig dabei eine generelle Lösung vorzubereiten. Das wird aber noch ein paar Tage dauern.

[sterni24]

Ich denke, hierzu wurde alles gesagt.

[marians]

Für's Archiv: Dieses Thema wurde unter #226 weiter behandelt.