Opmerkingen uit #532 verwerken #309
Comments
|
This comment originally might have been created by someone else. @JohanBoer ik heb nog een paar opmerkingen over de laatste versie (die van gisteren) die we vandaag nog niet konden bespreken:
|
|
This comment originally might have been created by someone else.
Jazeker is die nodig, ook om gerelateerde rechtsfeiten en/of betrokken objecten in samenhang te kunnen beoordelen. |
Originally created by JohanBoer (kadaster/BRK-bevragen#536):
@JohanBoer de domein property bij identificaties ontbreekt nu
-- Wijzigingen t.a.v. domein overgenomen in de master
-- Domein toegevoegd bij Abstractstuk, Stukdeel, Hypotheek, Beslag en Publiekrechtelijke beperkingen
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 zakelijkgerechtigde met identificatie #423 die vraagt om een specifieke beschrijving van aantekening in de verschillende situaties.
-- Ik kan aan de aardAantekening niet zien of een aantekening een privaatrechtelijke beperking is of niet. Vraag: zijn alle aantekeningen op de tenaamstelling en op het kadastraal object privaatrechtelijke beperkingen ? Zo ja, dan moet er een link bij zakelijk gerechtigde en KOZ opgenomen worden naar de privaatrechtelijke beperking. Dan wordt ook de property "aantekening" in tenaamstelling omgenoemd naar privaatrechtelijkeBeperkingIdentificatie. en bij de KOZ een property privaatrechtelijkeBeperkingIdentificatie worden toegevoegd
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?
--isGebaseerdOpStukdeel en isVermeldInStukdelen opgenomen in PrivaatrechtelijkeBeperking_links
zelfde bij publiekrechtelijke beperking
--isGebaseerdOpStukdeel en isVermeldInStukdelen opgenomen in PubliekrechtelijkeBeperking_links
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.
--isGebaseerdOpStukdeel en isVermeldInStukdelen opgenomen in ZakelijkGerechtigde_links en Beslag_links en hypotheek_links
--De vraag staat nog open of het volledige pad binnen de resource opgenomen moet worden om gebruik van de templated link te kunnen maken.
De description van isVermeldInStukdeelIdentificaties heeft een taalfout: "De identificaties van het stukdelen waarin deze aantekening is vermeld"
--Op 8 plekken aangepast
In KadastraalOnroerendeZaak_links zit een link publiekrechtelijkeBeperkingen. Dat is een array, wat suggereert dat hierin de links komen naar de verschillende publiekrechtelijke beperkingen.
Dan is er ook een endpoint /kadastraalonroerendezaken/{kadastraalonroerendezaakidentificatie}/publiekrechtelijkebeperkingen/{identificatie} nodig. Alternatief is om deze link niet als array te definiëren.
--/kadastraalonroerendezaken/{kadastraalonroerendezaakidentificatie}/publiekrechtelijkebeperkingen/{publiekrechtelijkebeperkingidentificatie} toegevoegd
Waarom is er eigenlijk geen link naar privaatrechtelijke beperkingen vanuit de KOZ?
--/kadastraalonroerendezaken/{kadastraalonroerendezaakidentificatie}/privaatrechtelijkebeperkingen/{privaatrechtelijkebeperkingidentificatie} toegevoegd
Ook ontbreken de identificaties (naar publiekrechtelijke- en privaatrechtelijke beperkingen) in de resource.
--Publiek- en privaatrechtelijke identificatie opgenomen in de KOZ.
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).
--De componenten OnroerendeZaakFiliatie en VoorwaardeFiliatie verwijderd en 1 component Filiatie gemaakt. Uit dat component de identificatie verwijderd. Uit KadastaalOnroerendeZaak_links de links naar filiaties verwijderd. UitKadastraalOnroerendeZaak_embedded ook de filiaties verwijderd.
Moet ik nu in de KadastraalOnroerendeZaak_links een link isOvergegaanIn en een link IsOntstaanUit toevoegen ?
Als dat zo belangrijk is, waarom niet als comfortgegeven opnemen in de kadastraal onroerende zaak resource?
Zolang de BAG API niet live is, bestaat die resource niet en kan de verwijzing daarnaar (in _links) ook niet worden opgenomen.
--Adres uit de KadastraalOnroerendeZaak_embedded verwijderd. Adres toegevoegd als gegevensgroep aan de KadastraalOnroerendeZaak Die property heet nu "adres". Moet dat "objectlocatie" worden ? en maken we hier hergebruik van de adres-definitie uit de BAG ?
Voorheen zat hierin alleen _links, geen _embedded. Er was toen onderscheid tussen ZakelijkGerechtigdeHal en ZakelijkGerechtigdeHalCollectie__embedded. Dat is nu verwijderd, ZakelijkGerechtigdeHalCollectie__embedded bestaat niet meer.
--Inmiddels heb ik deze constructie aangepast door een zakelijkgerechtigdeHalBasis met alleen links te introduceren.
Ik had niet door dat we zakelijk gerechtigden ook gingen uitbreiden, ik dacht dat die af was.
In mandeligheid zit property "heeftHoofdKadastraalOnroerendeZaakIdntificaties". Dat moet zijn "heeftHoofdKadastraalOnroerendeZaakIdentificaties". ** aangepast naar hoofdzaakIdentificaties**
Verder ontbreekt de toelichting op mandeligheid en op de properties daarin. Wat is mandeligheid? Wat zijn hoofd kadastraal onroerende zaken? description mandeligheid toegevoegd. Description hoofdzaak ontbreekt ook in het IMKAD. voorstel achterhalen ?
Kan die naam niet korter? Bijvoorbeeld door "heeft" weg te laten? voorstel korte naam: "hoofdzaakIdentificaties" op deze manier doorgevoerd
Wat voegt die mandeligheid.identificatie toe? Dat is geen resource die op te vragen is. Is men werkelijk geïnteresseerd in het nummertje dat daarbij hoort? Zeg het maar. Dit nummertje wordt nu met de BRK-levering wel geleverd. Dat was het argument om het toe te voegen
Moeten de relaties naar de mandeligheid hoofd KOZ niet ook in _links worden opgenomen?
_links.hoofdzaak toegevoegd
Moet er niet juist ook het stuk(deel) (of de stukdelen) dat bij de mandeligheid hoort worden toegevoegd als property? toegevoegd
in zakelijk gerechtigde zit nu isOntstaanUitAppartementsrechtSplitsing bevat nu verenigingVanEigenaren. Moet dit dan niet ook worden toegevoegd aan _links? verebigingVanEigenaren toegevoegd aan de _links. Moet hier onderscheid gemaakt orden op basis van het pad ? (isOntstaanUit en IsBetrokkenBij)
@CathyDingemanse algemene vraag over deze toevoegingen: moeten voor alle identificaties die we nu toevoegen ook links worden opgenomen naar betreffende personen, stukdelen, kadastraalonroerendezaken, enz.?
Een stuk kan een kadasterstuk zijn of een terInschrijvingAangebodenStuk. Nu is dit zo gemodelleerd dat een stuk deze twee als property heeft. Dit is precies het soort modellering die we bij de adresseerbare objecten zo hard hebben afgewezen.
Dit betekent bijvoorbeeld dat de identificatie van een stuk op twee mogelijke plekken in de resource kan staan. Dit geldt voor alle overlappende properties, die dus op twee plekken kunnen staan en dus vanuit twee plekken gemaakt moeten worden. Dus moet de gebruiker eerst aftesten welk van de twee bestaat, om daaruit de waarden te halen. Gaarne inhoudelijk bediscussieren. Dit stuk was al gemodelleerd en heb ik alleen overgenomen
in een stuk is het stukdeel opgenomen i.p.v. een subresource (op zich prima, hebben we geloof ik zo besproken). Maar er is wel een embedded (sub)resource kadasterverzoeken. Waarom is dat niet ook opgenomen in de resource stukken?
In kadasterverzoeken zit een self-link. Maar er bestaat geen endpoint waarnaar deze kan verwijzen.
--Kadasterverzoeken als gegevengroep opgenomen in AangebodenStuk. AangebodenStuk_embedded verwijderd.
in stukken.terInschrijvingAangebodenStuk zit stukdelen, maar ook stukdeelIdentificaties. In de stukdelen zit ook al een identificatie, dus hetzelfde gegeven is twee keer opgenomen.
--stukdeelIdentificaties verwijderd
In stukdeel zit property "omschrijvingToptgrafischeMutatie". Dit moet zijn omschrijvingTopografischeMutatie.
--aangepast
in publiekrechtelijke beperking zit property "bevoegdGezag" die via de identificatie (PersoonBeperkt) verwijst naar een persoon. Moet dit dan niet ook als link worden toegevoegd?
--Die verwijzing heb ik aangepast naar de NietNatuurlijkPersoonBeperkt. Ik heb een link "bevoegdGezag" toegevoegd aan de _links
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?
--In de specificaties staat bij de endpoints dat de hypotheekhoude de geldverstrekker is. Dit staat ook bij de property Hypotheekhouder, maar die description wordt niet getoond in de swagger gui.
Ik heb bij aantekening de betrokkenpersoonidetificaties opgenomen (array verwijst naar persoonBeperkt). Ik heb in alle resources waarin de aantekening als gegevensgroep is opgenomen een link toegevoegd naar de betrokkenPersoon. (beslag, Hypotheek, PrivaatrechtelijkeBeperking, zakelijkgerechtigd
De wet en het BRK redeneren andersom dan in de boze buitenwereld gebruikelijk is, dus is het belangrijk dit erg duidelijk te beschrijven. zoals gezegd, ik heb het op drie plaatsen in de specificatie gevonden. Hopen dat Swaggerhub snel OAS3.1 gaat ondersteunen. dan zie je die description ook weer in de GUI.
N.B. valt me op dat ook in inKAD het niet nodig gevonden werd om hypotheeknemer te definiëren. Tja... --> die relatie is gedefinieerd en heet heeftHypotheeknemer. naar een _persoon. Kan een bank zijn, maar ook een natuurlijk persoon.
--We moeten doen wat het duidelijkst is voor de consumer. Zoals het nu is is het wel conform de naamgevingsconventie die we toepassen voor parameters. De parameters komen uit de verwijzing naar 4 verschillende typen resources Een hypotheekhouder is 1 van die resources.Maar als dat niet duidelijk genoeg is passen we het aan. wel graag eerst bespreken wat wijzheid is.
Besproken: De prefix wordt zoals voorgesteld door Frank en de type wordt verwijderd.
idem bij beslagen. idem reactie
Besproken: De prefix wordt zoals voorgesteld door Frank en de type wordt verwijderd.
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. aangepast
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 selflinks toevoegen bij privaatrechtelijke beperking, beslagen, en hypotheken #264?
--In selflinks toevoegen bij privaatrechtelijke beperking, beslagen, en hypotheken #264 staat als comment dat het kadaster niet registreert wie de onderpandgever is.
beslagen is gemaakt (volgens goals canvas) t.b.v. 2 user stories:
#130 vraagt om beslagleggingen in een periode
#68 wil inzicht in relaties van eigenaren
@CathyDingemanse vult zoeken op beslagleggers zonder periode #130 in?
En hoe biedt zoeken op beslagleggers inzicht in relaties van eigenaren?
In de Goalscanvas is de periode (en RSN en KvKnr) heel lichtgrijs gemaakt. Ik vermoed dat dat was omdat we in versie 1.0.0 en versie 1.1.0 deze functionaliteit nog niet geÏmplementeerd konden krijgen. Terechte vraag of wij die periode, kvknr en RSIN nu wel moeten specificaeren
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.
Stel dat je dezelfde resource wilt gebruiken in een "plain json" uitwisseling en je doet bovenstaand, dan ben je dus de identificatie van je gerelateerde reource kwijt. Ik denk dus dat die identificaties bij de resource zelf horen
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.
Nu zijn OnroerendeZaakFiliatie, VoorwaartseOnroerendeZaakFiliatie en PubliekrechtelijkeBeperking toegevoegd omdat deze nodig zijn voor de BRK Events/Update API. Zoals het nu is opgezet moet er van de BRK bevragen API een release worden gemaakt, als er van de BRK Events/Update API een release wordt gemaakt.
Dit is een mooi vraagstuk. Moet er een repository van contentcomponenten opgezet worden ? Krijgen we dan "standaard" compnenten waar API-bouwers zich aan moeten conformeren ? Klinkt als een centraal model op basis waarvan je componenten definieert. Dit is een discussie waard.
verkavelObject in KadastraalOnroerendeZaak is nu gedefinieerd als een nested object. Het is beter om dit als een component te definieren en te refereren
aangepast
Ik denk dat de stukIdentificaties, en zakelijkGerechtigdenIdentificaties ook in KadastraalOnroerendeZaakHal horen omdat deze nodig zijn om de templated urls in _links te kunnen expanden.
*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
Hier gaarne een discussie / ontwerpsessie aan wijden
Adres opnemen in de resource i.p.v. embedded. Reden: we kunnen ook zoeken op adres. Voor veel gebruikers is het adres interessant.
Is wel schending van principe "halen bij de bron", zoals we ook bij naam (omschrijving) en adres van personen hebben gedaan. Zijn comfortgegevens.
Adres ook behouden als link.
Adres is opgenomen als gegevensgroep in de KOZ
"locatieKadastraalObject" wordt "adres", waarin de adresgegevens en koppelingswijze (voorlopig) worden opgenomen
is nu zo opgenomen in de KOZ
in zakelijk gerechtigde zit nu isOntstaanUitAppartementsrechtSplitsing bevat nu verenigingVanEigenaren. Deze is gedefinieerd als persoonBeperkt. Moet zijn NietNatuurlijkPersoonBeperkt, zodat de enumeratie van type klopt
**aangepast
verkavelObject in KadastraalOnroerendeZaak is nu gedefinieerd als een nested object. Het is beter om dit als een component te definieren en te refereren
**aangepast
Hetzelfde zie ik in:
En hetzelfde hadden en hebben we in de *Collectie._embedded:
KadastraalOnroerendeZaakHalCollectie._embedded
HypotheekHalCollectie._embedded
KadasterNietNatuurlijkPersoonHalCollectie._embedded
BeslagHalCollectie._embedded
PubliekrechtelijkeBeperkingHalCollectie._embedded
ZakelijkGerechtigdeHalCollectie._embedded
KadasterNatuurlijkPersoonHalCollectie._embedded
PrivaatrechtelijkeBeperkingHalCollectie._embedded
@MelvLee is het niet erg wanneer we een object in een object definiëren bij de collecties?
Dit is in ieder geval ook de manier waarop we dit in de BRP-Bevragen API gedaan hebben
KadastraalOnroerendeZaakHalCollectie:
type: "object"
properties:
_links:
$ref: "https://raw.githubusercontent.com/VNG-Realisatie/Haal-Centraal-common/v1.0.0/api-specificatie/common.yaml#/components/schemas/HalCollectionLinks"
_embedded:
type: "object"
properties:
kadastraalOnroerendeZaken:
type: "array"
items:
$ref: "#/components/schemas/KadastraalOnroerendeZaakHal"
In KadasterStuk zit property OorspronkelijkStukIdentificatie. Dit is niet lowerCamelCase.
aangepast
verkavelObject in KadastraalOnroerendeZaak is nu gedefinieerd als een nested object. Het is beter om dit als een component te definieren en te refereren
Hetzelfde zie ik in:
Hypotheek_links.hypotheekhouder
PubliekrechtelijkeBeperking.beperkingsgebied
ZakelijkGerechtigde.mandeligheid
Beslag_links.beslaglegger
En hetzelfde hadden en hebben we in de *Collectie._embedded:
KadastraalOnroerendeZaakHalCollectie._embedded
HypotheekHalCollectie._embedded
KadasterNietNatuurlijkPersoonHalCollectie._embedded
BeslagHalCollectie._embedded
PubliekrechtelijkeBeperkingHalCollectie._embedded
ZakelijkGerechtigdeHalCollectie._embedded
KadasterNatuurlijkPersoonHalCollectie._embedded
PrivaatrechtelijkeBeperkingHalCollectie._embedded
@MelvLee is het niet erg wanneer we een object in een object definiëren bij de collecties?
KadastraalOnroerendeZaakHalCollectie:
type: "object"
properties:
_links:
$ref: "https://raw.githubusercontent.com/VNG-Realisatie/Haal-Centraal-common/v1.0.0/api-specificatie/common.yaml#/components/schemas/HalCollectionLinks"
_embedded:
type: "object"
properties:
kadastraalOnroerendeZaken:
type: "array"
items:
$ref: "#/components/schemas/KadastraalOnroerendeZaakHal"
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.
@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 stel voor om deze wijziging op de backlog te zetten (bij alle API's) en bij de eerste breaking change op content ook door te voeren.
@CathyDingemanse Hoe denk jij daar over ?
Als we dit gaan aanpassen dan zijn dat breaking changes. Gaan we die direct doorvoeren ?
Ik stel voor om deze wijziging op de backlog te zetten (bij alle API's) en bij de eerste breaking change op content ook door te voeren.
@CathyDingemanse Hoe denk jij daar o
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.
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.
Het is inderdaad niet wenselijk
Als we dit gaan aanpassen dan zijn dat breaking changes. Gaan we die direct doorvoeren ?
Ik stel voor om deze wijziging op de backlog te zetten (bij alle API's) en bij de eerste breaking change op content ook door te voeren.
@CathyDingemanse Hoe denk jij daar over ?
Ik denk dat het niet nodig is om dit asap door te voeren omdat de resolver dit al doet.
Als we dit gaan aanpassen dan zijn dat breaking changes. Gaan we die direct doorvoeren ?
@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 ?
@MelvLee zijn dit breaking changes? Er wijzigt toch niks in de interface, alleen in de onderliggende componentenstructuur?
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.
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 ?
@MelvLee zijn dit breaking changes? Er wijzigt toch niks in de interface, alleen in de onderliggende componentenstructuur?
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.
The text was updated successfully, but these errors were encountered: