XSD schema bg0310_ent_basis.xsd van bg0310_20120101_patch10 definieert het complex type AdrGrp-kerngegevens met daarin ondermeer het element ogo.locatieAanduiding, dit met een kardinaliteit 0..1.
Het zelfde schema definieert het complex type TGO-kerngegevens, met daarin de adresAanduidingGrp met type="BG:AdrGrp-kerngegevens, dus opnieuw een ogo.locatieAanduiding, dit met een kardinaliteit 0..1.
Het schema bg0310_msg_bag.xsd definieert een kennisgeving bgrKVO_Lk03 met daarin ondermeer een vboLk01 met type="BG:TGO-Lk01-bag-VBO-verbouwing, dat via een aantal tussenstappen een restrictie is van het type TGO-bag-VBO-verbouwing.
TGO-bag-VBO-verbouwing uit schema schema bg0310_ent_bag.xsd is een restrictie van een restrictie van TGO-kennisgeving uit het schema bg0310_ent_basis.xsd, maar nu heeft het element ogo.locatieAanduiding ineens een kardinaliteit 1..1, oftewel het is verplicht.
Ons inziens is dit een beetje vreemd voor een VBO. Die kan en mag nooit een locatieaanduiding hebben. Ons inziens is dit element alleen van toepassing bij een OGO en dan nog alleen in combinatie met een NUM (locatie adres) of OPR (straatadres) en niet bij een OAO (officieel adres).
Kortom, wij begrijpen deze wijze van verstuffing niet en stellen voor het element ogo.locatieAanduiding te verwijderen uit de AdrGrp-kerngegevens en op te nemen als element ogo.locatieAanduiding bij het complex type TGO-kennisgeving.
Ik ben het met Han eens dat de lokatieaanduiding niet verplicht kan worden gesteld omdat een VBO er geen mag hebben.
Voorstel: pas in een patch de kardinaliteit aan (0..1).
Het verplaatsen van het element uit de AdrGrp-kerngegevens naar het complex type TGO-kennisgeving zie ik als een verbetering die we in een nieuwe versie kunnen doen (RFC), maar zie niet de noodzaak om dit in een patch te doen (het is m.i. geen fout die moet worden opgelost om problemen te voorkomen).
Ik ben het eens met Sid. Volgens mij betreft het hier een bug dat de kardinaliteit 1.1 is in TGO-BAG-VBO-verbouwing. Dit moet gecorrigeerd worden. Het verwijderen van het element uit de AdrGrp-kerngegevens en op te nemen in het complex type lijkt ons geen goed idee. Je hebt het element nodig, in enkele gevallen, bij adressen van OGO’s. Het is dan een onderdeel van het adres. Als je het element verwijdert uit de AdrGrp-kerngegevens dan moet je aparte groepen maken voor het adres van OGO en VBO. Nu is de keuze voor 1 groep.
Ik ben het eens met SID, en ook Annemiek lijkt zich te vinden met een aanpassing van de kardinaliteit.
Maar Annemiek noemt een redenering voor het tweede voorstel, wat ik best achterwege wil laten, waar ik me niet in kan vinden. Volgens mij is het complex element adresAanduidingGrp ontstaan vanuit de (onbeargumenteerde) behoefte om het volledige adres plat te slaan. Als dat niet zou zijn gebeurd, dan had kunnen worden volstaan met het opnemen van óf een num.identificatie óf een oao.identificatie, wat dan waarschijnlijk vervangen zou zijn door een aoa.identificatie, óf een opr.identificatie, en in alle drie (twee) gevallen al dan niet gecombineerd met een ogo.locatieaanduiding.
Volgens het RSGB is de locatieaanduiding is een element van de ogo (hé, de tag is ogo.locatieaanduiding). Mijns inziens is het dus geen onderdeel van een platgeslagen adres.
De locatieaanduiding maakt onderdeel uit van de kerngegevens van een OGO en omdat hij hier noodzakelijk is, maakt hij, volgens ons, onderdeel uit van het platgeslagen adres. Overigens zal dit maar in zeer beperkte gevallen gevolgen hebben, omdat de meeste TGO's geen locatie aanduiding hebben.
Ik deel Annemiek's standpunt dat locatieAanduiding onderdeel is van de kerngegevens van een TGO, omdat locatieAanduiding bij een OGO noodzakelijk kan zijn om te komen tot een uniek en eenduidig adres. Een en ander is een consequentie van het communiceren over de subtypen LIG, STA, VBO, OGO en OTR dmv TGO. In objecten die geen OGO zijn, zal locatieAanduiding altijd gevuld worden met StUF:noValue="geenWaarde".
Blijkbaar moet dus het XSD schema bg0310_ent_basis.xsd van bg0310_20120101_patch10 worden aangepast zodat in het complex type TGO-kerngegevens binnen de adresAanduidingGrp het element ogo.locatieAanduiding een kardinaliteit 1..1 krijgt.
In TGO-kerngegevens is net als in de andere XXX-kerngegevens complexTypes geen enkel element verplicht. Het lijkt me dus niet nodig om ogo.locatieAanduiding in TGO-kerngegevens verplicht te maken.