Kleine gebieden en speciale codes zijn de plek waar een landendatamodel erachter komt hoeveel van zijn ontwerp een aanname was. De dataset werkt prachtig voor de grote, ondubbelzinnige, goed gedocumenteerde plekken, en dan komt er een afhankelijk gebied, een overzees departement of een gereserveerde code, en er moet iets wijken.
De waarde van deze gevallen is dat ze goedkoop toe te voegen zijn en ongewoon goed in het blootleggen van structurele problemen. Een model dat ze aankan, heeft meestal meerdere belangrijke beslissingen expliciet gemaakt.
Waarom breekt de aanname van de tweelettercode?
Omdat de codesystemen zijn ontworpen voor doelen die niet allemaal een tweelettercode voor elke plek vereisen. Het tweelettersysteem is het bekende, maar er is ook een drielettersysteem en een numeriek systeem, en elk bestaat om een ander probleem op te lossen. Het numerieke systeem ontstond met name om de dubbelzinnigheid van letters tussen talen te vermijden.
Onderverdelingscodering voegt nog een laag toe. Sommige plekken verschijnen alleen als onderverdelingen binnen een grotere entiteit in plaats van als zelfstandige entiteiten, en sommige verschijnen wel in het ene systeem maar niet in het andere. Een model dat de tweelettercode als de primaire sleutel van de wereld behandelt, heeft voor die plekken simpelweg geen plek.
De praktische consequentie is dat de primaire sleutel iets moet zijn dat je systeem beheert, niet een waarde die is geleend van een standaard met zijn eigen bereikbeslissingen. De standaardcode wordt dan een attribuut — belangrijk, doorzoekbaar, maar vervangbaar wanneer de situatie erom vraagt.
Wat moet er gebeuren met gereserveerde en afgeschafte codes?
Codes worden toegevoegd, gereserveerd voor toekomstig gebruik en ingetrokken. Ingetrokken codes verdwijnen niet uit de wereld; ze blijven in historische archieven, in gearchiveerde documenten en in oude databases, en ze blijven bij imports binnenkomen lang nadat de code is afgeschaft.
Een systeem moet beslissen wat het ermee doet. Ze ronduit afwijzen breekt het vermogen om de geschiedenis te lezen. Ze stilzwijgend als actueel accepteren verzint een feit over het heden. De werkbare middenweg is ze accepteren met een markering die zegt dat ze niet actueel zijn, en dat onderscheid zichtbaar houden overal waar de waarde wordt weergegeven.
Dezelfde logica geldt voor codes die werden gereserveerd voordat ze ooit werden gebruikt. Een gereserveerde code is geen fout; het is een gat in de nummering dat iemand bewust heeft gekozen, en een validatieregel die die als misvormd afwijst, heeft het mis over de standaard in plaats van over de invoer.
Voormalige namen en de namen die een plek voor zichzelf gebruikt
Namen veranderen, en de verandering is zelden overal gelijktijdig. Gedurende een periode is een nieuwe naam officieel terwijl de oude naam nog in de meeste documenten staat, en bij plaatsnamen verschillen de lokale vorm en de internationale vorm vaak.
Er moeten dus drie soorten namen worden onderscheiden. De huidige officiële naam, de naam die in oudere archieven voorkomt, en de naam die lokaal door de inwoners wordt gebruikt. Een systeem dat slechts één van de drie bewaart, zal in de ene of de andere richting fout zijn, en welke richting hangt af van wie leest.
Dit is een plek waar het opschonen van gegevens ze kan vernietigen. Een goedbedoelde normalisatieronde die elk historisch record naar de huidige naam herschrijft, laat het archief het met het heden eens worden en niet meer met zichzelf.
Niet van toepassing is niet hetzelfde als onbekend
Kleine gebieden maken dit onderscheid onmogelijk te negeren, want het zijn de gevallen waarin een veld werkelijk niet van toepassing is.
Een veld dat niet van toepassing is, betekent dat het begrip voor die plek niet bestaat, dus valt er niets op te zoeken en is er geen correcte waarde. Een veld dat onbekend is, betekent dat de waarde bestaat en nog niet is vastgesteld. Deze twee leveren dezelfde lege cel op en vereisen tegenovergestelde reacties, en een checklist die ze als één toestand vastlegt, blijft werk produceren dat niet kan worden afgerond.
Waar het veld een postcodesysteem is, is het verschil groot. De gids over postcodeformaten per land behandelt hoeveel het veld tussen plekken varieert. De situatie van elk land moet worden geclassificeerd voordat er enige validatie aan te pas komt, want een systeem dat aanneemt dat een veld bestaat, markeert elke vermelding zonder zo’n veld als onvolledig, en een systeem dat aanneemt dat het mogelijk niet bestaat, accepteert werkelijk slechte invoer.
Niet-ondersteund is niet hetzelfde als misvormd
Dit is het onderscheid dat het vaakst verloren gaat, en het is degene met de duidelijkste gebruikerskosten.
Een waarde die een systeem niet ondersteunt, is geen waarde die fout is. Ze kan volkomen goed gevormd zijn voor haar eigen plek, in een formaat dat het systeem eenvoudigweg nooit is geleerd te verwerken. Haar bij de gebruiker als ongeldig melden zegt hem dat hij een fout heeft gemaakt, terwijl de beperking in werkelijkheid aan de ontvangende kant ligt.
| Wat het systeem aantrof | Wat het weet | Wat het hoort te zeggen |
|---|---|---|
| Een waarde die de regels volgt die het implementeert | De waarde is geldig | Accepteer haar |
| Een waarde die regels volgt die het niet implementeert | De waarde is mogelijk geldig | Kan hier niet worden gecontroleerd |
| Een waarde die regels breekt die het wel implementeert | De waarde is ongeldig | Meld het specifieke probleem |
| Een veld dat voor deze plek niet bestaat | Er valt niets te controleren | Niet van toepassing, niet ontbrekend |
De middelste twee rijen samenvoegen is de gangbare fout. Ze levert een product op dat vol zelfvertrouwen fout is precies op de plekken waar zijn kennis het dunst is, en klanten uit die plekken merken dat het eerst.
Voor ontwikkelaars: maak de derde toestand uitdrukbaar
Een binaire uitkomst geldig of ongeldig kan “hier niet gecontroleerd” niet weergeven, dus heeft het validatieresultaat een derde waarde nodig die eerlijk doorwerkt naar de interface. Dat is een wijziging van een type in plaats van een wijziging van een regel, en daarom wordt ze onder tijdsdruk overgeslagen en later betreurd.
Test dan de grensgevallen met opzet. Neem een plek op waarvan de code slechts in één systeem voorkomt, een code die is afgeschaft, een plek zonder postcodesysteem, en een naam die is veranderd. Deze vier gevallen zijn klein, snel en ongewoon productief, en ze zijn het waard om permanent in de suite te blijven in plaats van te worden toegevoegd wanneer er een ticket binnenkomt.
De landen- en regiorgids is een redelijke plek om te zien hoe een land en zijn onderverdelingen worden weergegeven wanneer ze als een eersteklas vermelding worden behandeld in plaats van als uitzondering, en de vermelding voor de Verenigde Staten laat zien hoe een volledig gespecificeerde vermelding eruitziet naast een dunnere.
De gebieden, codes, namen en veldtoestanden in dit artikel zijn geconstrueerde grensgevallen die zijn samengesteld om een ontwerpprobleem te illustreren. Ze zijn geen dataset, ze vertegenwoordigen niet de werkelijke classificatie van enig gebied, en niets hier mag worden geciteerd als een feit over een specifieke plek.
Volgende stappen
Voeg de vier grensgevallen hierboven toe aan je suite en kijk welke van hen een verkeerd antwoord opleveren in plaats van een onafgehandeld exemplaar. De gids over landen kiezen voor testdata legt uit hoe je zulke gevallen bewust in een standaardset plaatst, en de gids over grensoverschrijdende adresscenario’s behandelt wat er gebeurt wanneer een plek als deze als een van meerdere landen in één transactie verschijnt.