IMKL-validatie

IMKL-testpagina

Ga naar de IMKL-testpagina.

Met deze tool kan een gebruiker IMKL-pakketten opladen en laten valideren. Bij het opladen doorloopt het pakket de IMKL-validatie. Bij een ongeldig IMKL-pakket krijgt u de fouten en waarschuwingen te zien. Indien één stap niet succesvol is, wordt de volgende stap niet uitgevoerd.

Is het IMKL-pakket geldig, dan kunt u het in de viewer bekijken overeenkomstig het PMKL, met het GRB als achtergrondkaart. Testpakketten staan los van een planaanvraag: er wordt niet nagekeken of de IMKL-data (deels) binnen een planaanvraagzone valt. De pakketten die u hier oplaadt, worden niet bijgehouden door KLIP.

De IMKL-testpagina is ook bereikbaar via de API IMKL-validatie.

Validatiestappen

1. Validatie van het zip-pakket

KLIP kijkt eerst na of het opgestuurde bestand een geldig zip-pakket is.

2. Validatie van de optionele digitale ondertekening (optioneel)

Een KLB kan indien gewenst het opgestuurde IMKL-bestand digitaal ondertekenen. Als er een digitale handtekening aanwezig is, wordt deze gevalideerd. Meer informatie over de digitale handtekening.

3. Validatie tegen het XSD-schema

Het XSD-schema (IMKL2.2-20141128.xsd) werd gegenereerd op basis van het IMKL-schema (zie inleiding). In het document met de extra regels kunt u ook zien welke elementen verplicht zijn (rode elementen). Sommige elementen moeten verplicht toegevoegd worden. Voor een aantal van deze elementen kunt u wel een NilReason opgeven (zoals beschreven in Extra regels document). Wanneer een NilReason wordt toegevoegd, moet ook het attribuut xsi:nil worden toegevoegd met waarde True.

Voorbeeld: <us-net-common:validFrom nilReason="unknown" xsi:nil="true" /> 

De mogelijke NilReasons zijn: inapplicable, missing, template, unknown of withheld.

4. Validatie van de extra regels

De extra validatieregels werden opgenomen in het document met de IMKL extra validatieregels (zie IMKL 2.3).

5. Validatie of er geen IMKL-Objecten zijn met identieke id’s

voor Inspire Us elementen:

<net:inspireId> <base:Identifier> <base:localId>001</base:localId> <base:namespace>interstroom-be</base:namespace> <base:versionId>v1</base:versionId> </base:Identifier> </net:inspireId>

voor IMKL-elementen:

<imkl:imklId> <base:Identifier> <base:localId>EP001<\base:localId> <base:namespace>interstroom-be</base:namespace> </base:Identifier> <\imkl:imklId>

VersionId is optioneel. Binnen eenzelfde pakket voor eenzelfde soort element (bijv. twee electricitycables) moet de combinatie van deze 3 elementen uniek zijn. De namespace is de identifier van de KLB-zone, hij moet via de GUI opgeven welke namespace hij gebruikt.

6. Validatie of alle referenties (in het href-attribuut) verwijzen naar een bestaand IMKL-object

7. Validatie van afhankelijkheden tussen IMKL-objecten

Validatie van cross-referenties

Voorbeeld: als een appurtenance verwijst naar een diepte-object, dan moet dat diepte-object ook verwijzen naar die appurtenance

Validatie van de types van appurtenances

Voorbeeld: in een netwerk van het type water mogen enkel appurtenances van het type water zitten.

De validatie is incrementeel, dat betekent dat stap 5 niet uitgevoerd zal worden wanneer 1 tot 4 niet succesvol waren. Ook de regels in stap 2 zijn incrementeel. Als er bijvoorbeeld een href-attribuut ontbreekt, zal er ook niet gevalideerd kunnen worden of de syntax van de URI correct is.

Opvragen validatieboodschappen

De gebruiker krijgt alle gevonden validatiefouten en waarschuwingen te zien.

Opgelet! Dit zijn niet noodzakelijk alle validatiefouten in het IMKL-pakket. Wanneer het pakket bijvoorbeeld een schemafout (controlestap 1) en een verkeerde referentie (controlestap 4) bevat, zal de gebruiker enkel de schemafout zien. De tweede fout werd nog niet ontdekt omdat de validatie na stap 1 gestopt is.