Als deelnemende infrastructuur wil ik extra metadata aan een endpoint kunnen toevoegen zodat andere partijen deze kunnen gebruiken en begrijpen.

minvws / generiekefuncties-adressering

Samenwerken aan de Generieke Functie Adressering

2 stars 2 forks source link

Als deelnemende infrastructuur wil ik extra metadata aan een endpoint kunnen toevoegen zodat andere partijen deze kunnen gebruiken en begrijpen. #31

Open stevenvegt opened 6 months ago

stevenvegt commented 6 months ago

Gebruiker

Anders

Wat wil de gebruiker doen?

Als deelnemende infrastructuur wil ik extra metadata aan een endpoint kunnen toevoegen zodat andere partijen deze kunnen gebruiken en begrijpen.

Motivatie

Infrastructuren hebben soms logica voor het kiezen of gebruik van endpoints. Deze logica heeft dan aanvullende informatie over het de beschikbare endpoints nodig, die moeten dan beschikbaar zijn in de adresseringsfunctie. Welke velden dat zijn is infrastructuur specifiek, en kan dus niet van te voren worden bedacht. Daarom is het handig om vrije velden in de vorm van metadata toe te staan naast een endpoint.

Extra informatie

Ingebracht tijdens de werkgroep van 27 februari.

ltieleman commented 5 months ago

Wordt met endpoint een adres bedoeld?
Mogelijk dubbel met #27

BertineUithoven commented 5 months ago

Titel omgeschreven naar 'Als'

PascalvanderHall commented 5 months ago

Deze wordt mee terug genomen door Bertine

ldebruinvecozo commented 5 months ago

Gewenste metadata bij technische adresgegevens:

ingangs- en einddatum/tijd geldigheid adres
of het een test of productie-omgeving betreft
onderhoudsperiodes waarin het technisch adres niet bereikbaar is (periodiek of éénmalig)
emailadressen waarop de beheerders bereikt kunnen worden ingeval van storingen
technische kenmerken van het koppelvlak (SOAP versie, TLS versie, MTOM, etc.)
welke partijen 'gebruiker/afnemer' zijn van het adres (voor mogelijk maken van informeren van partijen bij storingen of wijzigingen)

Wijzigingshistorie met overzicht van gegevens over mutaties op adresgegevens (aanleiding, door wie ingediend, datum mutatie, aard en inhoud van wijziging)

Ondersteuning migraties/overgangen door meerdere versies van adresgegevens:

per 'electronische dienst' aparte adressen voor verschillende versies van die dienst kunnen vastleggen

GTukker commented 5 months ago

in de motivatie staat 'Welke velden dat zijn is infrastructuur specifiek, en kan dus niet van te voren worden bedacht. Daarom is het handig om vrije velden in de vorm van metadata toe te staan naast een endpoint', maar in plaats van 'vrije velden', kan een infrastructuur toch aangeven welke metadata wenselijk zijn voor deelname (zie bijvoorbeeld de bovenstaande opmerking). Regie lijkt wenselijk.

BertineUithoven commented 5 months ago

Het lijkt mij wijs te bespreken hoe eventuele meta gegevens het beste vastgelegd kunnen worden. In principe wijzigen deze in de tijd niet vaak. Daar moet wel ruimte voor zijn, mocht dit wel een keer het geval zijn. Er kan bijv. een call worden gedaan naar het bronregister als check bij een bevraging.

BertineUithoven commented 5 months ago

Eens met de beschreven scenario's door Leendert. Vraag is in welke situaties het centrale adresseringsregister hier wel/geen last van heeft. Goed om ze langs te lopen en aan te vullen waar nodig.