search

VNG-Realisatie / klantinteracties

Project repository tbv de ontwikkeling van de Klantinteracties API specificatie
https://vng-realisatie.github.io/klantinteracties/
1 stars 5 forks source link

Als gemeente wil ik in verzoektypes waardes kunnen definiëren. #11

Open erikdelepper opened 4 years ago

erikdelepper commented 4 years ago

...zodat ik kan controleren of een verzoek volledig en juist is en een indiener tijdens de klantreis kan ondersteunen door middel van feedback. Defacto moet ik daarvoor zowel het bestaan van een waarde als voorwaarden daarvoor vastleggen. Beide wil ik vastleggen in een waardeobject dat als array bestaat op een verzoek type. Dat roept de vraag op hoe we kunnen definiëren aan welke “voorwaarden” een waarde moet voldoen. Hiervoor is een antwoord in de vorm van commonground/nl-api strategie design keuzes. Daarbij leggen we voor API waarden en voorwaarden vast in OAS3. Diezelfde definitie kunnen we hier gebruiken om een waarde en voorwaarde te definiëren. Met andere woorden we eindigen dan met een waarde-resource onder een verzoekType-resource die we als properties voorzien met voorwaarde definities conform OAS3:

  1. Name: De naam waaronder we de waarde opslaan
  2. Type: B.v. "string", "integer", "boolean", "number","array"
  3. Format: Het swagger type van de property
  4. Iri: Gestandaardiseerd exert datamodel
  5. Required (op het moment van indienen)
  6. enum
  7. defaultValue
  8. nullablemultipleOf
  9. maximum
  10. exclusiveMaximum Etc etc in principe zouden we alle waarden die binnen OAS worden gebruikt om een property de documenteren toepasbaar moeten zijn op een waarde die we willen uitvragen via een formulier

Deze moeten we de dan voor onze use case uitbreiden met

  1. Titel: De weergeven gegevens in het
  2. Description: Een eventueel toelichting over het input veld
  3. Utter: Een spraak georiënteerde uitvraag over deze waarde, b.v.: “Op welke datum wilt u verhuizen?”
  4. Icon: Een nl-design of font awesome icon class voor weergave op schermen
  5. Order: Plaats (volgorde) van de waarde binnen formulieren en processen
  6. Uri: Verwijzing naar een extern register voor voorinvullen of aanbieden van keuzelijsten in een formulier.
  7. Filters: Optionele query parameters die worden meegeven bij het voorinvullen van deze waarde aan de hand van een extern register.
michielverhoef commented 4 years ago

Even heel gechargeerd denk ik dan dat dit qua idee hetzelfde is als EIGENSCHAP uit ImZTC: https://www.gemmaonline.nl/index.php/Imztc_2.1/doc/objecttype/eigenschap

Waar ik in ieder geval voor wil waken is in een dergelijke definitie ook een volgorde/plaatsbepaling (punt 5: Order) op een formulier op te nemen. Dan zou je nl. een nieuwe versie van dat Verzoektype moeten maken wanneer je besluit om een veld ergens anders op het formulier te maken. Dat is denk ik niet wat je wilt, het gaat immers om de structuur en voor de verwerking van het verzoek noodzakelijke gegevens. Niet over de definitie van een UI, dat is een ander onderwerp.

erikdelepper commented 4 years ago

Ik worstel eerlijk gezegd ook nog met de UI-aspecten: Dat wil je eigenlijk niet vast hebben liggen in het verzoektype, maar je wil wel iets centraals hebben vastliggen waar de verschillende kanalen geautomaiseerd gebruik van kunnen maken; naast een webformulier bijvoorbeeld ook een chatbot die de vragen in een logische volgorde moet stellen. Het idee is in ieder geval dat je straks ook geen specifiek webformulieren meer gaat bouwen, maar dat het formulier ter plekke wordt gegenereerd op basis van deze definitie. Dan kun je in feite met één configuratie een verzoektype ontsluiten voor meerdere kanalen, zonder daar een progammeur of webbouwer voor nodig te hebben.

michielverhoef commented 4 years ago

Ik snap je. Dan zou ik dit toch apart opslaan, in een UI-definitie of zo. Mocht die dan ooit aangepast worden staat dat los van het verzoektype.

In het verzoektype beschrijf je alleen de structuur van het verzoekType, ongeacht hoe dat verzoek ingediend kan worden.

Het grote voordeel is dan dat je eventueel toch meerdere ui-definities kunt maken die naar het zelfde verzoektype wijzen, mocht dat nodig zijn.

erikdelepper commented 3 years ago

@michielverhoef, Ik kan hier in meegaan, maar als die leidt tot een 1-op-1-relatie, vraag ik me af wat de toegevoegde waarde is om het te scheiden. Als de verwachting is dat het een 1-op-n, of zelfs een n-op-m-relatie wordt, of dat een groot deel van de verzoektypen geen UI-aspecten heeft, dan moet je uiteraard splitsen.

michielverhoef commented 3 years ago

Aangezien @HenriKorver inhoudelijk hier mee bezig is heb ik hem geassigned, het lijkt me dat hij hier beter op in kan gaan.