Brk bevragen1.1 #532
Brk bevragen1.1 #532
Conversation
… erfpachtcanon. Filiatie toegevoegd (ook embedded bij KOZ. Mandeligheid toegevoegd aan Zakelijkgerechtigde.
…ng toegevoegd aan KOZ
…et coponent vervangen door identificaties.
….0 van common aangebracht
Bkr bevragen++
2 incorrecte verwijzingen hersteld
…agen daarin opgenomen (ook in de _links en de identificaties in de tenaamstelling).
Bij ZakelijkGerechtigde _embedded toegevoegd en ook hypotheken en besl…
…rechtigde_links en -_embedded
Hypotheken en beslagen verwijderd uit de tenaamstelling en zakelijkge…
|
@JohanBoer de domein property bij identificaties ontbreekt nu |
|
In een zakelijkgerechtigde.tenaamstelling en in hypotheek en in beslag zit een aantekening, maar hier wordt ook "aantekening" gebruikt als een soort synoniem voor privaatrechtelijke beperkingen. Is de aantekening in een tenaamstelling en een privaatrechtelijke beperking hetzelfde? Anders zou ik de termen anders gebruiken. zie #423 die vraagt om een specifieke beschrijving van aantekening in de verschillende situaties. |
|
een privaatrechtelijke beperking heeft isGebaseerdOpStukdeelIdentificatie en isVermeldInStukdeelIdentificaties. In de bijbehorende _links zit een link naar stuk, geen link naar deze stukdelen. Daarvoor hebben we wel een endpoint. Moeten deze dan niet ook worden toegevoegd als links? zelfde bij publiekrechtelijke beperking en iets vergelijkbaars bij isGebaseerdOpStukdeelIdentificatie. Daar is er wel een link naar stukdelen, maar is dan niet duidelijk of dit een gebaseerd of vermeld stukdeel betreft. |
|
De description van isVermeldInStukdeelIdentificaties heeft een taalfout: "De identificaties van het stukdelen waarin deze aantekening is vermeld" |
|
In KadastraalOnroerendeZaak_links zit een link publiekrechtelijkeBeperkingen. Dat is een array, wat suggereert dat hierin de links komen naar de verschillende publiekrechtelijke beperkingen. Waarom is er eigenlijk geen link naar privaatrechtelijke beperkingen vanuit de KOZ? Ook ontbreken de identificaties (naar publiekrechtelijke- en privaatrechtelijke beperkingen) in de resource. |
|
in publiekrechtelijkeBeperkingen.beperkingsgebied.werkingsgebied zit property "kadatstraalObjectIdentificatie". Moet denk ik zijn "kadastraalObjectIdentificatie" |
|
In KadastraalOnroerendeZaak_links en KadastraalOnroerendeZaak_embedded zitten de links/resources onroerendeZaakFiliatie en voorwaartseOnroerendeZaakFiliatie. Naar welk endpoint verwijzen deze links? Zo te zien is dit geen resource. Waarom is dit in embedded opgenomen? Zijn dit niet gewoon eigenschappen van de KOZ, en geen eigen resource? Deze bevat immers maar 4 properties, geen _links (zou nog best logisch geweest zijn, want er zitten kadastraalOnroerendeZaakIdentificaties in). |
|
Volgens imKad heeft een zekerheidsstelling een relatie met een hypotheeknemer. En vanuit de aantekening naar de betrokken persoon. In de resource hypotheek is er een relatie met een hypotheekhouder. Die is in de specificaties niet verder gedefinieerd. Welke is dit? De geldverstrekker (bank) of de koper van woning? En wat is gebeurd met de relatie naar de andere betrokken persoon? De wet en het BRK redeneren andersom dan in de boze buitenwereld gebruikelijk is, dus is het belangrijk dit erg duidelijk te beschrijven. N.B. valt me op dat ook in inKAD het niet nodig gevonden werd om hypotheeknemer te definiëren. Tja... |
|
Hypotheken kunnen worden gezocht op de persoon. Dit is, als ik de endpoint description goed begrijp, de Hypotheekhouder. Kunnen we die properties dan niet beter hypotheekhouder__burgerservicenummer, hypotheekhouder__kadasterpersoonidentificatie en hypotheekhouder__typepersoon noemen? idem bij beslagen. De parameternamen in de endpoint description en de feitelijke parameternamen moeten ook worden gelijkgetrokken. (zowel bij hypotheken als bij beslagen) Voor persoon__typepersoon is geen enumeratie gedefinieerd, dus het is niet duidelijk wat hier ingevuld moet worden. Hier kan gebruik worden gemaakt van PersoonType_enum zoals die in /beslagen wel wordt gebruikt. |
|
begrijp ik het goed dat hypotheken en beslagen alleen kunnen worden gezocht op resp. hypotheeknemer (de geldverstrekker) en beslaglegger, en niet op hypotheekgever (woningeigenaar)? Vult dit dan de functionele wens in van #264? |
|
beslagen is gemaakt (volgens goals canvas) t.b.v. 2 user stories:
@CathyDingemanse vult zoeken op beslagleggers zonder periode #130 in? |
|
Ik denk dat het goed zou zijn om properties die horen bij een functionaliteit te groeperen en in specificieke componenten te stoppen. Dit helpt bij het scheiden van verantwoordelijkheid en maakt het ook duidelijker waar de properties voor bedoeld zijn. Een voorbeeld: We hebben nu de KadastraalOnroerendeZaakHal die inherit van KadastraalOnroerendeZaak met _links en _embedded properties. Ik denk dat de stukIdentificaties, en zakelijkGerechtigdenIdentificaties ook in KadastraalOnroerendeZaakHal horen omdat deze nodig zijn om de templated urls in _links te kunnen expanden. Ook helpt dit bij evolvability. Components kunnen namelijk onafhankelijk van elkaar evolven. Nu moet voor elke sub-resource die wordt gelinkt en geembed de ge-inherit resource worden uitgebreid met een identificaties array. Om de API's ook onafhankelijk van elkaar te kunnen laten evolven is het denk ik nodit om de BRK core/common componenten in een eigen yaml te stoppen en daardoor misschien ook een eigen repo. |
|
verkavelObject in KadastraalOnroerendeZaak is nu gedefinieerd als een nested object. Het is beter om dit als een component te definieren en te refereren |
We hebben deze identificaties oorspronkelijk opgenomen voor gebruikers die de HAL links niet gebruiken, maar zelf de request naar de gerelateerde resource willen samenstellen. Dus deze moeten niet in de *Hal component komen. |
Dat herinner ik me nu ook. Maar dat is niet handig voor de Events/Update API, want dan krijgt je daar alle identificaties terwijl je die niet nodig hebt/zal gebruiken omdat je bij de Events/Update API de hele state van een resource krijgt |
Heb je voor de update API niet ook behoefte aan het meekrijgen van de relaties? Maken de actuele relaties van een object/resource naar een ander object/resource niet deel uit van de state? |
Volgens mij krijgt je bij een wijziging alle interne relaties (zakelijkgerechtigden, stukken) mee. Dus van die lijkt het mij nutteloos om de identificaties daarvan mee te sturen. Dit versterkt wel mijn gevoel om een BRK common/domain yaml te hebben, zodat je veel makkelijker kan inheriten en API's niet belast met elkaars requirements |
|
Adres opnemen in de resource i.p.v. embedded. Reden: we kunnen ook zoeken op adres. Voor veel gebruikers is het adres interessant. |
|
"locatieKadastraalObject" wordt "adres", waarin de adresgegevens en koppelingswijze (voorlopig) worden opgenomen |
|
in zakelijk gerechtigde zit nu isOntstaanUitAppartementsrechtSplitsing bevat nu verenigingVanEigenaren. Deze is gedefinieerd als persoonBeperkt. Moet zijn NietNatuurlijkPersoonBeperkt, zodat de enumeratie van type klopt |
Hetzelfde zie ik in:
En hetzelfde hadden en hebben we in de *Collectie._embedded:
@MelvLee is het niet erg wanneer we een object in een object definiëren bij de collecties? |
|
In KadasterStuk zit property OorspronkelijkStukIdentificatie. Dit is niet lowerCamelCase. |
De code generatoren genereren een class met de naam _embedded. Als er meerdere _embedded op deze manier zijn gedefinieerd, dan krijgt je classes met de naam _embedded gevolgd door een nummer. Dus _embedded2, enz. |
@MelvLee mag ik hieruit concluderen dat dit inderdaad ook onwenselijk is? Deze constructie gebruiken we namelijk ook in de BRP en BAG API definities. |
Het is inderdaad niet wenselijk |
Als we dit gaan aanpassen dan zijn dat breaking changes. Gaan we die direct doorvoeren ? |
Ik heb even gekeken waarom deze issue niet speelt bij BRP en BRK. Ik zie dat in de gegenereerde variants deze constructie is vervangen door een class. Dat betekent dus dat de resolver dit doet. Als test heb ik van de BRKBevragen1.1 OAS een geresolvede versie gegenereerd en ook hier zie ik dat de resolver deze constructies vervangt met een class |
|
Ik denk dat we dit nu in v1.1 moeten doen. Breaking changes (in gedrag denk nen3610) zijn vanaf livegang aangekondigd. Er zijn nog geen afnemers in productie. Dat gebeurt met deze aankondiging sowieso pas in juli. |
Ik denk dat het niet nodig is om dit asap door te voeren omdat de resolver dit al doet. |
@MelvLee zijn dit breaking changes? Er wijzigt toch niks in de interface, alleen in de onderliggende componentenstructuur? |
Volgens mij hebben we voor de "gewone" _ links en _embedded gedaan voordat we de resolver gingen gebruiken. Als de resolver dit probleem oplost, moeten we hier dan überhaupt iets aan aanpassen ?
Het lijkt mij dat als de componenten structuur gewijzigd wordt dat dan de namen van je classes wijzigen. Dat is waarom ik denk dat het breaking is, maar ik ben erg benieuwd naar Melvins conclusie. |
Het zijn geen breaking changes, alleen de namen van de onderliggende classes wijzigen. Wat de resolver doet is als hij een object tegenkomt als property dat hij deze in component. De naam van de component wordt dan de 'naam van de parent component' + '_' + 'naam van de property (idg _embedded)'. De code generator doet in principe hetzelfde, alleen gebruikt deze niet de naam van de parent als prefix maar wordt een ophogende nummer gebruikt als postfix. Omdat het geen breaking change is zou ik het nu nog niet gaan aanpassen bij de BRP, maar wel bij de BRK (er komt een 1.1) en BAG (nog niet in productie). Dan is voor altijd de naamgeving van de _links en _embedded componenten gelijk en niet toevallig omdat de resolver het op dezelfde manier doet. |
Het is inderdaad geen breacking change, maar heeft wel impact op de provider-implementatie. Die impact kan ik niet zo goed inschatten. Ik maak een aparte issue (#539) aan en vraag @rhengeveld om de impact in te schatten |
Dee pull request heb ik gedaan om de verschillen tussen de huidge master en de BRK-bevragen ++ versie inzichtelijk te maken. Het is niet de bedoeling dat deze pull request wordt gemerged.