Algemeen:
het is of "StUF-BG 3.10" of "bg0310" maar geen "StUF bg 03.10". Komt op meerdere plekken in de tekst voor
Term "berichtencatalogus" veranderen in "berichtcatalogus" (komt op meerdere plekken voor)
Sectie 1.1, tabelrij 9 (versie 0.96): de tekst over de revisies is direct overgenomen uit een feedbackverslag. Er staan vragen in en er wordt gesproken in de ik-vorm. Dit is te rauwe tekst.
Sectie 2.3: In de derde alinea wordt gesproken over vraag- en antwoordberichten. Echter deze horen niet thuis in de bag-berichtcatalogus. Deze zitten al in bg0310 zelf. Hetzelfde geldt voor de synchronisatieberichten in de vierde alinea.
Sectie 3:
In de derde alinea wordt weer gesproken over vraag-antwoord en synchronisatieberichten. Die horen hier niet thuis. Dit soort teksten zijn pas relevant in de uiteindelijke koppelvlakken. Graag het hele document scannen op dit soort teksten en verwijderen.
De laatste twee paragrafen schrappen (hier niet ter zake doende), alleen de laatste zin kan blijven staan.
Sectie 4: Hier staan (wederom) allerlei koppelvlakspecifieke eisen die niet thuis horen in een berichtencatalogus. Graag sectie herschrijven of schrappen.
Sectie 7:
Hier moet nog een stukje tekst komen rondom de problematiek van TGO-berichten zoals beschreven in 'Memo Specificatie TGO-berichten.pdf'.
De door de spreadsheet gespecificeerde restricties op de tgo-berichten worden nog steeds niet afgedwongen in het schema. Daarvoor moet de software ontwikkelaar blijkbaar nu de restricties afkijken in de berichtelementen voor de subtypen VBO, STA, LIG, etc., omdat de spreadsheet niet meer bestaat. Bovendien kunnen niet alle restrictions klakkeloos uit deze schema's worden overgenomen (bijv. brondocument is niet verplicht op TGO-niveau maar wel op VBO-niveau). De spec moet hier scherp beschrijven hoe te handelen. Anders hebben we een probleempje.
Door de keuze die gemaakt is in 'Memo Specificatie TGO-berichten.pdf' (optie 3) zitten we opeens opgescheept met migratieproblematiek m.b.t. een berichtcatalogus die nog nooit eerder officieel is geweest. Optie 2 heeft mijn voorkeur. Je moet zoveel mogelijk proberen dit soort problemen buiten de spec te houden en op een ander niveau op te lossen (bijvoorbeeld conversietooling).
Sectie 7, pagina 10: De eerste zin: "Er wordt vanuit gegaan dat een afzonderlijke gebeurtenis altijd slechts betrekking heeft op één object. " klopt niet. Bijvoorbeeld in het bericht bgrBIG_Lk03 kunnen meer dan één object worden geraakt door een gebeurtenis.
Sectie 7, pagina 11: In de laatste alinea worden wederom zaken besproken die thuis horen in een koppelvlakspecificatie maar niet in een berichtcatalogus.
Bijlage: De bijlage spreekt op verschillende plekken over een "voorstel" van extra elementen. Echter dit klinkt raar omdat een specificatie van een berichtcatalogus natuurlijk niet gebaseerd kan zijn op een voorstel dat nog niet gehonoreerd is. Ik zou de extra elementen gewoon definieren zonder te praten over een voorstel ervan uitgaande dat de extra elementen goedgekeurd worden in de aankomende expertgroepvergadering.
Schema's:
in de naamgeving van de folder en de schema's wordt nog steeds de term "koppelvlakBAG" gebruikt. Dit moet veranderd worden in "berichtcatalogusBAG"
Het samengestelde bericht bgrBIG_Lk03 bevat berichtelementen zoals BG:tgoLk01 die kan conflicteren met andere berichtelementen zoals BG:vboLk01. Leveranciers kunnen beide elementen gebruiken om een verblijfsobject te communiceren en dat schaadt de interoperabiliteit.
Niet alle restricties die op het berichtelement BG:tgoLk01 van toepassing zijn zijn in het schema afgedwongen. Dit is in strijd met de best practices.
Sectie 2.2
Het lijkt me verstandig om in de beschrijving ook iets te zeggen over + objecten. NU staat er alleen iets over + entiteiten en attributen. Mijn voorkeur heeft het om in beschrijving op te nemen dat alle objecten uitgewisseld worden middels dit koppelvlak. Of ze nu authentiek zijn of niet maakt niet uit.
Sectie 2.3
In de koppelvlakbeschrijving kan wel opgenomen worden dat vraag/antwoord berichten relevant zijn. BAG applicaties kunnen voorzieningen hebben om een StUF-BG vraag te beantwoorden.
Hoofdstuk 7
Waarom is de kennisgeving gemLk01 van belang? De BAG kent toch geen gemeentecode?
Algemeen:
Memo omzetting excel schema's:
Alle reacties heb ik verwerkt. Nieuwe documenten heb ik onder 'documenten' op de site geplaatst.
Nog een paar opmerkingen over de schema's in KoppelvlakBAG20110707.zip:
Erratum ERR183 is nog niet verwerkt (zie http://www.kinggemeenten.nl/gemma/gegevens-en-berichten-(stuf)/forums/stuf_3/1358-Output-in-wsdl-operations-BAG-WOZ-koppelvlak )
Het valt me op dat bij het element bgrMSB_Lk03 voor het bericht voor Melding start bouw er slechts 1 pand kan worden opgenomen in het bericht, terwijl in het processenhandboek word gesproken van "pand(en)".
In het WSDL schema bg0310.koppelvlakBAG.ontvangAsynchroonBericht.wsdl staat als attribuut van het <definitions> element "StUF-WOZ0310". Ik dacht dat het de bedoeling was de WOZ referenties eruit te halen?
Nog een opmerking: In het type TGO-Lk01-bag-VBO-toevoegen is de minOccurs en maxOccurs van het object 2. Ik zou denken dat deze beide 1 moeten zijn, het gaat immers om een toevoeging.
Nog een opmerking:
In het type AOA-bag-toevoegen is de groep woonplaatsWaarinGelegen verplicht gesteld door de minOccurs op 1 te zetten. Echter volgens RSG Basisgegevens 2.01 deel II word de overeenkomstige relatie "ADRESSEERBAAR OBJECT AANDUIDING ligt in WOONPLAATS" alleen opgenomen indien het object is gelegen in een andere woonplaats dan de openbare ruimte waaraan de adresseerbaar object aanduiding is gerelateerd. De groep moet dus denk ik dus niet verplicht zijn.
De opmerkingen uit de post van 15-7-2011 14:43:26 zijn alle drie terecht. Ik heb ze verwerkt in een nieuwe versie van de schema's, die te zijner tijd weer gepubliceerd zal worden.
Ook de opmerking over TGO-Lk01-bag-VBO-toevoegen is terecht en aangepast in de schema's.
Ook je derde opmerking is correct. De groep is optioneel gemaakt.
Bedankt voor het kritisch reviewen van de schema's.
Nog een opmerking:
Bij een hoop typen is het attribuut verwerkingssoort niet opgenomen (Voorbeeld AOA-bag-muterenCorrigeren). Nu is aan de naam van het type vaak wel te zien wat de verwerkingssoort zou moeten zijn, maar als ik in de StUF standaard kijk zie ik in paragraaf 5.2.2 geen uitzondering die het gebruik van dit attribuut optioneel maakt. Ik denk dus dat het attribuut toch moet worden opgenomen.
De verwerkingssoort is als verplicht attribute gedefinieerd op het complexType AOA-kennisgeving dat gerestricted wordt. Het is daardoor ook een verplicht attribute op alle restrictions van AOA-kennisgeving en dus ook op AOA-bag-muterenCorrigeren. Probeer maar eens een Lk03-bericht te valideren waarin geen verwerkingssoort zit.
Correct, ik zie dat de verwerkingssoort inderdaad wel vereist is. Ik was op het verkeerde spoor gezet door gebruikte tools, die geen code genereerde voor het attribuut verwerkingssoort. Dat zal ik toch zelf moeten uitzoeken dus.
Beste mensen,
In de afgelopen bijeenkomst van de StUF Expertgroep is besloten dat de BAG-berichtcatalogus kan worden goedgekeurd als aan de volgende drie voorwaarden is voldaan:
Ad 1) De expertgroep achtte scenario 3 niet wenselijk. Dit scenario staat conflicterende elementen toe in een choice-constructie waardoor interoperabiliteit niet meer kan worden gewaarborgd. Bijvoorbeeld, het samengestelde bericht bgrBIG_Lk03 bevat berichtelementen zoals BG:tgoLk01 dat kan conflicteren met andere berichtelementen zoals BG:vboLk01. Beide kunnen dezelfde informatie bevatten maar als de ene applicatie kiest voor het BG:tgoLk01 element en de andere applicatie voor het BG:vboLk01 element, dan kunnen ze niet met elkaar praten.
Ad 3) Leveranciers krijgen tot woensdag 27 juli einde dag de tijd om te reageren. Indien de reactie positief is kan de Waarderingskamer de specificaties aanpassen en kan de definitieve goedkeuring via het forum verlopen zonder fysieke bijeenkomst van de expertgroep. Bij negatieve reactie zal de beslissing van KING de uiteindelijke doorslag geven.
Met vriendelijke groet,
Henri Korver
Voorzitter StUF Expertgroep
Nog een paar opmerkingen:
In het type TGO-bag-VBO-toevoegen word voor het element adresAanduidingGrp het type AdrGrp-bag gebruikt, en voor het type TGO-bag-OGO-toevoegen het type AdrGrp-bag-kerngegegvens. Wat is de reden van dit verschil? In het type AdrGrp-bag-kerngegegvens zijn alle identificaties optioneel (num.identificatie, oao.identificatie), of zelfs uitgesloten (wpl.identificatie, gor.identificatie, opr.identificatie). Ik weet niet waarom het bij een OGO niet is toegestaan de identificaties te versturen, en bij een VBO wel.
In het document stuf.bindingen staat in paragraaf 4.2 "Het gebruik van het <portType> element" dat bij OntvangAsynchroon de Bv01-, Bv03-, Fo01- en Fo03-berichten in bepaalde gevallen moeten worden opgenomen. Deze staan allemaal in bg0310.koppelvlakBAG.ontvangAsynchroonBericht.wsdl, behalve Bv01. Het lijkt me dat deze wel nodig is om de bevestiging op het asynchrone bericht te verzenden.
Er is mogelijk bewust gekozen voor verschillend gedrag voor AOT's (LIG, STA en VBO) en OGO en OTR. De BAG ziet adressen als attributen van AOT en kan complete nummeraanduidingen meeleveren met AOT's. OGO's en OTR's lenen hun NUM of hebben een eigen OAO die onafhankelijk van de OGO of OTR is gedefinieerd. Daarom is er bij OGO of OTR voor gekozen om alleen de kerngegevens in het bericht op te nemen.
Je kunt je overigens afvragen of dit in het licht van de modellering in bg0310 wel de meest gelukkige keuze is. Een alternatief is om in de gebeurtenis voor toevoegen van een TGO niet alleen de TGO toe te voegen zoals nu het geval is, maar ook de AOA's als afzonderlijke objecten. Als je hiervoor kiest, dan is overal waar je naar een adres verwijst binnen TGO de kerngegevens voldoende.
Gaarne de mening van anderen over dit punt.
Voor wat betreft de Bv01-berichten. Deze komen niet voor binnen dit koppelvlak. Op geen enkel bericht hoeft gereageerd te worden met een Bv01-bericht. De bevestiging op een asynchroon bericht is het Bv03-bericht.
Wij zijn tegen het gebruik van scenario 2 of 3 en voor scenario 1.
De specificaties voor het BAG-WOZ koppelvlak zijn in het voorjaar van 2010 vastgesteld en voorgelegd aan de StUF Expertgroep. Toen zijn deze goedgekeurd mits het beheermodel zou worden aangepast en de XSD zouden worden aangepast zodat de berichten gebruik maken van de bg0310 namespace.
De best practices voor de verstuffing zijn de afgelopen maanden op papier gezet (en bij mijn weten nog steeds niet gedgekeurd laat staan van kracht).
Het aanpassen van de XSDs comform de best practices is op zich een goede zaak. Maar de voorgestelde aanpassing betekent dat een ontvangende appplicatie conform de vigerende XSDs niet voldoet aan de voorgestelde XSDs, waardoor de voorgestelde aanpassing niet backwards compatibel is met de vigerende XSDs.
Wij hebben inmiddels een zendende applicatie conform de vigerende XSDs en een ontvangende applicatie conform de vigerende XSDs. Doorvoeren van de aanpassing conform scenario 2 houdt in dat beide applicaties niet voldoen aan de nieuwe XSDs. Doorvoeren van de aanpassing conform scenario 3 houdt in dat de ontvangende applicatie niet voldoet aan de nieuwe XSDs.
De gewraakte aanpassing behelst het afdwingen van een specifieke inhoud; inhoudelijk verandert er daarnaast weinig.
Wij stellen daarom voor de aanpassing te behandelen als een wijziging en niet als een erratum. Dus in te voeren met ingang van een nieuwe versie van BG.
Beste Han,
jammer dat je niet opteert voor scenario 2, in mijn ogen de mooiste en beste oplossing. Ik kan natuurlijk niet onder jullie motorkap kijken, maar het lijkt mij geen hele ingewikkelde aanpassing. Zou je nog één keer kunnen overwegen of het toch niet mogelijk is om te kiezen voor het algemeen belang?
Mocht dit niet mogelijk zijn dan zou ik eventueel kunnen instemmen met scenario 1 mits de beslistabellen in spreadsheet 'Inventarisatie Gebeurtenissen BAG WOZ versie 0.9.7.xls' worden vervangen door een hulpschema waarin de verplichte velden zijn gespecificeerd door middel van het restriction-mechanisme van XML Schema . Dit hulpschema zou dan hetzelfde schema zijn als het schema van scenario 2 maar dan zonder berichtelementen. Dit schema wordt puur gebruikt om de beslistabellen te specificeren, het speelt geen rol als validerend schema van de berichtcatalogus. Daarvoor mogen alleen de oorspronkelijke schema's gebruikt worden. Ongeveer hetzelfde principe wat we hanteren bij de kerngegevens, die worden gespecificeerd doormiddel van XML Schema, echter zonder ze te betrekken in de validatie.
Mvg,
Henri Korver
Henri,
Wij zwichten voor de druk vanuit de StUF expert groep, mits gekozen wordt voor scenario 2, omdat deze dan op de meest duidelijke wijze de correcte inhoud afdwing en geen ambiguiteit introduceert. Ik citeer:
Bij de omzetting wordt het TGO bericht in de xsd-schema gesplitst in VBO, STA/LIG, OGO en OTR-berichten. Per type bericht kunnen dan specifieke eisen worden geformuleerd, bijvoorbeeld dat een brondocument wel verplicht is bij VBO en STA/LIG, maar niet bij de andere typen. Nadeel van deze oplossing is dat de reeds in de praktijk gebruikte "TGO-berichten" niet voldoen aan de schema-validatie met deze schema's
Einde citaat.
GeoTax betreurt het dat de regels uit het beheermodel niet worden gehanteerd en dat onze bezwaren met betrekking tot bestaande implementaties niet worden gehonoreerd. We hopen dat bij toekomstige wijzigingen het beheermodel wel gehanteerd gaat worden.
Han,
Het siert jou en GeoTax om te kiezen voor het algemene belang, te weten scenario 2. Mijn dank daarvoor! Dan kan de Waarderingskamer de laatste puntjes op de spreekwoordelijke i zetten en ligt er als het goed is niets meer in de weg voor een snelle vaststelling.
Mvg,
Henri
Het valt me op dat in het bericht BGR-BSLSP het element gebruiksdoel verplicht is in het type TGO-Lk01-bag-AOTnietVBO-toevoegen. Echter volgens het RSGB is dit element voor een OTR van toepassing, en niet op een STA. Is dit een fout? Of is dit een nog niet doorgevoerde RFC, zoals geldt voor de GBO-specifieke elementen in ditzelfde bericht:
http://www.kinggemeenten.nl/gemma/gegevens-en-berichten-%28stuf%29/forum...
Hallo Joris,
Je hebt helemaal gelijk. Ik heb een en ander verbeterd in de schema's en deze opgeleverd aan de Waarderingskamer.
Maarten
In de spec's van de BAG-berichtcatalogus wordt het extraElement codeGebeurtenis geintroduceerd. Wat is hiervan de toegevoegde waarde? Immers de code van de gebeurtenis is ook af te leiden uit de elementnaam van het samengestelde bericht.
Bij het ontwerp van berichten wordt ernaar gestreefd om informatie beschikbaar te hebben op de plek waar je die logisch verwacht. De naam van een berichtelement is vanuit dat oogpunt niet de meest gelukkige plek voor het meegeven van de code van een gebeurtenis. Het heeft de voorkeur dat de berichtnaam vanuit het oogpunt van de verwerking betekenisloos is en dat de gewenste betekenis wordt gedefinieerd binnen een StUF-entiteit.