Since we received the bellow listed questions in german, we took the freedom the answer in german. If you need an english version of the set of questions and answers concerning the Call-for-Bids: Concept for a Framework for Internal API Alignment, let us know (tb@lists.ilias.demailto:tb@lists.ilias.de).
———
Liebe Service Providers, liebe Entwicklerinnen
Wir haben zur „Call-for-Bids: Concept for a Framework for Internal API Alignment“ (siehe Anhang) einige Rückfragen erhalten. Im Sinne der Transparenz, möchten wir die Fragen und unsere Antworten allen Entwicklerinnen zukommen lassen.
1. Wie eng/weit ist der Begriff "Framework" hier gefasst? Soll dieses "Framework" bspw. ein komplettes Sub-System sein, welches sich z.B. auch um Routing im Web-Kontext (GUI) kümmert oder ist mit "Framework" eher eine übergreifende Begrifflichkeit aus Regeln und Vorgehensweisen gemeint?
Zweites, übergreifende Begrifflichkeit aus Regeln und Vorgehensweisen falls möglich mit Proof of Concept/Beispielen (für consumer und activities sowie users of consumers).
1. Wenn wir die Goals&Benchmarks richtig verstehen, ist es durchaus in Ordnung, wenn aus der Ausarbeitung mehrere Varianten/Ansätze resultieren, die dann mit dem TB zusammen im ersten VC diskutiert werden und danach auch weiterverfolgt werden können, oder wird eher schon in der ersten Besprechung mit dem TB nach der Ideensammlung eine einzelne Richtung verfolgt?
Mehrere Ansätze/Varianten welche zusammen mit dem TB diskutiert werden sind durchaus in Ordnung (sogar erwünscht) aber nicht zwingend notwendig. Ob nach der Besprechung noch immer mehrere Varianten weiterverfolgt werden wird sich in dieser Diskussion zeigen.
1. Wie genau definiert ihr 'Domain-Level Activitiy': Meint dies z.B. eher 'Test' oder 'Kurs', oder z.B. auch 'Metadaten' und 'Tracking'. Hintergrund ist die Betrachtung von bekannten Bedarfen an APIs wie „gebe mir alle Lernstände von allen Kursen“ oder „gebe mir alle erreichten Achievements im Zeitraum x bis y“ , die wir natürlich gerne mit berücksichtigen wollen. Die Frage hängt damit zusammen, dass Services wie 'Metadaten' oder 'Tracking' intern meist eine Abhängigkeit von Domainen wir 'Kurs' oder 'Test' sind, diese im Kontext von APIs aber auch im Mittelpunkt für Anspruchshalter stehen können und dann vielleicht zu einer Art 'virtual Domain' werden könnten.
Sowohl in Test und Kurs als auch in Metadaten und Tracking gibt es Aktivitäten, die auf dem Domain-Level liegen oder auch nicht. Mit "Domain-level" sind dabei Aktivitäten gemeint, die für Nutzer der Komponente eine fachliche Bedeutung haben und nicht nur ein technisches Detail der Implementierung der Aktivität sind. Für den Kurs wäre beispielsweise "Ein Nutzer zu einem Mitglied machen" eine solche Aktivität, "Die lokale Teilnehmerrolle vergeben" aber ein Implementierungsdetail. Für das Rollenmanagement wäre die Aktivität "Eine lokale Rolle am Kurs vergeben" hingegen Teil der Domain, also der Fachlichkeit der Komponente. In diesem Sinne könnten auch die Metadaten und das Tracking fachliche Aktivitäten bereitstellen, auch wenn sie von anderen Komponenten als Detail in einer Implementierung genutzt werden. Zentral ist die fachliche Bedeutung der Aktivität, die sich auch für nicht technische Nutzer erschließen und keine Details der Implementierung enthalten soll.
Beste Grüsse