geen vrije berichten gebruiken als restrictions op enkelvoudige kennisgevingen worden toegepast

Dit is een statische kopie van het eerdere discussie.kinggemeenten.nl.
Nieuwe discussies kunnen in de GitHub repository 'StUF standaarden' als issue worden opgevoerd.

7 reacties / 0 nieuw
Robert Melskens
geen vrije berichten gebruiken als restrictions op enkelvoudige kennisgevingen worden toegepast

Tijdens de StUF Expertgroep van 16 maart 2016 is opgemerkt dat er op dit moment vaak vrije berichten worden gebruikt als er restrictions op enkelvoudige kennisgevingen worden toegepast. Dit is echter niet de bedoeling. Dit moet aangescherpt worden in de Best Practices.

Robert Melskens

Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ERR0445.
De lijst met onderhoudsverzoeken vind je op: 
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten

Robert Melskens

Zie bijgaand het voorstel voor de oplossing van het erratum ERR0445.

Bijlage

stuf_best_practices.zip
Ruud Kathmann

Wij gaan er van uit dat dit soort restricties juist gebruikt worden, wanneer men ook bij de controles en dus de foutafhandeling strenger wil zijn. Het aanbrengen van een restrictie in een ComplexType zal naar onze mening alleen zin hebben als je in de keten daar dan ook foutafhandeling op zet.

Volgens het nu geformuleerde voorstel mag dat niet. Het kennisgevingsbericht met de restrictie op het ComplexType mag geen andere foutafhandeling krijgen dan het basis kennisgevingsbericht. Daarmee is deze restrictie wat ons betreft zinloos geworden.

Door over te stappen naar een dienstbericht kan ik wel betekenisvolle foutafhandeling doen gericht op de aangebrachte restrictie.

Robert Melskens

Tijdens de StUF Expertgroep van 15 juni 2016 is besloten het voorstel nog niet goed te keuren. Robert gaat het met Henri bespreken.

Robert Melskens

Naar aanleiding van de reactie van Ruud zijn wij tot het bijgaande vernieuwde voorstel gekomen.

Bijlage

stuf_best_practices - ERR0445.pdf
Robert Melskens

Tijdens de StUF Expertgroep van 15 maart 2017 is de uitwerking van dit onderhoudsverzoek zoals voorgesteld in reactie #6 goedgekeurd en is tevens goedgekeurd deze al meteen op te nemen in patch 26.