search

OParl / spec

Spezifikation für eine offene Schnittstelle für Ratsinformationssysteme
https://oparl.org
Creative Commons Attribution Share Alike 4.0 International
61 stars 21 forks source link

Inline-Ausgabe des Person.location-Objekts in OParl 1.0 #382

Closed Medo42 closed 6 years ago

Medo42 commented 6 years ago

Ich implementiere aktuell eine Client-Anwendung auf der Basis der OParl 1.0-Spezifikation. Nun wurde ich mit einer Server-Implementierung konfrontiert, die das mit einer Person verknüpfte Location-Objekt inline ausgibt anstatt - wie in der Spezifikation unter https://oparl.org/spezifikation/online-ansicht/ beschrieben - als URL-Verweis.

Die Server-Implementierung setzt damit bereits eine Änderung um, die hier im Issue #373 behandelt wurde und sich aktuell im master-Branch dieses Repositories befindet. Da diese Änderung jedoch bisher - soweit ich das sehen kann - in keiner herausgegebenen OParl-Version vorhanden ist, sich nicht auf dem 1.0-Branch befindet und darüber hinaus inkompatibel zur 1.0-Spezifikation ist (breaking change), sollte sie m.E. nicht in OParl 1.0-Implementierungen umgesetzt werden.

Ich halte inkompatible Änderungen ohne Anheben der Major-Version (und damit der URLs) generell für problematisch, weil das die Kommunikation verschiedener Clients und Server untereinander verkomplizieren würde, die u.U. auf verschiedenen Ständen der Spezifikation basieren. Die meisten Änderungen kann man auch rückwärtskompatibel umsetzen, hier z.B. als optionale Eigenschaft (z.B. "locationObject"), die zusätzlich neben der location-Eigenschaft ausgegeben würde. In der nächsten Major-Version könnte man das dann "bereinigen" und das Objekt direkt inline in der location-Eigenschaft ausgeben.

Soweit meine Sicht der Dinge. Nun als Frage: Ist die Ausgabe von Person.location als inline-Objekt konform zu OParl 1.0? Welche Änderungen in diesem Repository müssen / dürfen Implementierer von OParl 1.0-Software generell umsetzen?

akuckartz commented 6 years ago

@Medo42 Welche Server-Implementierung ist das denn?

konstin commented 6 years ago

Ist die Ausgabe von Person.location als inline-Objekt konform zu OParl 1.0?

Nein, das ist ein Bug in der Schnittstellenimplementierung. Die Schnittstelle hat auch noch ein paar andere Fehler, die nicht kompatibel zur Spezifikation sind. Im meinem Projekt bekommt diese daher eine Extrabehandlung, auch wenn ein Teil der Probleme mittlerweile gelöst sein sollte.

Welche Änderungen in diesem Repository müssen / dürfen Implementierer von OParl 1.0-Software generell umsetzen?

Keine. Der master-Branch ist in keinster Weise verbindlich und stellt nur einen beliebigen Entwicklungsstatus dar. Lediglich im 1.0 Branch werden nur 1.0-Kompatible Änderungen vorgenommen, die dann aber auch eigene Veröffentlichungen mit 1.0.X als Versionsnummer bekommen.

Ich halte inkompatible Änderungen ohne Anheben der Major-Version (und damit der URLs) generell für problematisch, weil das die Kommunikation verschiedener Clients und Server untereinander verkomplizieren würde, die u.U. auf verschiedenen Ständen der Spezifikation basieren. Die meisten Änderungen kann man auch rückwärtskompatibel umsetzen, hier z.B. als optionale Eigenschaft (z.B. "locationObject"), die zusätzlich neben der location-Eigenschaft ausgegeben würde. In der nächsten Major-Version könnte man das dann "bereinigen" und das Objekt direkt inline in der location-Eigenschaft ausgeben.

Das entspricht auch unserer Ansicht. Vor der Veröffentlichung von 1.1 wird da25779b67a71daeaacdcd9c6251dbcdd76707e9 auch dementsprechend überarbeitet. Der Vorschlag mit locationObject klingt dafür ziemlich gut. Wir freuen uns natürlich auch über Pull Requests ;)

Wie wir die Branches für 1.1 und ein späteres 2.0 Release organisieren steht im Moment noch offen. Am wahrscheinlich ist, dass wir den master bis zur Veröffentlichung von 1.1 wieder Semver-Kompatibel zu 1.1 machen, dann davon einen 1.1 Branch abzweigen und dann auf master 2.0 entwickeln.

konstin commented 6 years ago

@Medo42 Ich habe in e17bd6ce08a04273b508810c5026f818ef749189 eine Semver-Kompatible Lösung verfasst. Passt diese Lösung für dich?

Medo42 commented 6 years ago

@konstin Sieht gut aus, danke. Die Angabe ist dann optional, aber man kann sie als Client nutzen wenn sie da ist (und sich dadurch einige Einzel-Requests sparen). Ich würde noch eine "constraint" ergänzen: Wenn die locationObject-Eigenschaft angegeben ist, dann muss auch die location-Eigenschaft vorhanden sein und den gleichen Wert enthalten wie die id-Eigenschaft in locationObject.

Edit: Habe einen PR dazu verfasst: https://github.com/OParl/spec/pull/385

konstin commented 6 years ago

Ist gemergt :)