Reguliere expressie voor kadastraleAanduiding is incorrect en onnodig complex

[KayodeBakker]

Beschrijf de bug Als aanvulling op de issue #875 open ik deze issue om aan te kaarten dat de reguliere expressie voor kadastraleAanduiding moet worden veranderd. Deze is nu als volgt: ^([a-zA-Z0-9'][a-zA-Z0-9' ,-]*[a-zA-Z0-9]) ([A-IK-Z]{1,2}) ([1-9][0-9]{0,4})(A[1-9][0-9]{0,3})?$ Er zijn meerdere zaken die hier niet kloppen en mocht iemand geïnteresseerd zijn om hier uitgebreid over te praten dan kan dit contact opnemen met mij, maar om to the point te blijven een aantal kleine voorbeelden:

1. In het eerste stuk van deze expressie worden er meerdere herhalingen gebruikt zodat we zo breed mogelijk een casus kunnen ondersteunen. Dit is begrijpelijk aangezien gemeenten hoofdletters, lage letters en tekens als ' en - kunnen bevatten. Echter zullen deze nooit getallen bevatten en er is een nettere notatie wijze hiervoor, namelijk \D* (ofwel alle niet getal karakters voor ongelimiteerde aantal keren).
2. Aanvullend op punt 1 is het daarmee ook onduidelijk waarom '[a-zA-Z0-9'][a-zA-Z0-9' ,-]' oneindig keer mag maar [a-zA-Z0-9] mag maar 1 keer.
3. Een sectie mag schijnbaar vermoedelijk geen letter J bevatten. Dit is apart, maar hier zal vast een regelgeving voor zijn binnen de BRK.
4. Het is optioneel om appartementsrechtVolgnummer toe te voegen, echter volgens de documentatie hoort hier een spatie te staan. Deze zit niet daadwerkelijk in de reguliere expressie en blokkeert nu sommige waarden.

Mijn voorstel zou zijn om het volgende te doen: ^(\D*) ([A-Z]{1,2}) ([1-9]{1}[0-9]{0,4})( A{1}[0-9]{1,4})?$

Met als reden de omschrijving van kadastraleAanduiding:

Kadastrale aanduiding is een unieke aanduiding van een onroerende zaak. De volgorde waarin deze string wordt opgebouwd is
          - [Kadastrale gemeente](http://www.kadaster.nl/schemas/waardelijsten/KadastraleGemeente/).
          - sectie, 1 of 2 hoofdletters
          - perceelnummer, 1 tot 5 cijfers
          - appartementsrechtVolgnummer, Hoofdletter A gevolgd door 1 tot 4 cijfers (optioneel)
          gescheiden door een spatie

• ^..$ verzorgt dat er een complete match moet plaatsvinden
• (\D) matcht de gemeente naam welke volgens 'http://www.kadaster.nl/schemas/waardelijsten/KadastraleGemeente/' nooit een cijfer kan bevatten en dus hoeft niet geen aandacht aan te worden besteed. Tevens hoef je niet complexe herhalingen te doen van karakters als \D omvatrijk is en de quantifier ervoor zorgt dat deze zo vaak als nodig wordt herhaald.
• ([A-Z]{1,2}) is voldoende voor sectie (mits er echt een harde regel bestaat dat letter J moet worden geweigerd. In dat geval is ([A-IK-Z]{1,2}) dan idd beter.
• ([1-9]{1}[0-9]{0,4}) wat hetzelfde is maar wel als extra safeguard dat er een quantifier gespecificeerd is voor [1-9] zodat je zeker weet dat het altijd alleen om de eerste gaat.
• ( A{1}[0-9]{1,4})? met een spatie binnen de match zodat de optionele zijde kan worden gehonoreerd maar de spatie daarmee ook optioneel is. Al deze matches hebben dan ook hardcoded een spatie er tussen zitten ook zoals gedicteerd is.

Als resultaat heb je een nettere reguliere expressie die compleet volgens specificaties functioneert.

Graag hoor ik hier meningen over.

[fsamwel]

@KayodeBakker de reguliere expressie is wel correct in kadastraal-onroerende-zaken.yaml: `"^([a-zA-Z0-9'][a-zA-Z0-9' ,-]*[a-zA-Z0-9]) ([A-IK-Z]{1,2}) ([1-9][0-9]{0,4})( A[1-9][0-9]{0,3})?$"

Kadastrale aanduiding "'s-Gravenhage N 8272 A3" voldoet aan deze reguliere expressie (volgens in https://regex101.com)

In genereervariant/openapi.yaml wordt deze over twee regels verdeeld, waarbij de spatie voor de A (van Appartementrechtvolgnummer) niet meer zo herkenbaar is:

          pattern: ^([a-zA-Z0-9'][a-zA-Z0-9' ,-]*[a-zA-Z0-9]) ([A-IK-Z]{1,2}) ([1-9][0-9]{0,4})(
            A[1-9][0-9]{0,3})?$

In de reguliere expressie die jij hierboven noemt is (wellicht daardoor) die spatie voor de A weggevallen.

[KayodeBakker]

Wellicht is dat het geval inderdaad, maar dat neemt niet weg dat de reguliere expressie naar mijn idee onnodig complex is. Ik ben bijv. wel benieuwd naar de redenatie waarom ([a-zA-Z0-9'][a-zA-Z0-9' ,-]*[a-zA-Z0-9]) en niet gewoon (\D*). De uitleg voor dat facet verklaart het iig niet.