Het RGBZ kent meerdere tekstvelden, zoals 'Toelichting Zaak' en 'Toelichting Rol'. Deze hebben veelal het formaat AN1000. De vraag is of zo'n lengtebeperking terecht is en wat er allemaal ingevuld mag worden.
Is het niet voor de hand liggender, zeker gezien de ontwikkeling van zaakservices o.b.v. REST/JASON, om als formaat 'text' te specificeren (of AN)? Of moet het markdown of html (door een WYSIWYG editor bijvoorbeeld) zijn?
En wat mag er ingevuld worden? Alleen platte tekst of ook alinea-einden of zelfs vet en cursief en plaatjes en...?
Wat zijn de ideeen en voorkeuren hierbij en waarom?
Zo'n lengtebeperking is een gevolg van een technische beperking. In die zin is die beperking niet terecht en hoort die ook niet in een conceptueel model van het RGBZ. De vraag is wat je functioneel als toelichting kwijt wilt kunnen. Ik kan nu wel gaan gissen, maar ik weet niet wat 'men' kwijt wil. Maar als je het mij vraagt zou ik zeggen tekst, als weerslag van wat je zou willen zeggen over die Zaak, Rol etc. De opmaak is dan niet belangrijk.
@Rindert - ik ben van mening dat de opmaak net wel belangrijk is, zeker als je wil standardiseren. Als een leverancier HTML opslaat, en een andere werkt met markdown, dan betekent dit dat, ondanks de openapi specificatie (of WSDL zelfs), deze 'compatibel' zouden zijn met elkaar, en dat zijn ze niet. Want - de markdown leverancier kan de HTML niet als markdown interpreteren en weergeven.
Als je dus data bij de bron gaat opslaan (in beheer van de gemeente bijvoorbeeld), dan kan de ene taakapplicatie wel de toelichtingen correct weergeven, en de andere mogelijk niet. Je zit hier dan weer met een gebrek aan uitwisselbaarheid/standaardisatie.
@Sergei: Wat je benoemt zijn allemaal technische eisen en er zal ongetwijfeld een keuze gemaakt moeten worden. Ik refereer in mijn eerste reactie aan de positie van het RGBZ. Dit is een conceptueel model (of dat zou het moeten zijn). In het conceptuele model geef je weer wat je wilt kunnen communiceren. In de taal van de gebruiker. Dat je bij het registreren HTML toepast of markdown is voor de gebruiker niet interessant. Hij begrijpt dat niet en hoeft dat ook niet te begrijpen. Dat je dat technisch wel degelijk moet specificeren spreekt voor zich. Maar zoals ik al zei, dat valt buiten de scope van het RGBZ als conceptueel model. Je hebt dus naast (of na) een conceptueel model ook een (logisch en) technisch model nodig waar je de technische specs in definieert..
De vraag is dan wie wel deze beslissing maakt?
Dat is een goeie vraag Sergei. Iets voor VNG-realisatie om over na te denken.
Als patroon staat er nu in het RGBZ bij deze attribuutsoort "alle alfanumerieke tekens". M.i. houdt dit in 'platte tekst' dus geen opmaak in welk formaat dan ook. Gezien de aard van de inhoud van een toelichting, "tekst, als weerslag van wat je zou willen zeggen" zoals Rindert het verwoord, stel ik voor het te beperken tot alle tekens die op een voor Nederland bedoeld toetsenbord voor komen ('Engels (Verenigde Staten)"). Dus inclusief de alinea-einde-markering.
Wat ik niet weet is of dit te specificeren is met een deelverzameling van UTF-8.
Zolang er geen goede argumenten komen die een andere oplossing bepleiten, dan gaan we het zo doen.
Je zou een conceptueel model ook kunnen toepassen in een wereld zonder ICT (hoezo "alinea-einde-markering"). Ik zie het er helaas niet van komen dat we zuivere conceptuele modellen maken en ik ben bang dat het alleen maar erger wordt.
Daarom ga ik mee met het voorstel van Arjan.