Bij het testen van een bericht uit de bag berichtencatalogus in het StUF Testplatform lopen we er tegenaan dat in het complexType 'TGO-bag-OGO-afvoeren' het element 'BG:authentiek' niet aanwezig mag zijn terwijl het wel in het complexType TGO-kerngegevens is opgenomen.
Is dit correct of moet het bewuste element ook in het eerste complexType gewoon aanwezig zijn?
Wat mij betreft is dit correct, omdat dit bericht uitsluitend wordt gebruikt voor een OGO en een OGO geen authentiek object is en dus het element authentiek daarin geen zin heeft.
Misschien om zoveel mogelijk eenduidig te houden is het fijn om niet teveel uitzonderingen te hebben.
Hoi Robert, je hebt wel een punt denk ik. Het element BG:authentiek is gedefinieerd als een kerngegeven van TGO en kan dus strict genomen niet worden weggelaten in het genoemde complexType als je wilt voldoen aan StUF. Echter ben ik wel een voorstander om de definitie van het begrip 'kerngegevens' wat flexibeler te laten zijn. Dus naast de definitie XXX-kerngegevens de mogelijkheid willen bieden om conditionele regels toe te voegen in de beschrijving van het sectormodel of koppelvlak zoals: ALS de typering van TGO gelijk is aan 'Overig gebouwd object' DAN is BG:authentiek geen kerngegeven.
Het antwoord van Henri behoeft denk ik nog wat toelichting.
In mijn vraag geef ik al aan dat in het complexType 'TGO-bag-OGO-afvoeren' het element 'BG:authentiek' niet aanwezig mag zijn terwijl het wel in het complexType ‘TGO-kerngegevens’ is opgenomen. Inmiddels is mij duidelijk dat OGO gebaseerd is op TGO maar zelf geen authentiek object is (zie antwoord van Maarten). Daarmee is verklaard waarom ‘BG:authentiek’ niet aanwezig mag zijn.
De leverancier van het StUF Testplatform heeft geconstateerd dat dit echter voor een toename van de complexiteit zorgt. Dit is nl. een uitzondering op de regel dat als het attribute sleutelOntvangend ontbreekt alle kerngegevens aanwezig moeten zijn. In dit geval zou authentiek dus wel mogen ontbreken. Dit betekent echter dat alleen voor deze context de testregel aangepast moet worden. De implementatie van deze uitzondering zorgt voor nogal wat hoofdbrekens.
De grote vraag is dus of hier valt te simplificeren? Behoort ‘authentiek’ bijvoorbeeld echt tot de kerngegevens of is het een metagegeven dat ook in de kerngegevens gewenst is? Binnen het StUF Testplatform zorgt deze constructie dus voor een probleem. Het commentaar van de leverancier is als volgt:
Ik zie nog niet hoe wij deze uitzondering kunnen implementeren.
Dit betekent dat kerngegevens anders mogen zijn voor hetzelfde entiteitytpe maar in verschillende contexten.
… het wordt wat (onnodig) complex.
De vraag waar ik nu mee zat, en die nu in feite is beantwoord door Henri is of deze check toch door de leverancier mogelijk gemaakt moet worden of moeten wij (als dat tenminste kan) de nu gebruikte constructie in de schema’s aanpassen?
Tot zover de extra toelichting.
Samenvattend zijn er de volgende twee mogelijkheden om weer te voldoen aan de StUF-standaard: 1) Het element 'BG:authentiek' opnemen in het complexType 'TGO-bag-OGO-afvoeren'. Als het een OGO betreft, dan heeft dit element de waarde "N" (Nee). 2) Afspreken dat in de context van TGO het element 'BG:authentiek' in bepaalde typeringen (bijv: Overig gebouwd object, Overig terrein) niet als kerngegeven mag worden opgenomen. Ad 1) Deze oplossing is het gemakkelijkst te implementeren, maar is niet backwards compatible Ad 2) Wel backwards compatible, maar iets moeilijker te implementeren. Nog een kleine nabrander. Het element 'BG:typering' in het complexType 'TGO-bag-OGO-afvoeren' is nillable. Dat is mijns inziens een bug omdat het altijd gevuld moet zijn met de waarde 'Overig gebouwd object'.
Naar aanleiding van dit probleem hebben we 2 errata opgevoerd in de onderhoudsverzoeken te weten ONV0331 en ERR0332.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
M.b.t. ONV0331 heeft de StUF Expertgroep van 18 juni 2014 besloten nu geen wijzigingen door te voeren en het te houden zoals het nu is. De StUF Expertgroep vindt het geen argument om het probleem op te lossen omdat de StUF Testplatform er een probleem mee heeft. Het StUF Testplatform zal de afwijking dus moeten implementeren. Dit erratum wordt omgezet naar een RFC (RFC0331).
Waarom staat dit erratum weer op de agenda, als er in de vorige vergadering een besluit over is genomen?
Tijdens de StUF Expertgroep van 17 september 2014 is KING gevraagd in de discussie even duidelijkheid te scheppen met betrekking tot de historie van erratum ERR0332. Volgens Annemiek is dit tijdens de voorgaande vergadering doorgeschoven omdat er in de vorige vergadering te weinig mensen aanwezig waren.
Bij deze de uitwerking m.b.t. de historie van issie ERR0332.
Bijlage
Tijdens de StUF Expertgroep van 28-1-2015 is geconstateerd dat het erratum niet backwards compatibel is. De StUF Expertgroep besluit het erratum dan ook niet door te voeren in de huidige versie en er een RFC (RFC0332) van te maken. Het staat nu een correcte werking niet in de weg.