Bij het maken van het sectormodel bg0310 wordt op een aantal plaatsen een choice gebruikt om expliciet te maken dat slechts één van de elementen binnen de choice in het bericht mag worden opgenomen. Een persoon kan bijvoorbeeld niet verblijven op zowel een buitenlands adres als een binnenlands adres. Dit gebruik van een choice is nieuw voor bg0310, want in bg0204 komen geen choices voor. Het gebruik van de choice constructie leidt tot een interpretatieprobleem met de huidige specificatie. Tabel 5.3 specificeert nu dat in 'oud' de te wijzigen elementen moeten worden opgenomen en in 'huidig' de gewijzigde elementen. Hierbij wordt niet expliciet rekening gehouden met het gebruik van een choice in de schema's, want als een persoon verhuist van een buitenlands adres naar een binnenlands adres, dan zouden beide opgevat kunnen worden als te wijzigen en gewijzigde gegevens. Het schema staat bij gebruik van een choice echter niet toe dat beide in het bericht worden opgenomen. Bij het gebruik van een choice (een volstrekt standaard constructie binnen schema, die het mogelijk maakt een bericht scherp te definiëren) dienen te wijzigen en gewijzigde element te worden opgevat binnen de context van de choice. Er is dan precies één element binnen de choice te wijzigen en gewijzigd en 'oud' en 'huidig' zijn qua elementen niet gelijk. Een en ander kan verduidelijkt worden door onder Tabel 5.4 de volgende tekst op te nemen: "Indien het te wijzigen element en het gewijzigde element zich binnen een choice bevinden en niet dezelfde elementnaam hebben, dan wordt in 'oud' alleen het te wijzigen element opgenomen en in 'huidig' alleen het gewijzigde element. Het te wijzigen element wordt dus niet met StUF:noValue=geenWaarde opgenomen in 'huidig' en het gewijzigde element wordt niet met StUF:noValue=geenWaarde opgenomen in 'oud'. Dit kan ook niet gegeven de regels voor een choice." De vraag die voorligt is of dit een functionele wijziging is van de StUF-standaard of een verbetering van een fout.
vr, 20-03-2009 - 10.33u
#1
Choice in StUF0301 schema's
Beste Maarten
Dit punt is naar mijn smaak het gevolg van de basiskeuzes achter StUF. De schoen wringt omdat de semantisch bedoelde choice-operatie (exclusive-or tussen statussen) rechtstreeks vertaald wordt naar een consequentie op berichtniveau (gezamenlijk voorkomen van elementen).
Een functionele wijziging is het dus naar mijn smaak niet. En het een fout noemen is wat zwaar. Ik begrijp het vooral als een noodzakelijke reparatie als gevolg van het StUF-paradigma.
Groet!
Paul
Maarten,
Ook ik vind de kwalificatie "noodzakelijke verbetering" zuiver. Het moet gewoon gebeuren, want anders werkt de beoogde functionaliteit niet.
Dus dit moet binnen versie 3.01 opgelost kunnen worden.
Ruud Kathmann
Beste community leden,
Hierbij de bijdrage van PinkRoccade Local Government.
Of dit nu als fout of wijziging van de standaard beschouwd moet worden is eigenlijk niet zo interessant. Waar het om gaat is hoe de choice uiteindelijk door alle partijen geïmplementeerd kan gaan worden. En met name op dit vlak heeft de choice een aantal nadelige consequenties.
Eerst even dit. De oplossing met een choice is in onze ogen 'ongelukkig' omdat "keuzen" noch in de 'werkelijkheid', noch in databases voorkomen. In de 'werkelijkheid' komen slechts disjuncte typen voor en in database al dan niet gevulde rubrieken. Dit betekent dat een choice-constructie semantisch-functioneel noch technisch-applicatief optimaal is. (Om de 'werkelijkheid' te modelleren zou een entiteit-met-keuzes (zeker als de keuzes kerngegevens bevatten) opgesplitst 'moeten' worden in onderscheiden (entiteit)typen. Pas dan kun je optimaal valideren en in de sfeer van (web)services de zaken scherp afbakenen en gericht sturen.
Maar om niet om te komen in de aantallen entiteittypen, lijkt het ons beter om aan de kant van de database te gaan zitten en de oude, vertrouwde stufmanier van doen gewoon te handhaven.
Er is er indertijd - na ampel beraad - voor gekozen om de oude en de nieuwe tak van kennisgevingsberichten te laten balanceren opdat vergelijkingen soepel en vlekkeloos zouden kunnen verlopen. De toegevoegde waarde van een choice-constructie weegt daar naar onze mening niet tegen op. De toegevoegde waarde bestaat er in dat met behulp van sectormodel-xsd's bepaalde relaties tussen rubrieken iets beter gevalideerd kunnen worden. Die toegevoegde waarde bestaat weliswaar maar is in onze ogen van beperkte waarde omdat allerlei waarden van andere rubrieken die niet onder de choice vallen maar er inhoudelijk wel mee samenhangen niet bij de validatie betrokken (kunnen) worden. Daar komt bij, dat als keuzemogelijkheden zogenaamde kerngegevens bevatten er ook een nieuwe definitie van het begrip kerngegevens nodig is.
Samengevat:
De vraag waar de discussie over gevoerd moet worden is of de genoemde (nadelige) consequenties van het gebruik van de choice opwegen tegen de voordelen van de beoogde scherpere definitie.
Het is onze overtuiging dat dit niet het geval is ! ! !
Met vriendelijke groeten,
Henk, Rolf en John
Communityleden,
Ik ben het met Henk, Rolf en John eens dat evt. nadelige consequenties van het gebruik van de choice op moeten wegen tegen de voordelen van de beoogde scherpere definitie.
Helaas kan ik het met de teneur van hun post niet eens zijn. Het is te gemakkelijk om te zeggen dat het gebruik van de choice constructie in XML-Schema's moet worden vermeden omdat een database daar niet mee overweg kan. Hiermee zou het gebruik van XML beperkt worden en de meerwaarde t.o.v een of ander delimited formaat afnemen.
Aan datgene waar XML en dan met name XML-Schema juist erg goed in is, nl. het vastleggen van businessrules op een gestandaardiseerde wijze, wordt dan voorbij gegaan. Het bericht zal hoe dan ook tegen de businessrules, die gerelateerd zijn aan het gebruik van het choice element, gecheckt moeten worden. Wat betekent dat je dit dus in je programmatuur zult moeten inprogrammeren. Een situatie die n.m.m. zo veel mogelijk vermeden moet worden.
Overigens zijn er database types, native XML en hybride databases, die geen probleem hebben met de opslag van dit type berichten.
Of xml-schema's nu wel zo handig zijn om er 'business rules' in te formuleren, daar kun je je twijfels over hebben. Denk bijvoorbeeld aan de enorme omvang van het huidige RSGB schema en het feit dat het desondanks geen enkele regel bevat over de relaties tussen de verwerkingssoorten.
Maar daar gaat het ons niet om, dat is een gepasseerd station. Feit is, dat de meeste 'business rules' in de verwerkingssoftware moeten worden "ingebakken", en dat het introduceren van het 'choice' element nodeloze problemen veroorzaakt en weinig soelaas biedt. De StUF standaard bestaat niet voor niets uit allerlei beslissingstabellen en algoritmen. Het algoritme voor het opnemen van elementen in een bericht houdt overigens (nog) geen rekening met choice elementen.
Niemand twijfelt er aan dat berichten in databases kunnen worden opgeslagen. Het probleem zit hem echter veeleer in de gegevens en niet in de berichten.
Het probleem is - in onze ogen - dat er vanwege de introductie van het choice-element een (te) grote breuk optreedt met eerdere versies van stuf en nodeloos veel vergt van de verwerkingssoftware.
We vatten onze concrete bezwaren nog eens samen:
In theorie zou aan de bezwaren 1-3 tegemoet kunnen worden gekomen door in elke keuzetak van een choice-element alle elementen van de overige keuzetakken op te nemen met het gefixeerde attribuut noValue=geenWaarde. Daarmee zou je de (in onze ogen: 'vermeende') voordelen van choices kunnen behouden en zou er geen grote trendbreuk op treden met oudere StUF versies. Helaas is dit met eenvoudige middelen te niet realiseren. Hetgeen eens te meer aantoont dat het vastleggen van 'business rules' in xml niet van een leien dakje gaat. (xml is daar ook niet voor bedoeld). Derhalve lijkt het ons het beste om op de reeds ingeslagen weg voort te schrijden en moeizame choices te omzeilen door ze weg te laten.
Namens GouwIT het volgende:
Het ingangsprobleem is in onze visie dat tot dusverre gegolden heeft dat het sectormodel bij definitie gelijk is aan de xsd. Hier wringt de schoen, de syntax van xsd's is niet toereikend om alle semantische eigenschappen van de berichten vast te leggen. Het gevolg hiervan is dat je de berichten zo scherp mogelijk wilt definieren. Als nu blijkt dat we tegen de grenzen aan dreigen te lopen van wat haalbaar of wenselijk is te realiseren binnen de xsd, kan dit alleen maar gecompenseerd worden door naast de xsd een document te hanteren waarin de semantische zaken geregeld worden. Volgens ons zijn er naast de choice nog wel meer benoembare issues waar de xsd niet in voldoende mate de gewenste semantiek afbakend.
Dus resumerend: we halen de choice weg en compenseren dit met een beschreven semantiek van StUF-BG berichtenverkeer, een document uitgebracht onder de vlag van de EGEM en een geheel vormend met de xsd, OF we gaan voor zo scherp mogelijk gemaakte xsd.
Ik heb er moeite mee dat het gebruik van op zich nuttige constructies binnen xsd belemmerd wordt door het feit dat leveranciers die al een implementatie gedaan hebben hierdoor aanpassingen in hun verwerkingssoftware moeten doorvoeren. Dit klemt voor mij te meer, omdat voor mijn gevoel de aanpassingen die gedaan moeten worden bij de overgang van StUF0204 naar StUF0301 vele malen groter zijn dan de aanpassingen ten gevolge van het choice probleem. Ik realiseer me dat het hier slechts om een gevoel gaat, maar ik heb in de reactie van PinkRoccade geen motivering aangetroffen waarom het zoveel werk is.
Voor wat betreft de kerngegevens lijkt de invoering me juist een winst aan scherpte geven. Je maakt expliciet dat niet zowel een buitenlands adres als een binnenlands samen kunnen voorkomen bij een persoon en je voorkomt daarmee het nodeloos opnemen van lege elementen.
Het database argument snap ik niet zo goed. In je tabeldefinitie definieer inderdaad alle gegevens in het bericht ongeacht de choice constructie. De kolommen voor de elementen die niet in de choice voorkomen laat je gewoon leeg of vul je expliciet met geenWaarde (is in dit geval strikt genomen niet nodig).
Met betrekking tot het vierde punt, kan ik me voorstellen dat op een paar andere punten ook errata nodig zijn, om een en ander te verscherpen. Voor de kerngegevens zie ik hier overigens geen noodzaak toe, omdat het schema al expliciteert dat of de ene of de andere set moet worden opgenomen. (Dit kan natuurlijk wel weer consequenties hebben voor verwerkingslogica die altijd alle kerngegevens in een bericht wil opnemen).
Splitsen in subtypen is lang niet altijd een oplossing. Denk aan het voorbeeld van de choice met buitenlands adres en verblijfsadres. Het lijkt me niet zinnig subtypen te definiëren op basis van de plek waar iemand verblijft. De choice wordt in de praktijk juist vaak voorgeschreven vanuit het objectmodel van de werkelijkheid.
We zijn ons er van bewust dat een en ander afhangt van de wijze waarop 'stufprocessoren' zijn georganiseerd, en dat 'choices' niet voor iedereen een lastig te nemen horde vormen.
In zeer algemene termen beschouwd, komt het op hier op neer: indien er 'choices' binnen entiteiten voorkomen dan zul je (in principe) voor elk stuf/database element moeten bijhouden of het deel uit maakt van een 'choice'.
En indien het element onderdeel van een 'choice' is - en het element geenWaarde heeft, of niet ondersteund wordt en indien niet een van de andere takken van de 'choice' reeds in het bericht is opgenomen - zal via een evaluatie van de inhoud van de overige onderdelen van de keuzetakken bepaald moeten worden of het element in het bericht moet worden opgenomen. (En deze evaluatie is niet triviaal omdat keuzetakken zelf uit 'choices' kunnen bestaan en ook relaties etc kunnen bevatten). Dit, tezamen met het feit dat
betekent ons inziens een fundamentele verzwaring van de verwerkingslogica alsmede een stevige verlenging van de verwerkingsdoorlooptijd. Het komt ons voor dat deze wijzigingen - en de consequenties daarvan - relatief groot zijn tov de overige wijzigingen in StUF301.
In ieder geval weegt het 'iets scherper kunnen definieren van berichten' daar - in onze optiek - bij lange na niet tegen op, en verdient het de voorkeur de oude werkwijze (elementen opnemen met: 'geenWaarde') te handhaven.
Hallo Henk,
De choice regels in StUF zijn direct afgeleid van de choices gedefinieerd in het domeinmodel. Bij een correcte implementatie van dit domeinmodel in de database kunnen vanuit de database zonder enige controle correcte StUF-berichten gegenereerd worden, mits er voor attributen zonder waarde maar geen element wordt aangemaakt. Ook bij een wijziging gaat dit vanzelf goed, zolang er maar geen algoritmen zijn die proberen oud en nieuw in evenwicht te brengen.
Voor kerngegevens kan een probleem ontstaan op het moment dat er algoritmen zijn de ontbrekende kerngegevens willen aanvullen. Een dergelijk algoritme dient dan inderdaad te weten of een kerngegeven al dan niet in choice voorkomt en beslissen om dit al dan niet op te nemen.
De kern van het probleem ligt mijns inziens in de keuze om in een deel van de software dat van nature geen domeinkennis heeft (de StUF verwerker) toch algoritmen te implementeren die die kennis nodig hebben. Laat deze beslissingen over aan het deel van de software dat wel domeinkennis: de applicatie die een StUF-entiteit vult.
In het bg0310-schema is binnen vragen inderdaad de kardinaliteit van de choice aangepast om het stellen van een vraag mogelijk te maken.
Ik waag het te betwijfelen of je zonder controle en nadere informatie berichten rechtstreeks uit de database kunt genereren. Neem bijvoorbeeld het geval van een non-existente relatie. Indien deze relatie is gedefinieerd in een choice-constructie dan mag er in sommige gevallen geen xml-tag voor gegenereerd worden, terwijl wanneer een relatie niet in een xsd-choice zit, een non-existente relatie in sommige gevallen met 'geenWaarde' in het bericht moet worden opgenomen. Hetzelfde geldt, mutatis mutandis, voor 'eenvoudige' elementen: zonder extra indicator - naast: onbekend/geenWaarde etc - lukt het je niet om berichten rechtstreeks uit de database te destilleren.
Je analyse van 'de kern van het probleem' is (gedeeltelijk) correct, maar je panacee biedt (in ons geval) geen soelaas. Een en ander zou betekenen dat we op tientallen plaatsen zowel domein kennis voor 0204, 0205, 0301 en voor elke 'minor versie' daarvan zouden moeten vastleggen en onderhouden. Gezien de 'mutatiegraad en de turn over rate' van de sectormodellen ben je dan permanent bezig je hele softwarepark continu te 'updaten'. Afgezien van dit praktisch bezwaar zul je - zolang je meerdere stufversies parallel ondersteunt - de gesignaleerde informatie omtrent de choices - al of niet declaratief - nodig hebben.
Elders op dit forum (StUF2) is 'vastgesteld' dat men in StUF2.xx ging voor 'eenvoud van verwerking' en voor 'robuustheid'. In StUF3 heeft 'visuele' overeenstemming met het RSGB de voorkeur gekregen. (Het validatie-argument heeft geringe waarde, daar veel semantisch-functionele kwesties niet met validatie tegen een structuur ondervangen kunnen worden). In onze ogen komt dit de bruikbaarheid van stuf niet ten goede.
Uit je woorden begrijp ik dat de invoering van de choice-constructie de nodige consequenties heeft voor jullie software. Ik hoop dat er via dit forum bruikbare reacties binnenkomen om deze het hoofd te bieden.
Echter in je reactie kom ik geen argumenten tegen die erop wijzen dat de choice-constructie ongewenste bijwerkingen heeft voor de standaard zelf. Zolang die er niet zijn hebben we in de StUF Expertgroep afgesproken dat de choice-constructie in de vergadering van a.s. woensdag als erratum op de stuf0301 standaard wordt aangenomen.
Beste Henk,
Wanneer er in oud en nieuw voor één van de elementen in de choice een waarde in de database vastligt, dan gaat de automatische generatie ook bij het gebruik van een choice goed. Er is een probleem als in oud of nieuw voor geen van de waarden in de choice meer een waarde in de database vastligt. Voor een gewoon StUF-element kan deze situatie zich alleen voordoen, als de oude of nieuwe waarde onbekend is.
Voor een relatie kan deze situatie zich ook voordoen als de relatie geenWaarde had of geenWaarde krijgt. In de praktijk vooronderstelt de StUF-standaard voor relaties als default dat de relatie geenWaarde had en is niet goed voorzien in de situatie dat de relatie onbekend was.
In de laatste gevallen is naïeve vulling vanuit de database niet voldoende. Overigens geldt dit ook in het geval er geen choice wordt gebruikt, want ook dan zal in oud of nieuw een element dienen te worden opgenomen.
Bij het in evenwicht brengen van 'oud' en 'nieuw' is bij de introductie van de choice inderdaad domeinkennis nodig, die zonder de introductie van de choice niet nodig is. Deze domeinkennis kan hetzij declaratief worden ingebracht in een centrale component die 'oud' en 'nieuw' in evenwicht brengt, hetzij kan dit worden overgelaten aan de applicatie die 'oud' en 'nieuw' moet vullen. In het laatste geval lijkt het voor de hand te liggen om een en ander niet te automatiseren maar over te laten aan de programmeur met zijn domeinkennis. Ik vermoed dat PinkRoccade heeft gekozen voor een centrale component die 'oud' en 'nieuw' in evenwicht brengt en dat de andere leveranciers steunen op de domeinkennis van hun programmeurs. Dit is waarschijnlijk de reden dat de andere leveranciers minder problemen hebben met de introductie van de choice in bg0310 dan PinkRoccade.
De conclusie, dat na introductie van de choice een en ander qua onderhoud onbeheersbaar wordt, deel ik niet. Waarom zouden de choice constructies vaker wijzigen dan andere zaken?
Dat er inspanning nodig is om een en ander voor bg0310 voor elkaar te krijgen begrijp ik. Ik zou daarbij zelf opteren voor een oplossing dat vanaf bg0310 het in evenwicht brengen van 'oud' en 'nieuw' nog steeds gedaan wordt door de centrale component, maar dat in geval van het voorkomen van een choice het vervolgens de verantwoordelijkheid van de programmeur is om eventueel te veel toegevoegde elementen alsnog te verwijderen. De choice komt voor op circa 13 plaatsen in een stuk of vijf entiteittypen. De inspanning hiervoor bij de realisatie van bg0310 lijkt me te overzien.
Het in de StUF-standaard verbieden dat bij het maken van schema's geen gebruik gemaakt mag worden van een schema constructie als de gaat me veel te ver.