Request for comments: Extensible Enumeration 2.0

1. Inleiding

Per 12 februari 2020 is de Extensible Enumerations 2.0 specificatie met status “Recommendation” uitgebracht. Deze specificatie maakt het mogelijk enumeraties aan te maken die gebruik maken van hiërarchieën van domain members om enumeratie waardes te definiëren. Via deze Request for Comments stellen we een dergelijk mechanisme voor om toe te passen binnen SBR Nederland.

Effecten voor softwareleveranciers

De effecten voor softwareleveranciers dienen meegenomen te worden in de besluitvorming. Wij vragen dan ook met klem aan softwareleveranciers om te reageren.

Geef uw mening

Onderaan deze pagina vindt u de vragen waar we graag uw mening over horen. U kunt reageren tot 19 november 2021,17:00 uur.

2. Behandeling

In de werkgroep NT (over de NT architectuur) is het onderwerp meermaals besproken. Tevens is bekeken waar het fenomeen van nut is. De inhoud, de voordelen en de nadelen zijn uitvoerig besproken. Ook is er overleg geweest met Ruud van der Werf, zoals afgesproken in de EGG van maart 2021.

Ruud geeft aan dat hij:

• voor de multiselect functionaliteit een XMLSchema alternatief ziet (hoofdstuk 6)
• voor de hiërarchische enumeratie waardes (met of zonder (un)usable enumeratie waardes) een toegevoegde waarde ziet in EE2.0. Het voorbeeld van in welke landen actief met continenten indeling is een goed voorbeeld van de meerwaarde van EE2.0
• extensibility bij PE’s eigenlijk geen goede zaak vindt en dat zit hem in niet in EE2.0, maar in het gebruik van PE’s. Waarom zou je dit willen gebruiken? Bijvoorbeeld bij rechtsvormen er een nieuwe bijstoppen [als deze rechtsvorm niet in het wettelijk kader zit, dan hoef je het toch ook niet te rapporteren. Gewoon wachten op volgend jaar] of er eentje niet meer van toepassing vinden [dan rapporteer je hem toch niet; volgend jaar wordt deze dan uit de enumeratie gehaald]

3. Cases

Case A

In de AGT14 voor het entrypoint frc-rpt-agt-kerncijfers-pluimveehouderij wordt gevraagd of bij de pluimveehouderij 1 of meerdere types pluimveehouderij van toepassing zijn.

Extensible Enumeration 2.0 gaat ervoor zorgen dat er nog maar 1 concept is met multi-select optie.

Case B

In de toekomstige KYC Taxonomy wordt gevraagd in welke continenten/landen klanten actief zijn. EE2.0 geeft door middel van hiërarchische enumeratie waardes hiervoor een simpele en doeltreffende oplossing.

Case C

Klanten dienen bij banken in het kader van KYC aan te geven welke activiteiten zij verrichten in een bepaalde sector, bijvoorbeeld de seksbranche. De gewenste simpele en doeltreffende oplossing. Hiërarchische enumeratie waardes (online seksbranche; niet online seksbranche) en meerdere antwoorden mogelijk:

• Online seksbranche: webwinkels; televisie; webcam; chatten; telefonie; appen/SMS; Overige online activiteiten.
• Niet online seksbranche: erotische artikelen; seksbioscopen; bordelen; privéhuizen/raamprostitutie; parenclubs/stripclubs; escort met of zonder seksuele handelingen; massagesalons met seksuele handelingen.

EE2.0 geeft hierbij mogelijkheden die er nu niet zijn.

4. Voorgestelde oplossing

De werkgroep NT stelt voor om vanaf NT17 het fenomeen Extensible Enumeration 2.0 te introduceren en ziet daarbij geen noodzakelijkheid tot het definiëren van NTA regels als inperkingen of ter validatie. De specificatie is op zichzelf al compact. Uiteraard blijven de bestaande NTA regels van kracht op bijvoorbeeld de domain-member relaties waar de specificatie op leunt.

5. Technische uitwerkingen

Bekijk de informatie op Github-omgeving van het Centrum voor Standaarden.

6. XMLSchema alternatief voor multi-select

<xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema targetNamespace=http://www.example.com/enums xmlns:eg="http://www.example.com/enums" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:simpleType name="breeder-type-enum" >

<xs:restriction base="xs:string" >

<xs:enumeration value="layingHens" />

<xs:enumeration value="broilerHens" />

<xs:enumeration value="meatTurkeys" />

<xs:enumeration value="meatDucks" />

<xs:enumeration value="rearingHens" />

<xs:enumeration value="broilerBreeders" />

<xs:enumeration value="rearingBroilerBreeders" />

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="breeder-type-list-enum" >

<xs:list itemType="eg:breeder-type-enum" />

</xs:simpleType>

<xs:complexType name="breederListItemType">

<xs:simpleContent>

<xs:extension base="eg:breeder-type-list-enum">

</xs:extension>

</xs:simpleContent>

</xs:complexType>

<xs:element name="breederTypeList" type="eg:breederListItemType" />

</xs:schema>

En hier een simpel XML bestand met dit element:

<eg:breederTypeList xmlns:eg="http://www.example.com/enums">layingHens meatDucks rearingBroilerBreeders</eg:breederTypeList>

Ruud heeft dit getest en XSD validators controleren inderdaad of de waardes allemaal in de enumerations staan. Uiteraard moet dit in XBRL ingepast worden. Ter verduidelijking nog een kort schema waarin bijvoorbeeld een XBRL xoncept wordt gedefinieerd:

<xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema xmlns:xbrli=http://www.xbrl.org/2003/instance targetNamespace=http://www.example.com/enums xmlns:eg="http://www.example.com/enums" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:import namespace=http://www.xbrl.org/2003/instance schemaLocation="http://www.xbrl.org/2003/xbrl-instance-2003-12-31.xsd" />

<xs:simpleType name="breeder-type-enum" >

<xs:restriction base="xs:string" >

<xs:enumeration value="layingHens" />

<xs:enumeration value="broilerHens" />

<xs:enumeration value="meatTurkeys" />

<xs:enumeration value="meatDucks" />

<xs:enumeration value="rearingHens" />

<xs:enumeration value="broilerBreeders" />

<xs:enumeration value="rearingBroilerBreeders" />

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="breeder-type-list-enum" >

<xs:list itemType="eg:breeder-type-enum" />

</xs:simpleType>

<xs:complexType name="breederListItemType">

<xs:simpleContent>

<xs:extension base="eg:breeder-type-list-enum">

<xs:attributeGroup ref="xbrli:nonNumericItemAttrs" />

 

</xs:extension>

</xs:simpleContent>

</xs:complexType>

<xs:element name="breederTypeList" type="eg:breederListItemType" xbrli:periodType="duration" substitutionGroup="xbrli:item" />

</xs:schema>

7. Toelichting onderwerp

Bekijk de specificatie. 

Korte samenvatting Extensible Enumeration 2.0 specificatie

Per 12 februari 2020 is de Extensible Enumerations 2.0 specificatie met status “Recommendation” uitgebracht. Deze specificatie maakt het mogelijk enumeraties aan te maken die gebruik maken van hiërarchieën van domain members om enumeratie waardes te definiëren.

Hoewel het al mogelijk was om gebruik te maken van enumeratie concepten d.m.v. xs:enumeration (XML schema) was het niet mogelijk deze aan te passen in een extensie. Dit betekend dat het voor een partij niet mogelijk was de enumeratie te hergebruiken waarbij een aantal enumeratie waardes verwijderd en / of toegevoegd worden. Met de komst van Extensible Enumerations 2.0 is dit wél mogelijk. Bovendien brengt het nog meer voordelen met zich mee.

Voordelen Extensible Enumeration 2.0

Hier volgt een opsomming van eigenschappen van de extensible enumeration die als voordelen kunnen worden beschouwt.

Extensibility

Zoals genoemd maakt deze specificatie het mogelijk enumeraties aan te passen in een (preparer) extensie. Op dezelfde manier is het ook mogelijk onderscheid te maken in enumeratie waardes tussen verschillende entrypoints, zoals dat bijvoorbeeld ook gedaan wordt met presentatie relaties.

Hiërarchische enumeratie waardes

Met behulp van domain-member relaties kan een gelaagdheid worden opgebouwd in de set van enumeratie waardes. Zo kan bijvoorbeeld domain member Europa de parent zijn van de individuele landen. Hiermee kan een hiërarchie opgebouwd worden om de semantiek duidelijk te maken en / of voor presentatie doeleinden.

(Un)usable enumeratie waardes

Optioneel kan voor een domain-member relatie het attribuut “usable” op false gezet worden. Dit betekend dat domain members, oftewel de enumeratie waardes, niet gebruikt kunnen worden.

Neem wederom Europa als voorbeeld, dan is het wellicht wenselijk dat Europa zelf niet gekozen kan worden. Enkel de onderliggende individuele landen. Europa is dan toegevoegd ter aggregatie van de onderliggende enumeratie waardes.

Multi-select optie

Extensible Enumerations 2.0 bied twee verschillende types. Als men kiest voor enumerationItemType dan is het slechts toegestaan één enumeratie waarde te rapporteren. Een enumerationSetItemType staat toe dat meerdere enumeratie waardes gerapporteerd worden.

Meer in lijn met XBRL architectuur

Extensible enumerations 2.0 maakt gebruik van domain-member relaties. Deze relaties zijn geïntroduceerd in XBRL Dimensions en zullen dus welbekend zijn in de gemeenschap. Vanuit modellering gezien kan dit leiden tot voordelen. 

• Het zal mogelijk zijn bestaande domain-member relaties te hergebruiken als enumeratie. Dit voorkomt dubbele definities. 
• Vanuit technisch oogpunt kan het makkelijker zijn te werken met domain-member relaties. Een formula kan verwijzen naar de definieerde domain-member relaties en die gebruiken om tot een evaluatie te komen.

Obstakels / Benodigde inperkingen

De werkgroep NT ziet geen noodzakelijkheid tot het definiëren van NTA regels als inperkingen of ter validatie. De specificatie is op zichzelf al compact. Uiteraard blijven de bestaande NTA regels van kracht op bijvoorbeeld de domain-member relaties waar de specificatie op leunt.

Een nieuwe specificatie zal altijd impact hebben op software die dit moet gaan ondersteunen. Momenteel is het zo dat enkele partijen met generieke XBRL software een gecertificeerde oplossing hebben met betrekking tot Extensible Enumerations 2.0. Specifiek Fujitsu XWAND en Altova XMLSpy. Indien de Extensible Enumeration 2.0 toepassing gaat krijgen binnen de NT zal hier ook ondersteuning voor moeten komen binnen de NT specifieke software. Wegens de beperkte grootte van de specificatie, alsmede hergebruik van eerder gedefinieerde bouwblokken, is de verwachtte impact voor software ontwikkelaars beperkt.

8. Request for Comments

Graag zouden wij uw terugkoppeling ontvangen op de volgende vragen:

• Kunt u instemmen met het introduceren van Extensible Enumerations 2.0?
• Kunt u instemmen met het gebruik vanaf NT17?
• Kunt u instemmen dat er geen NTA regels worden aangepast of toegevoegd inzake Extensible Enumerations 2.0?

Indien u niet kunt instemmen:

• Kunt u dan aangeven welke bezwaren u tegen de voorgenomen oplossing heeft
• Kunt u dan aangeven of u (een) alternatieve oplossing(en) heeft

Indien uw terugkoppeling achterwege blijft, dan veronderstellen wij dat u in kunt stemmen met de voorgenomen besluiten.

Reageren voor 19 november

We verzoeken u om vóór 19 november 2021, 17:00 uur uw reactie(s) met toelichting te zenden aan sbr@logius.nl.