In het kader van de vereenvoudiging van StUF het voorstel om het attribute noValue te laten vervallen. Dit attribute kan de volgende waarden bevatten:
- nietOndersteund
- nietGeautoriseerd
- geenWaarde
- waardeBestaat
- waardeOnbekend
- vastgesteldOnbekend
De twee belangrijkste waarden uit deze enumeratie, te weten "geenWaarde" en "waardeOnbekend", kunnen ook op een andere manier uitgedrukt worden:
- "geenWaarde" kan worden uitgedrukt door het element in kwestie leeg te laten. Bijvoorbeeld:
<voorvoegsel xsi:nil="true"/> - "waardeOnbekend" kan worden uitgedrukt door in het bericht het element weg te laten.
De overblijvende noValue-waarden
- nietOndersteund
- nietGeautoriseerd
- waardeBestaat
- vastgesteldOnbekend
worden nauwelijks of nooit gebruikt. Een (zeer) aangename bijkomstigheid van het afschaffen van noValue is het feit dat het nillable-probleem op een elegante manier kan worden opgelost, zie deze discussie:
Het afschaffen van StUF:noValue als oplossing voor het nillable probleem heeft nogal wat gevolgen:
Bij niet afschaffen van noValue heeft het alternatief met dummy waarden of (nieuw alternatief) het gebruik van de waarde/leeg choice constructie op elementen die niet de lege waarde kunnen bevatten mijn nadrukkelijke voorkeur. Deze afwijkende behandeling van een element is slechts nodig op een klein aantal elementen (ik denk minder dan 10% als we waar nodig aan enumeraties de lege waarde toevoegen).
De impact van afschaffen van noValue is volgens mij aanmerkelijk groter dan het waar nodig gebruiken van dummy waarden of de waarde/leeg choice, omdat dit slechts nodig is op een klein aantal elementen. Bij afschaffen van noValue is voor precies dezelfde elementen ook een bijzondere behandeling nodig: het zetten van xsi:nil="true" of het vullen van het leeg-element. Daarbovenop komt dan nog het implementeren van de hierboven besproken consequenties.
Een nog niet besproken alternatief voor het nillable probleem is om getallen in de schema's getallen te definiëren via regular expressions die ook een lege waarde toestaan. Theoretisch lijkt het me met regular expressions mogelijk om in elk element de lege waarde mogelijk te maken, terwijl de check op het zijn van een getal gewoon gehandhaafd blijft. Dit zou uitgezocht moeten worden door te kijken of alle simpleTypes in stuf0301, bg0310, zkn0310 en ztc0310 die geen string zijn, kunnen worden omgezet naar regular expressions die hetzelfde domein definiëren. Voor datums en tijdstippen hebben we dankzij GAB toch al een bijzondere constructie en daar gebruiken we het element leeg in plaats van noValue.
Als de andere leveranciers in meerderheid vinden dat bovenstaande argumenten niet deugen c.q. vinden dat het afschaffen van noValue een wenselijk vereenvoudiging is, dan zal ik hen volgen in het afschaffen van StUF:noValue en het meerwerk ten gevolge hiervan voor lief nemen.
Bedankt voor deze observaties Maarten. Ik begrijp je argumenten en het lijkt er zelfs op dat het afschaffen van noValue naast voor bestaande implementaties ook hinderlijk is voor nieuwe StUF-implementaties. M.a.w. het afschaffen van noValue is voor mij nu ook geen optie meer. Wel zouden we dit RFC kunnen herformuleren door niet noValue af te schaffen maar de volgende waarden in het waardenbereik van noValue af te schaffen:
Op die manier kunnen we de functionaliteit van StUF versimpelen zonder dat we tegen de nadelen aanlopen zoals Maarten in bovenstaande post heeft geschetst. Ik zelf ben trouwens geen grote voorstander van een dergelijke versimpeling omdat dit ook weer kan leiden tot allerlei migratieproblemen. Het ging mij uiteindelijk om het oplossen van het nillable-probleem. Maarten heeft nu aangetoond dat het afschaffen van noValue helaas niet de juiste weg is voor de oplossing van dit probleem.
Even een reactie van andere orde op deze voorstellen over het noValue attribute.
In het kader van GAB heeft KING net als een aantal andere partijen gebonden om zoveel mogelijk gemeenschappelijke afspraken te maken en deze afspraken dan ook te implementeren in de eigen standaard. Over het onderwerp noValue is een dergelijke GAB afspraak gemaakt.
Het lijkt mij dan ook logisch dat wij in StUF deze GAB afspraak volledig en onverkort overnemen. Dus deze discussie binnen StUF lijkt mij nu overbodig.
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0464.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Tijdens de StUF Expertgroep van 18 januari 2017 is besloten dat het noValue-attribute niet meer gebruikt wordt als de betekenis van de lege waarde "geenWaarde" is. Dus bijvoorbeeld <BG:voorvoegselGeslachtsnaam StUF:noValue="geenWaarde"/> wordt vervangen door <BG:voorvoegselGeslachtsnaam/>.
Tijdens de StUF Expertgroep van 15 februari 2017 is dit RFC afgevoerd.