In "5.3 Mapping RGBZ-attributen met CMIS-properties" van "Standaard Zaak- en Documentservices 1.1" staan CMIS properties beschreven, met een kolom "CMIS-property-id". En in https://gemmaonline.nl/index.php/BIJLAGE-mapping-cmis-properties-rgbz... is die id overgenomen voor de query names. Het gaat dan bijvoorbeeld "zsdms:zaakidentificatie" maar ook om namen met een punt, zoals "zsdms:dct.omschrijving". Die punten zijn een probleem voor Alfresco.
Alfresco 5.1 accepteert geen punten in <property name="...">. Ik kan niet 1-2-3 vinden of dat inderdaad in de CMIS specificaties is beschreven. Maar voor query name wordt het in ieder geval wel duidelijk beschreven in de CMIS 1.0 specificatie, http://docs.oasis-open.org/cmis/CMIS/v1.0/os/cmis-spec-v1.0.pdf#page=15
id ID
This opaque attribute uniquely identifies the property in the repository. If two Object-Types each contain property definitions with the same ID, those property definitions are the same.
[...]
queryName String
All properties MUST supply a String queryName attribute which is used for query and filter operations on object-types. This is an opaque String with limitations. This string SHOULD NOT contain any characters that negatively interact with the BNF grammar.
The string MUST NOT contain:
- whitespace
- comma
- double quotes
- single quotes
- backslash "\"
- the period "." character or,
- the open "(" or close ")" parenthesis characters.
Het gaat dan om:
- zsdms:zkt.omschrijving (heet overigens "zsdms:Zaaktype-omschrijving" in de specificatie)
- zsdms:inp.bsn
- zsdms:anp.identificatie
- zsdms:inn.nnpld
- zsdms:ann.identificatie
- zsdms:dct.omschrijving
- zsdms:dct.categorie
Nog iets meer achtergrond:
Overigens klaagt Alfresco (nog?) niet over deze namen als er een XML modeldefinitie wordt geplaatst in Repository > Data Dictionary > Models. En na activeren van zo'n model kunnen deze namen dan ook daadwerkelijk via CMIS gebruikt worden. Maar de nieuwe Model Manager (Alfresco 5.1) en de API die daarvoor gebruikt wordt, keurt de punt wel af.
https://github.com/Alfresco/community-edition/blob/70f90384d2745fbc0c1d1...
public static final Pattern NAME_PATTERN = Pattern.compile("^[A-Za-z0-9_\\-]+$");
En hoewel Alfresco via Repository > Data Dictionary > Models dus wel toestaat om bijvoorbeeld zsdms:dct.omschrijving te definiëren, en dat ook teruggeeft in een "select *" query:
...kan het niet gebruikt worden in bijvoorbeeld "select zsdms:dct.omschrijving":
...geeft een foutmelding:
Overigens stelt de specificatie voor EDC cmis:name twee verschillende dingen. In "5.1 Zaken DMS boom":
...en in "5.3 Mapping RGBZ-attributen met CMIS-properties":
Alfresco verwacht in cmis:name een geldige bestandsnaam (en weigert bijvoorbeeld slashes of trailing whitespace).
Ik wil hier ook even op reageren gezien wij van Contezza er ook tegenaan zijn gelopen.
Het klopt wat je aanhaalt en dat dit voor problemen/verwarring zorgt binnen CMIS.
Binnen Alfresco kun je dit op 2 manieren aanpassen door:
SELECT * FROM zsdms:document WHERE zsdms:dct_x002e_omschrijving = 'omschrijving'
Alfresco maakt gebruik van de ISO 9075 Codering: http://docs.alfresco.com/5.1/references/API-JS-iso9075Encode.html
Echter kan intern Alfresco prima met een dergelijke notatie omgaan, echter is het niet de voorkeur om dit ook zo te doen.
Verder ben ik ook van mening dat dit niet netjes ontworpen is en voor veel verwarring zal zorgen.
Voor wat betreft de inhoud van cmis:name, zie ook: cmis.name mappen op bestandsnaam ipv Documenttitel.
Overigens werkt het gebruik van "_x002e_" voor zover ik ooit getest heb alleen in de queries; je kunt het niet gebruiken in de modellering in Alfresco. Dus namen zoals "zsdms:dct.omschrijving" zijn in Alfresco wel te gebruiken via Repository > Data Dictionary > Models maar niet via de Model Manager (Alfresco 5.1) en de API.
Hi Arjan,
Het is geen best-practise om Dynamic Models te gebruiken voor een kern model waarin grove wijzigingen plaats kunnen vinden. De Repository > Data Dictionary > Models is meer bedoelt om als functionele/technische beheerder even een klein model op te zetten. De Model Manager is pas in de 5.1. gelanceerd en kent nog wat kleine bugs, onderwater gebruikt de Model Manager ook de Dynamic Models.
Desalniettemin zijn we het gelukkig eens dat de notatie die door KING is gebruikt niet past in het DMS landschap. Hier is Alfresco niet uniek in, MS Sharepoint, IBM Filenet & overige loop je tegen hetzelfde probleem aan.
Bedankt voor deze waardevolle informatie, hier ga ik wel iets mee doen. Wat op dit moment echter de uitdaging is: de namen van elementen zoals dct.omschrijving zijn bepaald in StUF ZKN, het sectormodel waar het koppelvlak Zaak- Documentservices op gebaseerd is. De element namen zijn niet specifiek voor gebruik in het DMS landschap gemaakt maar applicatie onafhankelijk. Het kan dus voorkomen dat er element namen gebruikt worden die in bepaalde toepassingsgebieden niet goed werken.
Het toepassingsgebied 'DMS' maakt wel een heel groot deel uit van de ZS-DMS constructie, en is bovendien niet optioneel: CMIS vormt de verplichte verbinding naar de documentservices en moet dus goed werken. Betekent dit dat de StUF-ZKN er op aangepast gaat worden?
Het sectormodel StUF ZKN (dat is wat anders als de Zaak- Documentservices/ZDS) is niet specifiek voor het toepassingsgebied document management/DMS gemaakt.
Nu ik er zo nog eens naar kijk zijn in de Zaak- Documentservices soms elementen platgeslagen die in StUF ZKN in een hierarchische structuur zijn opgenomen. Aangezien er toch een fout opgelost gaat worden (zie ook https://vng-realisatie.github.io/StUF-Standaarden/discussie/gemma/koppelvlak-zs-dms/inc...) denk ik dat in de mapping vanuit de Zaak- Documentservices dit probleemopgelost moet gaan worden.
Hoe lossen leveranciers dit nu op? Is de underscore ("_") een goed alternatiief voor de punt (".")?
Hi Michiel,
In content modeling wereld binnen een DMS ook in naamgevingen is het eigenlijk not-done om punten te gebruiken binnen een naamgeving.
Inderdaad een underscore of nog beter UpperLowerCase combinatie zoals: zsdms:dctOmschrijving is het veiligst in een dergelijke situatie.
(Btw ik krijg mailingen van de forum allemaal in mijn spam)
Groet,
Tahir Malik
Aangezien er verschillende oplossingsrichtingen zijn is dit voor de komende teleconferentie op 17 november 2016 op de agenda gezet. Dan verneem ik graag hoe leveranciers eea. nu opgelost hebben en welke oplossing het beste aansluit bij de huidige implementaties. Dan kan een keus gemaakt worden om dit probleem op te lossen op een goede manier die de minste impact heeft voor de bestaande producten.
Mocht u niet in de gelegenheid zijn deel te nemen aan de teleconferentie maar heeft u wel inbreng over dit onderwerp, laat dit dan svp. aan mij weten.
Mocht u deel willen nemen aan deze teleconferentie maar nog geen deelnemer aan de werkgroep? Ook dan hoor ik het graag zodat u alsnog de uitnodiging en details kunt ontvangen. NB. de uitnodiging zal donderdag 10 november verstuurd worden.
In de Zaak- en Documentservice specificaties wordt alleen gesproken over de cmis:name. Een property kent echter verschillende namen zoals localName, displayName en queryName. In queries moet de queryName worden gebruikt en daar mag inderdaad geen punt in staan. Maar de Zaak- en Documentservice specificaties doen helemaal geen uitspraak over wat die queryName moet zijn. Dus wat dat betreft zijn de specificaties volgens mij niet in strijd met de CMIS standaard.
De juiste aanpak is wat ons betreft dat je eerst met een getTypeDefinition request opvraagt wat de queryName is van de property die je wilt opnemen in de query voordat je die query samenstelt.
In "BIJLAGE B-mapping-cmis-properties-rgbz-attributen.xlsx" staat wel een kolom met daarin de QueryName voor elk attribuut. Hier staan dan ook enkele niet-geldige namen zoals inp.bsn en anp.identificatie.
Tijdens de teleconferentie van dinsdag 22 november (dit was de verplaatste teleconferentie van donderdag 17 november) was de consensus dat de in de Zaak- Documentservices gespecificeerde naam gemapped wordt naar een geldende queryName welke dan vervolgens gebruikt wordt. Deze geldige queryName zou dan in de hierboven genoemde kolom van "BIJLAGE B-mapping-cmis-properties-rgbz-attributen.xlsx" gebruikt moeten worden.
Dit lijkt heel veel op wat Roel beschrijft en ik vind de oplossing via getTypeDefinition request een erg mooie omdat deze ook perfect past binnen de CMIS standaard. Een voorstel hiervoor zal ik (zoals afgesproken in de teleconferentie) uitwerken en voor de bijeenkomst van 14 december hier posten.
Overigens betekent bovenstaand voorstel dit ook een uitbreiding van de te ondersteunen CMIS operaties, nl. met de operatie getTypeDefinition (zie ook http://docs.oasis-open.org/cmis/CMIS/v1.0/cd04/cmis-spec-v1.0.html#_Toc243712546)
Ik had inderdaad de bijlage over het hoofd gezien.
Maar de operatie getTypeDefinition is al opgenomen in de lijst met verplicht te ondersteunen CMIS services in versie 1.2 van de specificities. Bovendien is deze in hoofdstuk 5.4 ook steeds opgenomen in de lijst met uit te voeren CMIS requests voordat een query wordt uitgevoerd. Dus volgens mij is dit al correct in de specificities verwerkt.