Binnen de Lk01-berichten in een Lk03 zijn extraElementen opgenomen met de codeGebeurtenis. Deze elementen moeten worden opgenomen en een code bevatten uit een vaste lijst met waarden.
Nu staat in de documentatie van de catalogus het volgende:
"Dit attribuut wordt geplaatst binnen het huidige voorkomen van alle binnen het samengestelde bericht voorkomende enkelvoudige berichten. Daarnaast geldt dat alle 'codeGebeurtenis' extraElementen binnen een samengesteld bericht dezelfde waarde dienen te hebben."
(pagina 11/12)
Hieruit maak ik op dat het element alleen met een waarde moet zijn opgenomen in de huidige voorkomens en niet in de oude voorkomens. Omdat het element zelf (volgens tabel 5.3 uit de StUF-documentatie) altijd in beide voorkomens moet zijn opgenomen, hebben we in het oude voorkomen ‘geenWaarde’ opgenomen en in een latere poging ‘waardeOnbekend’ (vergelijkbaar aan wat in het 02.04-BAG-GBA-koppelvlak is beschreven). In beide gevallen resulteerde dit in een foutmelding op het STP.
Het STP lijkt alleen te accepteren dat het extra element is opgenomen in alle voorkomens van alle objecten en dan ook allemaal met dezelfde waarde, of dat het element helemaal niet is opgenomen in de oude situatie.
Dat lijkt mij incorrect. Het ligt voor de hand dat een vorige mutatie is verzonden met een andere gebeurteniscode dan die je voor het nieuwe bericht nodig hebt. Daarmee is het laatste bericht dus verstuurd met een andere code dan de code die in de oude situatie van het nieuwe bericht is opgenomen. Dat klopt dus eigenlijk niet. Het niet opnemen van het element spreekt tabel 5.3 van de StUF-documentatie tegen, waarin staat dat de te wijzigen/gewijzigde elementen moeten zijn opgenomen in zowel het oude als het huidige voorkomen.
Mijn vragen aan zijn nu vooral:
- Is dit een fout in het STP, is het een erratum op de berichtencatalogus, of is het een fout/onduidelijkheid in tabel 5.3 die stelt dat alle te wijzigen/gewijzigde elementen in zowel oud als huidig voorkomen moeten zijn opgenomen?
- Wat zou de waarde in het oude voorkomen moeten zijn? Of welke waarde gebruik je voor het attribuut noValue? Of moet je het element weglaten in de oude situatie?
Dit erratum is opgevoerd in de onderhoudsverzoeken als ONV0338.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Het opnemen van een metagegeven gebeurtenis in oud is onlogisch, want waarom zou je geïnteresseerd in de gebeurtenis die ten grondslag ligt aan de oude gegevens. Helaas zegt de StUF-standaard hier niets over bij de bespreking van de metagegevens. Het lijkt me dat dit punt daar geadresseerd moet worden in lijn met de interpretatie van Sid van de tekst in de berichtencatalogus. Het StUF-testplatform zal hier vervolgens op moeten worden aangepast.
Tijdens de StUF Expertgroep van 16-9-2015 is besloten dat het ‘extraElement’ ‘codeGebeurtenis’ op dezelfde wijze moet worden behandeld als alle andere elementen in de oude en huidige objecten. Tabel 5.3. van de StUF standaard geldt dus ook voor dit ‘extraElement’. Het ‘extraElement’ ‘codeGebeurtenis’ mag dus zowel in de oude als in de huidige objecten voorkomen. In de oude objecten kan het een waarde aannemen die het in een evt. voorgaand bericht heeft gekregen maar het kan ook leeg blijven maar dan natuurlijk wel met een ‘StUF:noValue’ attribute. Binnen alle huidige objecten van een Lk03 bericht moeten al deze ‘extraElement’ elementen echter wel altijd dezelfde waarde hebben. De Lk01 berichten in een Lk03 bericht hebben immers dezelfde gebeurtenis als trigger. Binnen de STP moet er dus een correctie worden aangebracht. De documentatie bij BAG berichtencatalogus moet hier ook op aangepast worden.
Het document 'Berichtcatalogus bg0310-BAG.pdf' is aangepast conform wat besproken is in de StUF Expertgroep van 16-9-2015.
In de bijgaande pdf zijn alleen de aangepaste pagina's geplaatst.
Bijlage
Tijdens de StUF Expertgroep van 21-10-2015 zijn we helaas niet aan de behandeling van het bovenstaande voorstel toegekomen. Er is daarom toen afgesproken dat de aanwezige leden eventuele bezwaren binnen 2 weken na de betreffende bijeenkomst kenbaar zouden maken. Aangezien geen bezwaren zijn geplaatst is het voorstel aangenomen en het zal dan ook meegenomen worden in pre-patch 23.
Tijdens de StUf Expertgroep van 18 november 2015 is besloten de voorgestelde oplossing op te nemen in patch 23.