Logo ontwikkelaarsportaal omgevingswet

DSO Plan-Plan validatie

Gebruik

U kunt een account aanvragen bij IPLO. U krijgt dan een persoonlijke landingspagina voor het gebruik van dit validatieportaal, met een gebruikersnaam en password.

Deze validatieservice is speciaal ontwikkeld voor de plan-plan keten. Deze service valideert alleen initiële omgevingsdocumenten tegen de pre-omgeving van het DSO. Het valideren van mutaties wordt NIET ondersteund.

Deze validatieservice wijzigt volgens een speciaal algoritme de id's van het omgevingsdocument. Zo ontstaan er geen conflicten met bestaande content in de pre-omgeving. In de validatierapporten worden de gewijzigde id's weer teruggerekend naar de oorspronkelijke id's.

De validatieservice verwerkt leveringen die geschikt zijn voor het aanbieden aan het LVBB koppelvlak. Daarnaast verwerkt de validatieservice ook uitwisselpakketten, zoals die gebruikt worden in de uitwisseling tussen plansoftware pakketten.

Uitleg

Inleiding

Het algoritme doet zo min mogelijk aannamen over de opbouw van de levering en de conformiteit aan de standaarden. We willen namelijk niet dat dit portaal alleen correcte en valide content valideert. Bijvoorbeeld, de standaarden ondersteunen momenteel maar 1 doel, maar ons omnummer algoritme ondersteunt meerdere doelen.

Uiteraard zijn er grenzen. Alle xml dient tenminste "well-formed" te zijn. We kunnen alleen een foutloze werking garanderen als de content schema-valide is. Bij ernstige schema fouten kan het gebeuren dat het omnummeren niet lukt.

Een uitwisselpakket wordt eerst omgebouwd tot een levering. Daarna wordt de levering gevalideerd.

Id's worden "omgenummerd'. Ze worden hierdoor niet gevalideerd op het LVBB-bronhouderkoppelvlak. In plaats daarvan valideren wij het deel van het oorspronkelijk Id dat door ons wordt omgenummerd. Doordat het LVBB-bronhouderkoppelvlak de rest van het oorspronkelijk id valideert is het resultaat toch een sluitende validatie.

Een levering dient te voldoen aan de limieten. Ook met betrekking tot de bestandsformaten. Als u toch een bestand opneemt dat niet aan de limieten voldoet krijgt u een afgewezen levering.

Stap 0 (optioneel): Ombouwen van een uitwisselpakket

Indien het aangeboden zipbestand een pakbon.xml bestand bevat wordt het beschouwd als een uitwisselpakket. Deze wordt omgebouwd tot een levering. Hiervoor is het belangrijk dat de het uitwisselpakket zich houdt aan alle vereisten die voor zulke pakketten gelden. Wanneer het uitwisselpakket niet voldoet aan deze vereisten wordt het niet omgebouwd tot een levering en ook niet verder gevalideerd.

Bij het ombouwen wordt een dummy besluit aangemaakt, ook als er een besluit is opgenomen in het uitwisselpakket. Daarnaast wordt er een willekeurig leveringsId gemaakt. Hieraan is de levering in uw geschiedenis herkenbaar.

Het ombouwproces ondersteunt niet het ombouwen van besluiten die tijdelijk regelingdelen instellen.

Stap 1: Controle limieten

De levering wordt uitgepakt. De bestanden worden gecontroleerd op de limieten voor omvang en extensies. Als ze hieraan voldoen volgt stap 2.

Stap 2: Omnummering volgens het omnummer algoritme

Het omnummer algoritme valt uiteen in 4 delen:

  • ow-ids van alle objecten die ontstaan in deze levering.

    • xpath expressie: //*:identificatie
    • voorbeeld: nl.imow-gm0363.regeltekst.<omnummeren>

  • doelen van de regeling:

    • xpath expressie: //*:doel
    • voorbeeld: /join/id/proces/gm0363/2021/<omnummeren>

  • akn-ids:

    • xpath expressie: //*:FRBRWork[starts-with(text(),'/akn/nl') and not (ancestor::*:isTijdelijkDeelVan)]

      • NB: uiteraard worden de FRBRExpression-id's afgeleid van deze FRBRWork id's ook omgenummerd.

    • voorbeeld: /akn/nl/act/gm0363/2021/<omnummeren>

  • join-ids:

    • xpath expressie: //*:FRBRWork[starts-with(text(),'/join/id')]

      • NB: uiteraard worden de FRBRExpression-id's afgeleid van deze FRBRWork id's ook omgenummerd.

    • voorbeeld: /join/id/regdata/gm0363/2021/<omnummeren>

De met <omnummeren> gemarkeerde delen worden omgenummerd naar een uniek id met de volgende opbouw:

  • start met: dsX
  • aangevuld met 29 karakters, willekeurig gekozen uit de karakters a t/m Z en de cijfers 0 t/m 9 .

Stap 3: Klaarzetten voor validatie

De levering wordt als volgt klaargezet voor de validatie:

  1. Alle bestanden uit de oorspronkelijke levering worden klaargezet voor de validatie.

  2. De om te nummeren bestanden worden omgenummerd. Dit gebeurt met behulp van tekstvervanging.

  3. Alle gml-bestanden genoemd in manifest.xml worden opnieuw gehashed, en de hash verwerkt in de GIO-xml.

  4. Een nieuwe opdracht.xml wordt in de levering gezet:

    • root element validatieOpdracht

    • idLevering met daarin:

      • een herkenbaar begin gelijk voor alle leveringen: PP__VALIDATIE
      • de accountnaam, voorafgegaan door __
      • een timestamp in het formaat "ddmmjjjjuummss", voorafgegaan door __ .

    • idAanleveraar : onze digikoppeling leverancier

    • Overige element conform de oorspronkelijke levering

Stap 4: Aanbieden voor validatie

Alle bestanden uit stap 3 worden gezipt en via onze digikoppeling aangeboden aan LVBB.

De omnummer tabel wordt bewaard om de validatierapporten terug te kunnen nummeren.

Validatieresultaten

Bij het ophalen van de validatieresultaten worden de validatiemeldingen met behulp van tekstvervanging teruggenummerd zodat de oorspronkelijke id's in het rapport worden getoond.

In het validatierapport wordt zowel de oorspronkelijke idLevering genoemd, als ook de idLevering die is gebruikt bij de validatie.