Het attribute exact kan worden weggelaten bij simpleTypes voor datums en getallen (meer in het algemeen als via vanaf en totEnMet eenvoudig een range kan worden gedefinieerd) of voor simpleTypes gedefinieerd op basis van een enumeration. Goed om dit te beschrijven in de best practice voor het maken van sectormodellen. Het kan dus worden weggelaten binnen tijdvakGeldigheid en tijdvakRegistratie.
do, 14-02-2013 - 10.54u
#1
Weglaten van het attribuut 'stuf:exact' in datums en getallen
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0142.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Tijdens de StUF Expertgroep van 18 februari 2015 is gezegd dat je dit al in de sectormodellen kunt aanpassen. Het is een best practices issue.
Tijdens de StUF Expertgroep van 20-5-2015 is besloten dit RFC om te zetten naar een erratum (ERR0394).
Voorstel voor het oplossen van dit erratum (excl. de wijzigingen in de best practices).
Datum en Tijdstip complexTypes (zie 'Analyse Datum en Tijdstip ERR0394.xlsx')
Tijdens de analyse van het onderhoudsverzoek ERR0394 heb ik m.b.t. de Datum complexTypes (alleen 'StUF:Datum', 'StUF:DatumMetIndicator', 'StUF:Datum-e' en 'StUF:Datum-r' zijn aanwezig) het volgende geconstateerd:
Hiermee rekening houdend stel ik het volgende voor:
In feite hoeven er in het schema geen wijzigingen aangebracht te worden op deze elementen.
Ken dit complexType toe aan alle elementen waaraan nu de complexTypes 'StUF:DatumMetIndicator' en 'StUF:Datum-e' zijn toegekend.
De laatste natuurlijk met uitzondering van de elementen 'StUF:beginObject' en 'StUF:eindObject' die onderdeel uitmaken van de complexType 'StUF:TijdvakObjectZonderIndicator'.
Zie ook het tabblad 'Nieuwe situatie'.
Dit voorstel betekent dat in de schema's van de StUF onderlaag, StUF-BG 3.10, StUF-ZKN 3.10 en StUF-ZTC 3.10 van 1267 elementen het 'type' attribute gewijzigd moet worden (zie het tabblad 'Bepalen relevante elementen').
M.b.t. de Tijdstip complexType is de situatie eenvoudiger. Daarvoor is het voldoende om in het complexType 'StUF:Tijdstip-e' de attributeGroup 'StUF:element' te vervangen door het attribute 'StUF:noValue' waarmee het 'StUF:exact' attribute in alle tijdstip gerelateerde elementen is verwijderd (zie eveneens het tabblad 'Nieuwe situatie').
Enumeration complexTypes (zie 'Analyse enumeration ERR0394.xlsx')
Voor het bepalen van de enumeration complexTypes waarin een exact attribute voorkomt heb ik eerst een query gedraaid voor een lijst van simpleTypes en complexTypes die een xs:enumeration bevatten (het resultaat staat in het tabblad 'Types met enumerations').
Op basis van die lijst heb ik vervolgens een query gedraaid voor een lijst van simpleTypes en complexTypes die een extension zijn van de eerder verkregen complexTypes. Dit levert een lijst op van 75 complexTypes (zie tabblad 'Enum complexTypes met attrGrp') waarvan er 71 de attributeGroup 'StUF:element' gebruiken en dus een 'StUF:exact' attribute hebben.
Er zijn overigens geen complexTypes waarin direct een 'StUF:exact' attribute is gedefinieerd.
In de 71 verkregen complexTypes moet de attributeGroup 'StUF:element' vervangen worden door een 'StUF:noValue' attribute.
Tijdens mijn analyse zag ik dat er op het complexType 'TyperingSUB-e' in het schema 'bg0310_simpleTypes.xsd' helemaal geen attributen op waren gedefinieerd. Aangezien er op andere 'Typeringxxxxx-e' complexType wel attributen waren gedefinieerd, en daar straks in ieder geval het attribute 'StUF:noValue' is gedefinieerd, lijkt mij dat er op dit complexType nu ook het attribute 'StUF:noValue' gedefinieerd moet worden.
Of is er een goede reden dat dat op deze complexType niet van toepassing is?
Bijlage
Tijdens de StUF Expertgroep van 16-9-2015 is besloten het erratum toch weer om te zetten naar een RFC (RFC0394). De impact wordt toch als te groot ervaren.
Tijdens de StUF Expertgroep van 19 oktober 2016 is besloten dit RFC te laten vervallen.