Met de attribuutsoort 'Taal' van het 'Enkelvoudig informatieobject' wordt vastgelegd in welke taal het informatieobject is opgesteld. Qua schrijfwijze en te hanteren waarden wordt aanbevolen RFC 3066 in samenhang met ISO 639 2/B te gebruiken.
In dit artikel lees ik dat RFC 5646 inmiddels RFC 3066 vervangen heeft.
Moeten we de toelichting op de attribuutsoort hierop aanpassen in RGBZ 2.0? Of nog verdergaand, moeten we de aanbeveling in RGBZ 2.0 omzetten in een voorschrift: RFC 5646 i.c.m. ISO 639 2/B bepalen de waardeverzameling voor deze attribuutsoort?
Ik houd er wel van om een vaste waardenlijst te gebruiken. Dus van mij mag de aanbeveling worden omgezet naar een verplicht waardenbereik. ik ga ervan uit dat de lijst uitputtend is.
Als dat een verplichting wordt in RGBZ 2.0, dan ontstaat er een probleem met de achterwaartse compatibiliteit. Dat zou betekenen dat StUF-ZKN 3.10 en daarvan afgeleide berichten niet meer kunnen worden ondersteund.
@Roel, zo zou je dus nooit meer wat kunnen aanpassen na de eerste versie van een informatiemodel en koppelvlak. Dat kan niet de bedoeling zijn. Hier zijn vast oplossingen voor. Heb je een voorstel?
Mogelijk biedt RFC 5646 daar zelf een oplossing voor. Ik ken die standaard niet dus daar kan ik niets over zeggen. Maar het feit dat in RGBZ 1.0 sprake is van een aanbeveling maakt het moeilijk om daar in 2.0 een verplichting van te maken zonder compatibiliteitsproblemen.
Ik draai het toch liever om. Voortschrijding in de tijd maakt soms dingen mogelijk die eerder niet mogelijk waren. We moeten niet schromen daarop in te spelen. Anders is er geen ontwikkeling meer, staat de tijd stil. Veranderen cq. verbeteren gaan we dus doen. De uitdaging is om een beheersbare oplossing te vinden voor eventuele problemen. Niet om vanwege potentiele problemen de doorontwikkeling stop te zetten.
Nogmaals, dit zal toch niet de eerste keer zijn dat zoiets plaats vindt. Ik ben benieuwd naar de oplossingen.
Roel, ik begrijp je reactie. Een conversietabel samenstellen is ongetwijfeld mogelijk, maar als het waardenbereik nu 'tekst' is kun je in de huidige registraties waarden tegenkomen die dan niet in die conversietabel staan. Aan de andere kant vermoed ik dat bij bijna 100% de waarde 'Nederlands' zal zijn. Je kunt vast iets bedenken in een conversieprocedure om (die enkele) onbekende waarden boven tafel te halen en handmatig om te zetten naar een nieuwe waarde.