(Dit verzoek is ingediend door gemeente Amsterdam en gemeente Den Haag)
Gevraagde wijziging:
Stel complexType definities beschikbaar die samengesteld zijn met attributen op basis van de originele simpleTypes, in plaats van met de simpleTypes die ge-extended zijn met <attributeGroup ref="StUF:element"/>. Met andere woorden, in ieder geval voor de Vrije Berichten, verwijder de verplichting om voor ieder element de attributen StUF:noValue en StUF:exact mee te nemen. Dat geeft ons beter bruikbare complexType definities met minder ballast.
De standaard staat toe om in vrije berichten restrictions te gebruiken van de standaard beschikbaar gestelde complexTypes voor een StUF-entiteit. Iedereen kan derhalve complexTypes definiëren waarin in de element definities het gebruik van de attributegroup StUF:element niet meer is toegestaan en waarin de elementen niet meer nillable zijn. Deze complexTypes kunnen vervolgens in vrije berichten worden gebruikt.
Is dit een oplossing voor jullie probleem of hebben jullie primair last bij het genereren van de webservices van de attributegroup StUF:element?
Het is wat mij een betreft een open vraag of bij het maken van een sectormodel ook altijd een complexType beschikbaar gesteld zou moeten worden met bovenstaande eigenschappen.
Zou/mag je op elementniveau ook verwijzen naar de gedefinieerde 'simpleTypes'? Die hebben immers nog geen attributen; die komen ps in '-e'-variant?
Dit mag uitsluitend als in het basis-type waar het betreffende element in voorkomt is verwezen naar het simpleType ipv het complexType voor de "-e" variant. Je moet gaan via de restriction op de '-e' variant om de schema's te laten valideren.
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0138.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Tijdens de StUF Expertgroep van 20-5-2015 is besloten dit RFC af te voeren.