De attribuutsoort Documenttype-omschrijving generiek binnen Document heeft als waardebereik een tamelijk lange enumeratie (een stuk of 100 items). De vraag is of deze enumeratie moet worden overgenomen in het schema. Het nadeel hiervan is dat elke wijziging in deze lijst met waarden ook leidt tot een functionele wijziging van het schema en daarmee tot een nieuwe namespace. Dergelijke wijzigingen kunnen dan ook slechts eens per jaar worden doorgevoerd.
Mijn advies is derhalve om deze enumeratie niet in het schema op te nemen. Gaarne jullie mening hierover.
... maar dan wel een tabelentiteit hiervoor op te nemen ?!?
Het gaat hier om een eerste aanzet tot documentsoortbenamingen. Discussies en onderzoeken hiernaar zijn gaande, dus de lijst zal nog veranderen en m.i. ook daarna aan verandering onderhevig zijn. Desondanks is het van belang dat er steeds meer en zoveel mogelijk gebruik gemaakt wordt van dezelfde documentsoortbenamingen. Vandaar de domeinwaarden in het RGBZ. In de praktijk moeten deze regelmatig en eenvoudig uitgebreid kunnen worden. Een frequentie van eens per jaar cf. StUF beantwoord niet aan het doel. Het niet opnemen van de domeinwaarden cq. enumeratie in StUF lijkt me ook geen geweldig alternatief. Dan gaat de standaardiserende werking van het gebruik van dezelfde documentsoortnamen verloren.
Of een tabel een oplossing is (zie reactie Rooijakkers), betwijfel ik. Het attribuut zit in een soort van tabel: DOCUMENTTYPE. Een extra tabel zou een 1:1-relatie hiermee krijgen. In het RGBZ niet echt charmant. Misschien wel voor StUF?
Wie zinvolle oplossingen ziet die beantwoorden aan het doel en in de dagelijkse praktijk uitvoerbaar zijn: graag!
Hallo Arjan,
Gegeven de door jou geformuleerde requirements is de beste oplossing om een tabelentiteit op te nemen in zkn0310. Deze tabelentiteit kan gebruikt worden om systemen te voorzien van de laatste waardenverzameling. Er is dan natuurlijk wel een instantie nodig die deze waardeverzameling onderhoudt en nieuwe versies publiceert.
Je hoeft in het RGBZ alleen de het entiteittype voor deze tabelentiteit te definiëren. Het is niet nodig om ook relaties naar dit entiteittype te leggen. Het volstaat om bij de attribuutsoort documenttype op te nemen, dat de geldige waarden vastleggen in de tabelentiteit hiervoor.
Met vriendelijke groet,
Maarten
Lijkt me een goede oplossing. Dat beheer van die tabel moet EGEM cq. KING ter harte nemen. Sluit m.i. goed aan bij de Zaaktypecatalogus.
Is het verstandig om dezelfde modellering te volgen voor enumeraties van Zaaktype-omschrijving-generiek en Rolomschrijving-generiek? Ook die zijn de komende jaren aan voortschrijdend inzicht onderhevig. Zo leidt bijvoorbeeld de vergelijking met het Omgevingsloket tot zaak- en roltypen die nu nog niet in het RGBZ staan.
Bij het Kadaster maken we gebruik van waardelijsten. Een waardelijst is een XML die los staat van de XSD, waar de waarden van een bepaald veld instaan. Er bestaat dan een CVA bestand die de juiste link legt tussen waardenlijst en veld in XSD. Naast de validatie van de XML obv de XSD kunnen de waarden gevuld in de XML los gevalideerd worden aan de hand van de waardelijst. Deze waardelijst is dynamisch. De waardelijsten worden gepubliceerd. Gebruikers/software leveranciers dienen dan regelmatig de meest recente versie op te halen.
Beste Brigit,
Is een StUF tabelentiteit niet de meest charmante implementatie van zo'n waardenlijst ?
Groeten, John.
Hoi John,
Ik heb geen kennis van StuF Tabelentiteiten. Misschien dat ook wel een oplossing is. Ik heb alleen aangegeven hoe je lijsten kunt onderhouden zonder dat het opgenomen is als enumeratie.
Groeten,
Brigit