Binnen CMIS geen / in zaakidentificatie

Issue:

• De Zaak-DMS services schrijft voor dat in de ZAKEN boom een zaak wordt geïdentificeerd aan de zaakidentificatie. Bijvoorbeeld /ZAKEN/ZAAKTYPE/Z-AFD-001 - In CMIS termen is de zaakidentificatie dan een pathSegment, namelijk een component voor het pad waarmee via getObjectByPath() een object kan worden opgehaald. - De CMIS spec stelt logischerwijs (regel 1087) dat een pathSegment geen / mag bevatten: /ZAKEN/ZAAKTYPE/Z/AFD/001 gaat natuurlijk hopeloos mis.
• Echter: de zaakidentificatie wordt bepaald door RGBZ die geen inhoudelijke restrictie stelt – een / in een zaakidentificatie is niet verboden. En komt bij Decos-klanten ook echt voor. 
• Er is geen escaping-mechanisme afgesproken binnen Zaak-DMS voor het voorkomen/corrigeren/weglaten van slashes.

Vraag:

• Wordt nu als feitelijke restrictie op de zaakidentificatie afgesproken dat er geen / in de zaakidentificatie mag voorkomen? En vormt Zaak-DMS dan dus feitelijk een restrictie op RGBZ? Welke andere leestekens zijn er dan nog die issues kunnen opleveren? Als de ZAKEN-boom direct in een filesysteem zou moeten kunnen voorkomen, mogen \/”*?:| ook niet.
• Als het free-form model van RGBZ voor zaakidentificaties blijft staan, zou Zaak-DMS Services in ieder geval moeten voorschrijven hoe er gecorrigeerd wordt voor niet-toegestane tekens.

Oplossingen:

• Geen free-form string maar een technische sleutel (GUID) gebruiken voor identificaties, zoals eerder voorgesteld door Decos. Dat lijkt mij de meest stabiele oplossing, maar is er ook 1 van de lange adem gezien de discussie daarover richting RGBZ.
• De CMIS repository zou intern iedere / moeten verwijderen uit getObjectByPath calls en uit de path-parameters die het teruggeeft bij folders. Dat is een paardenmiddel omdat je dan de CMIS-server moet aanpassen voor het toepassingsdomein. Bovendien hanteer je dan niet meer de zaakidentificatie voor de opbouw van de boom en dat schrijft de spec toch voor. Techneuten-fix, maar technisch volgens mij mogelijk.
• Geen slashes toestaan in de zaakidentificatie die het zaaksysteem genereert. Feitelijk dus toch stiekem een restrictie op RGBZ toepassen en verwerken in de sleutelservice van het zaaksysteem. En dan hopen dat er geen andere leestekens verboden zijn in andere protocollen.

Voorkeur:

• Decos heeft nog steeds voorkeur voor een onderscheid tussen machineleesbare identificaties (sleutel) en mens-leesbare kenmerken (free-form string). Voorkeur dus voor oplossing 1.
• Als dat in de nabije toekomst niet kan, stellen wij voor geen slashes toe te staan en dat ofwel functioneel af te spreken (zoals nu tussen Pink en Decos) ofwel af te dwingen in de sleutelgenerator. Oplossing 3 is dus tweede keus.