Dynamisch toevoegen van nieuwe gegevens in een StUF-bericht

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

Wat zijn de voor- en nadelen van het dynamisch linken van berichtmodellen? De vergelijking wordt dan gemaakt versus de huidige methode om verwijzigen te hebben naar/tussen verschillende berichtmodellen: het expliciet refereren vanuit een xsd van 1 sectormodel naar een xsd van een ander sectormodel.

Nadelen:

1. Er moet vooraf hoe dan ook bekend zijn welke berichtmodel op welke manier gecommuniceerd/gelinked zullen worden, maar dit wordt niet meer vastgelegd in de berichtmodellering waarmee het berichtmodel per definitie onduidelijker wordt.
2. het vereist de beschikbaarbeid van xsd-schema’s (distributiesysteem?) in de gemeente; iedere applicatie die deze berichten wil kunnen versturen moet deze externe ‘bron van xsd’s’ modelleren om de juiste url’s te kunnen opnemen naar de xsd’s of: moet zèlf de xsd’s via url beschikbaar stellen. Dit is in mijn beleving een heel ingrijpende eis die je oplegt aan gemeentes en/of applicaties die StUF willen gebruiken, alleen maar vanwege een technische keuze.
3. Implementatie: er kan geen code generatie meer plaatsvinden omdat dit afhankelijk is van expliciete referenties in xsd’s (dit geldt in elk geval voor DotNet).
4. Het is lastiger om berichten ‘offline’ te controleren/gebruiken voor interne testdoeleinden omdat deze een afhankelijkheid krijgen van de omgeving waarin de berichten in 1e instantie verstuurd werden.
5. Het is technisch lastiger om dynamische xml en xsd’s te mappen op een statisch applicatie object model, dan het originele xsd model.
6. Het huidige voorstel vereist ‘rommelen met de inhoud van het bericht’ voordat validatie mogelijk is.
7. De distributie wordt foutgevoeliger: er kan alleen in begeleidende documentatie melding worden gemaakt welke xsd’s naar welke xsd’s gemaakt kunnen worden en er kan niet via een tool gecontroleerd worden of alle xsd’s aanwezig zijn/kloppen.

Voordelen:

1. Met een 'bestaand' ZKN0310 zaakbericht, kan er ook bijv. LVO-zaak informatie meegestuurd kan worden. Echter, dat kan ook door met expliciete referenties in de LVO-zaak een property te maken met als type een ZKN0310-zaak. Functioneel levert dat hetzelfde resultaat: beide zaak-informaties in 1 bericht kunnen verzenden en is dus geen voordeel. 
2. Je zou kunnen stellen dat het een voordeel is dat je iedere willekeurig berichtmodel kunt combineren, maar ik beschouw dit als een nadeel, omdat dit alleen zin heeft als er vooraf afspraken zijn gemaakt over de mogelijke/geldige combinaties. Als die afspraken er zijn, waarom leg je die niet vast in het bericht model?

Tijdens de StUF Expertgroep van 16 april 2014 is het voorstel goedgekeurd. Wel werd aangedrongen op een andere naamgeving dan 'extraElements'. Zie hier de laatste versie van het voorstel met renvooi

En hier de laatste versie van het voorstel zonder renvooi.