Op het bg0310-forum is een onderhoudsverzoek ingediend voor het vervangen van 'fixed' waarden in attribute "entiteittype" door een enumeration van één waarde:
Dit voorstel zou gegeneraliseerd moeten worden voor alle attributes in plaats van alleen het attribute "entiteittype". Dit is een RFC op de StUF-onderlaag en de Best Practices. Mijn voorstel is om dit RFC door te voeren in stuf0302 en de huidige best practices zodat straks alle nieuwe standaarden (bg0320, zkn0320, ..., koppelvlakken) geen fixed-values meer gebruiken in de schema's.
Dit erratum is opgevoerd in de onderhoudsverzoeken als RFC0416.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Tijdens de StUF Expertgroep van 18 november 2015 is dit RFC goedgekeurd.
Het bovenstaande RFC geldt natuurlijk ook voor elementen of andere XSD-constructies waarin "fixed"-waarden worden gebruikt.
De best practice is aangepast zie deze reactie in de discussie 'Vervang gebruik 'fixed' waarde voor entiteitType attribute voor enumeration '.
Het vervangen van de fixed waarde op een attribute door een enumeratie met één waarde is alleen mogelijk voor attributes die niet als ref zijn opgenomen in het schema, omdat gerefde attributes niet gerestrict kunnen worden. Het is dus bijvoorbeeld niet mogelijk voor het attribute entiteittype.
Gelukkig is dit geen groot probleem, want codegeneratoren gaan volgens het SIG rapport niet optimaal om met fixed values (Ze controleren bij serialiseren en deserialiseren niet of de waarde van een fixed attribute correct is), maar ondersteunen verder het ermee werken wel. De waarde van een fixed attribute moet expliciet gezet worden door de programmeur en wordt niet automatisch gezet door de gegenereerde software.
Het is daarmee de vraag in hoeverre het doorvoeren van deze RFC nog zinnig is.
Tijdens de StUF Expertgroep van 16 november 2016 is besloten dit RFC af te wijzen.
We hebben in de StUF Expertgroep van de vorige week dit RFC volledig afgekeurd maar ik vraag me af of we daarmee niet voorbij gaan aan situaties waarin we het voorgestelde principe wel kunnen toepassen. Op attributes dus die lokaal gedefinieerd worden of kunnen worden.
Het is duidelijk dat het principe niet toegepast kan worden op het attribute 'entiteittype' aangezien we deze niet lokaal kunnen definiëren. We hebben in RFC0391 immers besloten dat we het attribute 'entiteittype' voortaan altijd laten voorafgaan door de namespaceprefix van de namespace waarin de bewuste entiteit gedefinieerd is. Dat kan alleen maar als we het attribute globaal definiëren.
De vraag is echter of de noodzaak om andere attributen globaal te definiëren er wel is.
De vraag is ook of het lokaal definiëren zoveel voordeel oplevert dat dit het nadeel dat we voor het definiëren van een vaste waarde op attributes niet consequent dezelfde methode gebruiken wegpoetst.
Wat de eerste vraag betreft, ja, in het verleden was het globaal definiëren handig om het beheer op de XML-Schema's in de hand te kunnen houden. In de nieuwe aanpak wordt er echter geen beheer meer gevoerd op de XML-Schema's maar op de UML modellen. De XML-schema's worden gegenereerd en het is dus geen probleem om de attributes waar dat mogelijk is lokaal te definiëren.
Wat de tweede vraag betreft, ondanks dat het voorkomen van het 'fixed' attribute voor het genereren van code geen al te groot probleem is zorgt het wel voor extra werk voor de programmeur. De waarde van een fixed attribute moet zoals Maarten enkele reacties geleden al uitlegt immers expliciet gezet worden door hen. Elk attribute waarop in het verleden een fixed attribute werd gedefinieerd maar dat in de toekomst lokaal gedefinieerd wordt met een enumeration van slechts 1 waarde scheelt de programmeurs tijd. Het is mij voor alleen niet duidelijk of dit een significante tijdwinst oplevert. Ik hoop dat anderen daar zicht op hebben.
Ik realiseerde me vandaag dat we in het kader van RFC0391 het 'entiteittype' attribuut niet meer gaan definiëren in de StUF namespace maar in de sectormodellen/koppelvlakken waarvan de entiteiten deel uitmaken. Dit om er voor te zorgen dat het attribuut 'entiteittype' de prefix krijgt van het sectormodel waarin de entiteit is gedefinieerd. Reden waarom het 'entiteittype' attribuut nog steeds globaal gedefinieerd moet worden.
Ik herinnerde mij echter dat je bij het lokaal definiëren van een attribuut aan kunt geven dat de namespace waarin dat attribuut is gedefinieerd opgegeven moet worden door op dat attribuut form="qualified" te definiëren. Ik heb dit uitgeprobeerd en dit werkt inderdaad. Ik heb het schema waarin ik dit heb uitgeprobeerd bijgevoegd samen met een test bestandje.
Dit zou dus een mogelijkheid zijn om toch van het fixed attribuut af te komen. De vraag is echter of we met deze constructie niet een ander probleem voor codegeneratie introduceren. Wellicht kan iemand dat uitproberen.
Bijlage
Voordat we hier verder tijd en moeite in investeren lijkt het me goed om na te gaan hoe code generatoren omgaan met attributes die als waarde een enumeration met één waarde hebben? Wordt hiervoor wel code gegenereerd die het zetten van de waarde door de programmeur overbodig maakt?
Tijdens de StUF Expertgroep van 18 januari 2017 is dit RFC wederom afgewezen. De meerwaarde van het gebruik van enumerations wordt als nihil ervaren.