RFC: Consistente structuur binnen gerelateerde

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
RFC: Consistente structuur binnen gerelateerde

De structuur van het gerelateerde element is in de op StUF 3.01 gebaseerde sectormodellen niet consistent. Indien het bij een gerelateerde gaat om een supertype bevat het gerelateerde element een choice van twee of meer elementen die de betreffende subtypes representeren die vervolgens weer de entiteit bevatten. Indien het niet om een supertype handelt bevat het gerelateerde element zelf direct de entiteit.

Voorstel is om binnen een 'gerelateerde' element altijd, dus ook bij subtypes, een element op te nemen dat de entiteit representeert. Dus niet meer:

../gerelateerde/identificatie
                        omschrijving
                        isVan

maar:

../gerelateerde/zaak/identificatie
                                omschrijving
                                isVan

Robert Melskens

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

Robert Melskens

Tijdens de StUF Expertgroep van 15 juni 2016 heeft Henri Korver aangegeven dat het bij de verschillende structuurvormen van 'gerelateerde' ook daadwerkelijk om verschillende situaties gaat.

Robert Melskens

Henri, kan jij uitleggen waarom je de situaties zo verschillend vindt?

Ikzelf vind nl. dat de situaties helemaal niet zo veel verschillen. Ja ik begrijp dat je in het geval van een supertype in een 'gerelateerde' element wel verschillende container elementen per subtype MOET opnemen maar ik begrijp niet waarom je dit als er geen sprake is van een supertype NIET zou mogen doen.

Henri Korver

In het (meest voorkomende ) geval waarin de gerelateerde geen subtypes heeft, dan verwijst het element "gerelateerde" naar het gerelateerde entiteittype zelf. Op deze manier spaar je een extra niveau uit in het reguliere geval. In geval de gerelateerde een supertype is en wel subtypes bevat dan worden we gedwongen om extra container-elementen te introduceren voor de subtypes. Je kan voor de consistentie een kunstmatig tussenobject introduceren in het reguliere geval (gerelateerde heeft geen subtypes)  zoals jij voorstelt, maar dat vind ik persoonlijk niet elegant. Bovendien streef ik ernaar, als het even kan,de berichten zo compact mogelijk te houden. Uiteindelijk is het natuurlijk allemaal een kwestie van smaak of je consistentie of compactheid belangrijk vindt.

Robert Melskens

Het is inderdaad een kwestie van smaak. Aangezien de hoeveelheid winst aan compactheid in dit geval n.m.m. minimaal is ben ik van mening dat consistentie in dit geval van groter belang is.

Maarten van den...

Het probleem met de subtypen wordt veroorzaakt doordat gerelateerde een gereserveerd element is. Een abndere oplossing is om in plaats van gerelateerde een attribute te gebruiken om aan te geven dat het element een gerelateerde. Meerdere subtypen kunnen dan met verschillende elementnamen in het schema als choice en in xml als element worden opgenomen.