In januari vorig jaar is de laatste ronde tafel geweest om te onderzoeken of StUF als stelselstandaard kan worden gezien. Uit deze ronde tafel is een actielijn gekomen om een harmonisatie in te gaan met de 3 grote standaarden die naast Digikoppeling gebruikt worden binnen het stelsel.
Voor deze berichtenstandaard in ontwikkeling doneren SuwiML, NEN3610, StUF en Digikoppeling ieder hun oplossingen om te komen tot meer gemeenschappelijkheid.
Dit project is Utrecht genoemd. Utrecht heeft nu zijn eerste resultaten opgeleverd. De opgeleverde specificaties zijn een eerste stap in een (door)ontwikkel proces. Het aantal elementen dat gemeenschappelijk wordt gezien zal in de loop van de tijd steeds groter worden. Om deze groei naar meer elementen te borgen wordt nu gewerkt aan een duurzame organisatie en governance structuur.
Deze review is bedoeld om uw reactie op de huidige resultaten te horen. Na instemming van u, zullen de specificaties in ieder geval overgenomen worden door de 4 betrokken standaarden.
In het bij de reactie op deze discussie gevoegde zip bestand vindt u naast het voorstel m.b.t. Foutafhandeling enkele toelichtingen en een vragenlijst waarin u uw opmerkingen m.b.t. het voorstel kunt plaatsen.
Vanuit Enable-U voorwaardelijk akkoord: Naamgeving elementen in bijlage 3 toont nog inconsistente hoofdletters tussen StUF en SuwiML. Dit moet aangepast worden. Governance op toegestane prefixes is niet genoemd.
In het voorstel wordt de code van een foutmelding een onbeperkte string. Een code is een identificerend gegeven van een fout. Omdat onze applicaties vaak op identificerende gegevens zoeken (in een geïndexeerde database) is het goed om wel een (maximale) lengte te hebben zodat onze applicaties op codes die lokaal worden opgeslagen snel kunnen zoeken (een veld van onbeperkte lengte kan niet geïndexeerd worden).