Eigenlijk is dit een RFC op StUF ZKN 03.20 maar daar is nog geen forum voor.
Naar aanleiding van de aangenomen RFC om koppelvlakken en berichtcatalogi een eigen namespace te geven wil ik voorstellen ook eventuele voor koppelvlakken specifiek gedefinieerde structuren (simpleTypes, complexTypes) aan deze namespace te koppelen.
Mijns inziens is het een logische stap om ook deze elementen in de namespace van het koppelvlak te hangen, het zijn immers geen velden die uit bijvoorbeeld StUF ZKN komen maar alleen voor het betreffende koppelvlak van belang zijn. Denk bijvoorbeeld aan een parameter blok met CMIS informatie.
Zodra een element in andere koppelvlakken of verticale sectormodellen gebruikt gaat worden zou het een plek moeten krijgen in de algemene StUF standaard.
Michiel,
Ik neem aan dat je met algemene StUF standaard een onderliggend sectormodel bedoeld en niet de StUF onderlaag.
Het principe dat je hierboven in de laatste zin beschrijft lijkt op een wijziging die we n.a.v. het onderhoudsverzoek ERR289 al eens hebben toegepast. Toen hebben we ook afgesproken dat dit principe in de best practices zal worden opgenomen. Hier is echter sprake van een ietwat andere situatie want structuren die vanuit een koppelvlak schema overgebracht worden naar een onderliggend sectormodel komen daarmee meteen in een andere namespace te staan. Zeker bij complexType structuren zou dat een wijziging in de concrete berichten inhouden wat mogelijk backwards compatibiliteits issues zou kunnen geven. Bij simpleTypes speelt dat volgens mij niet.
Dit RFC heeft dus niet alleen gevolgen de koppelvlakken maar ook voor de best practice.
Dit wijzigingsverzoek is opgevoerd in de onderhoudsverzoeken als ONV0389.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Robert,
Merci voor het aanmaken van het onderhoudsverzoek. Ik bedoelde inderdaad de StUF sectormodellen maar vanuit koppelvlakken gezien maakt het mij niet uit waar een element terecht komt om het te kunnen hergebruiken, als het maar de goede plek is.
Aanpassen van de namespaces in zowel simpleTypes als complexTypes die koppelvlak specifiek zijn zullen hoogstwaarschijnlijk inderdaad tot backwards compatibiliteitsissues leiden. Een mogelijke oplossing zou zijn alle elementen die nu koppelvlakspecifiek zijn dubbel op te nemen, zowel met de oude ZKN/BG namespace als met de nieuwe namespace. Dit zou kunnen middels de aanvullende elementen constructie maar los van de organisatorische zaken (toestemming van de regiegroep ed.) vrees ik dat berichten dan monsterlijke gedrochten gaan worden die alsnog problemen gaan geven.
De reden van deze RFC is dat met het loskoppelen van alleen het root element de koppelvlak specifieke elementen nog steeds in de oude namespace zitten en daarmee gekoppeld zijn een StUF sectormodel. Het doel van RFC0382 was volgens mij de koppelvlakken en berichten catalogi los te koppelen en daarmee koppelvlakken de mogelijkheid te geven hun eigen releasebeleid te voeren.
Het is dus niet de bedoeling alle StUF sectormodel structuren te kopieren en in een eigen namespace te zetten, dat zou onzin zijn. De koppelvlak specifieke structuren, zowel extensies/restricties van elementen uit de StUF sectormodellen als eigen elementen, moeten voor mijn gevoel echter wel in de namespace van het koppelvlak geplaatst kunnen worden.
Het zou goed zijn wanneer ook leveranciers op deze RFC reageren en aandachtspunten vanuit de praktijk kunnen geven.
Hoi Michiel, ik ben het helemaal met je eens dat in principe alle elementen (en attributen) van een StUF-bericht die specifiek bij een koppelvlak horen in de eigen namespace van het koppelvlak gedefinieerd moeten worden. Echter als je dat consequent wilt doen, dan loop je in StUF 3.01 aan tegen een technische probleempje met de herkenbaarheid van entiteittypen (je weet in sommige gevallen niet meer bij welke namespace ze horen). Dit probleem kan worden opgelost door middel van dit RFC.
De bovenstaande teksten waren voor mij niet helemaal helder. Daarom ook nog mijn centje in de pot.
Uitgangspunt van StUF is dat semantische modellen worden omgezet naar StUF-entiteiten binnen een sectormodel voor zo'n semantisch model. Waar binnen een koppelvlak gegevens worden gebruikt die zijn gedefinieerd in een verStUFt semantisch model, dan dienen deze gegevens ook binnen een koppelvlak altijd te worden opgenomen in een topelement in de namespace van het koppelvlak met daarbinnen een entiteittype attribute dat definieert om welk entiteittype uit welk sectormodel het gaat en met als child-elementen elementen met als namespace de namespace van het sectormodel gedefinieerd door het attribute entiteittype.
Gegevens die specifiek zijn voor een koppelvlak (en dus niet gedefinieerd zijn in een sectormodel) kunnen op twee manieren in een bericht worden:
Het maken van restrictions op een StUF-entiteit leidt dus niet tot het in een andere namespace komen van de elementen in een restriction. Het maken van extensions op een StUF-entiteit is sowieso niet toegestaan. Via de aanvullendeElementen constructie kunnen 'extensies' van een StUF-entiteit worden gedefinieerd. In de definitie van een koppelvlak kan het exacte gebruik van aanvullende elementen via het restriction-mechanisme worden voorgeschreven.
Eens met Maarten. Als ik zijn tekst goed begrepen heb, voldoet het volgende bericht aan de namespace conventies:
<rbs:zoekNpsOpNaamGeboortedatum xmlns:stuf="http://www.stufstandaarden.nl/stuf0302" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:rbs="http://www.stufstandaarden.nl/koppelvlak/rbs0310" xmlns:bg="http://www.stufstandaarden.nl/sectormodel/bg0320" xsi:schemaLocation="http://www.stufstandaarden.nl/koppelvlak/rbs0310 rbs0100_msg.xsd">
<rbs:stuurgegevens>
<stuf:zender>
<stuf:applicatie>aaa</stuf:applicatie>
<stuf:gebruiker>a</stuf:gebruiker>
</stuf:zender>
</rbs:stuurgegevens>
<rbs:parameters/>
<rbs:selectie stuf:functie="selectie">
<rbs:parameters>
<stuf:peiltijdstipMaterieel>2001-12-17T09:30:47</stuf:peiltijdstipMaterieel>
</rbs:parameters>
<rbs:gelijk bg:entiteittype="NPS">
<bg:geslachtsnaam>
<bg:w>AA</bg:w>
</bg:geslachtsnaam>
</rbs:gelijk>
</rbs:selectie>
</rbs:zoekNpsOpNaamGeboortedatum>
Tijdens de StUF Expertgroep van 21 september 2016 is besloten dat datgene wat Maarten en Henri in de twee voorgaande posts beschrijven in de StUF onderlaag zal worden opgenomen.
Een en ander heeft tot gevolg dat in koppelvlakken gebaseerd op StUF0301 het voorgestelde niet kan worden gerealiseerd. Daar kan alleen het topElement van het bericht de namespace van het koppelvlak hebben.
In StUF0302 zal de onderlaag worden aangepast, zodat in StUF0302 koppelvlakken de lijn zoals beschreven door Henri en mij gevolgd worden.