Request For Comments Folder structuur en releasemanagement

Transcriptie

1 Request For Comments Folder structuur en releasemanagement Inleiding Alle partijen deelnemend aan SBR hebben belang bij een visie en een daarop aansluitende releasekalender met voorgenomen wijzigingen in de taxonomie. Het SBR team faciliteert en coördineert de ontwikkeling van deze visie en is verantwoordelijk voor het opstellen van de releasekalender. De besluitvorming over de aanpassingen in de architectuur vindt in deelonderwerpen plaats. De uitkomst van dit proces leidt tot een uitgebreide beschrijving van de architectuur van de Nederlandse Taxonomie (NTA). De architectuur bevat de uitgangspunten, afbakeningen en inrichtingsprincipes welke een domeineigenaar dient te hanteren om aangesloten te kunnen zijn bij de Nederlandse Taxonomie (NT). Onderdeel van de besluitvorming over de architectuur is de marktconsultatie. Voor u ligt een verzoek tot commentaar (Engels: Request For Comments, RFC) welke deel uitmaakt van de marktconsultatie. Deze RFC behandelt de wijziging van de folderstructuur en het releasemanagement van de NT. Met behulp van deze RFC willen de SBR taxonomie bouwende partijen (Belastingdienst, CBS, Kamer van Koophandel en de in het Financiële Rapportages Coöperatief samenwerkende banken) van u weten hoe u aankijkt tegen voorgestelde wijzigingen in de folderstructuur en het releasemanagement van de NT. Welke gevolgen ziet u en welke visie heeft u over de (wijze van) invoering, indien wordt overgegaan tot invoering. Aanleiding Diverse (toekomstige) ontwikkelingen en wensen vanuit de markt zorgen voor de behoefte tot aanpassing van de bestaande folderstructuur en het releasemanagement van de NT. Deze ontwikkelingen en wensen worden hieronder puntsgewijs beschreven: Door het ondersteunen van nieuwe XBRL specificaties in de NT komen er meer linkbase bestanden, zoals table linkbases en formula linkbases. Deze kennen momenteel geen plek in de bestaande structuur. De verwachting is dat in de komende jaren verschillende uitvragende partijen zullen toetreden tot het SBR programma. De verantwoordingsrapportages van zowel nieuwe als bestaande uitvragende partijen kunnen andere releasemomenten kennen dan de huidige releasecyclus van de NT mogelijk maakt. Het is wenselijk om de releasecyclus van de NT flexibeler te maken, zodat uitvragende partijen op verschillende momenten een rapportage kunnen publiceren. Vanuit de markt is de wens geuit om het versienummer stabiel(er) te laten zijn in het jaar dat een NT uitgebracht wordt, ook als er uitbreidingen gedurende het jaar opgenomen worden. Omdat de folder structuur en het releasemanagement van de NT sterk samenhangen is besloten beide onderwerpen in één voorstel aan u voor te leggen. De huidige opzet van de folder structuur en het releasemanagement is geoptimaliseerd voor het releasen van de taxonomieën van een drietal partijen die min of meer dezelfde releasemomenten kenden. Deze opzet is in de afgelopen jaren al wat opgerekt door het uitbrengen van aanvullende extensies door de Belastingdienst. De verdere verbreding van SBR zorgt ervoor dat nieuwe uitvragende partijen, met andere releasemomenten, zullen toetreden tot de NT. Deze ontwikkeling kan de huidige opzet niet goed aan. Om de verdere verbreding van SBR te faciliteren en partijen niet te belemmeren bij het toetreden tot de NT, richt dit voorstel zich op een herziening van de folder structuur en het releasemanagement. De intentie van de SBR taxonomie bouwende partijen is om deze herziening vanaf de NT11 te laten ingaan.

2 Doelstelling Met behulp van deze RFC willen de SBR taxonomie bouwende partijen achterhalen welke visie marktpartijen hebben op de wijziging van de folder structuur en het releasemanagement van de NT. Daarnaast zijn de SBR taxonomie bouwende partijen geïnteresseerd in mogelijke obstakels en de gevolgen van bepaalde ontwerpbeslissingen. Ook voorstellen met betrekking tot de technische invoering zijn onderwerp van deze marktconsultatie. Achtergrond Op dit moment zijn de folderstructuur en het releasemanagement van de Nederlandse Taxonomie als volgt ingeregeld: Folder structuur De huidige folder structuur geeft als root het versienummer van de NT, bijvoorbeeld 9.0. Daarna volgt een opbouw die uitgaat van een woordenboek (de basis), de NT partner specifieke invulling (het domein) en de daadwerkelijke rapportage voor de markt (het report). Onder elk van deze folders zijn NT partners vertegenwoordigd die een serie van subfolders kunnen aanleggen. Deze folder structuur ziet er als volgt uit: Figuur 1 Huidige folder structuur Releasemanagement De taxonomie kent een releasecyclus waarbij de meerderheid van rapportages jaarlijks op 1 december als x.0 versie wordt gepubliceerd. Eventuele aanvullende rapportages worden in een

3 latere release als versie x.1, x.2, etc. uitgebracht. Deze aanvullende taxonomiereleases kennen een directe afhankelijkheid van de eerder uitgebrachte x.0 release en zijn niet zelfstandig bruikbaar. Het herstellen van onjuistheden in een taxonomie kan op twee manieren: via het uitbrengen van een nieuwe versie in lijn met de hierboven vermelde methode of via een zogenaamde quick fix. Een 'quick fix' oplossing wordt alleen gekozen indien het probleem (zeer) urgent is, alle NT partners het eens zijn over de aanpak, de oplossing in een enkel bestand van de taxonomie verwezenlijkt kan worden en er geen tijdsafhankelijke implementatie is. Bij deze oplossing is er geen ophoging van het versienummer van de NT. Het gerepareerde bestand wordt voorzien van een XML commentaar (tekst tussen tekens) waarin de datum en reparatie worden vermeld. De bovenstaande werkwijze is niet langer houdbaar wanneer rekening gehouden wordt met de eerder genoemde ontwikkelingen en wensen. Het voorstel Het voorstel voor de nieuwe folder structuur en het releasemanagement van de Nederlandse Taxonomie wordt hieronder uiteengezet: Folder structuur Het voorstel is om de root folder van de NT te baseren op de van toepassing zijnde NTA versie. Gedurende een periode wordt de NTA bevroren en dienen NT partners hun taxonomie in te richten volgens deze NTA regels. De verwachting is dat de NTA versie op termijn langer stabiel zal kunnen blijven dan de huidige jaarlijkse cyclus van de NT versienummering. Onder de root folder zullen de NT partners een eigen folder krijgen. Hierdoor kan een partij die slechts één rapportage ondersteunt al de benodigde XBRL onderdelen middels één stap achterhalen. Elke NT partner levert voorts folders op die het formaat van een datum hebben. Dit is de releasedatum van de bestanden die onder deze folder opgenomen zijn. Inhoudelijk kunnen bestanden verwijzen naar XBRL onderdelen OVER de datum folder heen (maar wel alleen binnen dezelfde NTA versie). Hierdoor zullen rapportages mogelijk zijn waarbij de inhoud (concepten) minder frequent dan jaarlijks zullen wijzigen. In elke releasedatum folder zal voorts een technische vaste indeling van folders bestaan waarbinnen elke NT partner zijn bestanden beschikbaar maakt, te weten: entrypoints, dictionary, presentation en validation. In de entrypoints folder zijn de verschillende entrypoints van de betreffende release opgenomen. In de dictionary folder zijn alle zaken opgenomen die zich richten op de definitie van begrippen: denk aan gegevenswoordenboeken, zoals de schema s voor concepten, tuples en members, maar ook gestructureerde semantische relaties tussen deze begrippen. In de presentation map staan alle linkbases (presentation linkbases en table linkbases) en schema s (presentation items) die zich volledig richten op het presenteren van gegevens. In de validation map staan alle zaken die zich richten op het valideren van gegevens in een instance document, zoals dimensionele linkbases en formula linkbases. Deze nieuwe indeling is ook hieronder opgenomen.

4 Figuur 2 Voorstel nieuwe indeling folder structuur In het oog springt direct de enorme afname van het aantal folders tussen de NT versies wat de beheerlast en de vindbaarheid van onderdelen positief beïnvloedt. Andere voordelen zijn de mogelijkheid om individuele entrypoints langer te laten bestaan dan één jaar en tussentijds correcties uit te voeren doordat een individuele partner een eigen releasemoment kan invoeren zonder dat alle partners ook hun bestanden uit moeten leveren. Met name bij NT partners die verschillende (wettelijke) rapportagemomenten kennen is dit van belang. Nieuwe specificaties als tabellen en formules zullen een duidelijke plaats verkrijgen in de nieuwe structuur. Releasemanagement Het versienummer geeft voortaan aan met welke NTA versie de NT gebouwd is. Dit komt tot uitdrukking in het nummer: nt11. De taxonomie wordt op deze wijze geplaatst op nltaxonomie.nl, maar daarnaast ook als.zip bestand op de SBR website gepubliceerd. Dit.zip bestand bevat altijd alle releases (tot het moment van uitlevering). Voor elke nieuwe release maakt een uitvragende partij een eigen datum folder aan, dit heeft geen consequenties voor het versienummer van de taxonomie meer. Wel heeft dit consequenties voor de naamgeving van het.zip bestand. Een nieuwe gepubliceerde versie van het.zip bestand kenmerkt zich door de opname van de datum van publicatie in de naamgeving van het bestand: nt11_[datum].zip. De taxonomie kent hierdoor een releasecyclus waarbij dus op elk moment nieuwe releases uitgebracht kunnen worden. Dit wordt zichtbaar door middel van de datum folder. Nieuwe releases worden uitgebracht in het geval van de publicatie van nieuwe rapportages of in het geval van grootschalige (semantische) herzieningen van bestaande rapportages, bijvoorbeeld door de publicatie van nieuwe wet- en regelgeving. Dit betekent dus ook dat de gehanteerde namespaces in deze rapportages zullen wijzigen. Bugfixes kennen een andere wijze van verwerking in de nieuwe opzet van het releasemanagement dan nieuwe releases. Voor bugfixes worden gecorrigeerde versies uitgebracht van bestaande rapportages. Deze bugfixes zullen ook leiden tot gecorrigeerde versies van bestaande schema s en/of linkbases. Deze bestanden worden opgenomen naast de oude versie van de schema s en/of linkbases die zij vervangen. Voorbeeld: In het geval van een onjuist datatype in het bestand bd-omzetbelasting.xsd met de namespace zal dus een gewijzigd bestand beschikbaar komen met de naam bd-omzetbelasting _v2.xsd met nog

5 steeds dezelfde namespace: de relevante linkbases en het entrypoint. omzetbelasting. Hetzelfde principe is van toepassing op Hierdoor veranderen dus de bestandnamen van de linkbases, schema s en het entrypoint. In het geval van bugfixes veranderen de namespaces echter niet. Deze nieuwe bestanden worden naast de oude bestanden geplaatst in de bestaande datum folder. Een voorbeeld hiervan is in de onderstaande figuur opgenomen. Hierbij is een nieuwe versie van het schema voor de omzetbelasting opgenomen middels het bestand bd-omzetbelasting_v2.xsd. Figuur 3 Voorstel nieuwe opzet bugfixing Op deze wijze zijn de wijzigingen igingen in de taxonomie altijd waarneembaar voor de betrokken partijen, terwijl de impact voor de softwareleveranciers beperkt is tot het hernoemen van een of enkele bestanden. Daarnaast kunnen meerdere versies van dezelfde entrypoints (voor een bepaalde tijd) naast elkaar kunnen bestaan, zodat de aanleveraars de tijd hebben om over te gaan. In het geval dat er een fout in de OB zit die alleen in een uitzonderlijk geval tot problemen leidt, kan een fixed versie ernaast gezet worden, zodat de partij met het uitzonderlijke probleem deze e fix kan gebruiken en de andere partijen de tijd krijgen om over te stappen. Om dit mogelijk te maken, zal de entrypointtabel die gepubliceerd wordt op de SBR website een belangrijkere rol gaan spelen dan momenteel het geval is. De entrypointtabel zal altijd actueel zijn en aangeven welke rapportages gebruikt kunnen worden om te rapportages in te sturen naar de betreffende uitvragende partijen. Op dit moment kennen de verschillende rapportages ook verschillende statussen: alfa, bèta en definitieve versies. Om duidelijk te maken welke versie hier speelt zal dit in de datumfolder worden aangegeven. Een alfa versie krijgt de extensie.a mee, een bèta versie de extensie.b en een definitieve versie krijgt geen extensie mee. Er wordt niet meer gewerkt met een extensie als a.1, a.2, etc. Deze nummering is vervangen door de datum. In het onderstaande voorbeeld wordt dit geïllustreerd: Voorbeeld: Een alfa versie : Een bèta versie : Een definitieve versie : /entrypoints/ b/entrypoints/... /entrypoints/... Samenvattend: Dit voorstel heeft enige impact op de huidige implementatie. Doordat de foldernamen altijd in de URI van de namespaces tot uitdrukking gebracht worden, zullen de waarden van de toekomstige namespaces veranderen. De entrypoints zullen op een andere plek in de folderstructuur staan, maar het discovery mechanisme van XBRL blijft ongewijzigd.

6 Op onderstaande vragen ontvangen de SBR taxonomie bouwende partijen graag een antwoord met een toelichting. Vragen 1) Heeft u bezwaren tegen de aanpassing van de folder structuur in de Nederlandse Taxonomie? 2) Heeft u bezwaren tegen de aanpassing van het releasemanagement in de Nederlandse Taxonomie? 3) Wat is uw visie op het tijdstip waarop de aangepaste folder structuur en releasemanagement zouden moeten worden ingevoerd? 4) Heeft u (aanvullende) opmerkingen betreffende de invoering van deze specificaties? Reacties U wordt verzocht uw reacties voor 31 oktober 2015 naar het adres sbr@logius.nl te sturen met in het onderwerp de tekst RFC Folders en releasemanagement. U kunt u reacties in.pdf,.txt,.odf of.docx formaat indienen. Alle reacties worden in.pdf formaat geplaatst op de webpagina s van SBR. Twee weken na de sluitingsdatum zal het SBR team de rapportages verwerkt hebben tot een standpunt met betrekking tot de invoer. Dit standpunt zal eveneens gepubliceerd worden op de webpagina van SBR.