Bug #487549
closedmapping van bestandsnaam op cmis:contentStreamFileName
0%
Description
Binnengekomen via discussieplatform:
Roel de Bruin:
De property cmis:contentStreamFileName is readonly. De mapping van de bestandsnaam zoals beschreven in paragraaf 5.3 kan dus niet werken. De CMIS implementaties die ik heb gezien vullen deze property met de cmis:name. Het resultaat is dat bij het opvragen van een document het attribuut 'bestandsnaam' van element 'inhoud' niet de oorspronkelijke waarde bevat maar die van de titel van het document.
Wellicht kan dit in versie 1.2 worden opgelost door de bestandsnaam als extra property zsdms:bestandsnaam toe te voegen aan het EDC object.
Updated by Michiel Verhoef over 8 years ago
Michiel Verhoef schreef:
In CMIS 1.1 is cmis:contentStreamFileName inderdaad readonly
cmis:contentStreamFileName File name of the content stream. See also section 2.1.4.1 Content Stream.
Property Type: String
Inherited: FALSE
Required: FALSE
Cardinality: single
Updatability: readonly
Choices: Not Applicable
Open Choice: Not Applicable
Queryable: <repository specific>
Orderable: <repository specific>
De Zaak- Documentservices vereisen echter CMIS 1.0 en daar is cmis:contentStreamFileName volgens mij niet readonly:
cmis:contentStreamFileName : File name of the Content Stream
Required: False
Inherited: False
Property Type: String
Cardinality: Single
MUST be set if the document has a content stream
Van andere properties wordt aangegeven dat deze read-only zijn, van deze niet. Ik ga er dus van uit dat dit geen read-only property is. Echter, om toch forwards compatible te blijven en CMIS 1.1 in de toekomst ook te kunnen ondersteunen is het wel verstandig hier een oplossing voor te verzinnen.
Wordt vervolgd ..
Roel de Bruin schreef:
Je hebt gelijk.
Interessant gegeven is dat dit probleem optrad in een CMIS 1.0 implementatie. Naar aanleiding van jouw constatering vond ik de link https://issues.alfresco.com/jira/browse/ALF-16697. Daarin staat dat men dit probleem niet als een bug onderkent omdat men de wijziging in 1.1 ziet als een verduidelijking van de specificaties van 1.0. Naar mijn idee een enigszins dubieuze constatering maar dit zou een extra reden kunnen zijn om het probleem in onze specificaties te omzeilen.
Updated by Michiel Verhoef over 8 years ago
- Status changed from Nieuw to Afgewezen
- Sprint/Milestone set to ZS-DMS 1.2.0
In http://docs.oasis-open.org/cmis/CMIS/v1.0/cd04/cmis-spec-v1.0.html (CMIS 1.0)
Paragraaf 4.3.4.7 cmisContentStreamType staat voor de property filename aangegegeven:
cmisContentStreamType wraps a content stream and additional information about the stream.
filename Filename of the content stream. For the primary content of a document it SHOULD match the value of the property cmis:contentStreamFileName.
In http://docs.oasis-open.org/cmis/CMIS/v1.1/CMIS-v1.1.html (CMIS 1.1)
paragraaf 4.3.4.7 cmisContentStreamType staat voor de property filename aangegeven:
cmisContentStreamType wraps a content stream and additional information about the stream.
filename Filename of the content stream. For the primary content of a document it SHOULD match the value of the property cmis:contentStreamFileName.
Hieruit leid ik af dat de cmis:contentStreamFileName wel degelijk gemapped moet worden op de bestandsnaam. De mapping van cmis:name op de bestandsnaam is dus niet correct. Ook is het mappen van de document-titel op cmis:contentStreamFileName niet correct.
De property filename komt ook weer terug in dit voorbeeld:
http://www.programcreek.com/java-api-examples/index.php?source_dir=xcmis-master/xcmis-wssoap/src/test/java/org/xcmis/wssoap/ObjectServiceTest.java
Op zich klinkt het aannemelijk dat cmis:contentStreamFileName een readonly attribuut is wat bij het aanmaken van de contentStream gezet wordt via de methode setFilename, zoals in dit voorbeeld (Java, afkomstig uit bovenstaand voorbeeld):
CmisContentStreamType contentStreamType = new CmisContentStreamType();
contentStreamType.setFilename("test");
contentStreamType.setMimeType("text/plain");
Dit zie je ook terug in
public class CmisContentStreamType extends Object
Java class for cmisContentStreamType complex type.
The following schema fragment specifies the expected content contained within this class.
<complexType name="cmisContentStreamType">
<complexContent>
<restriction base="{http://www.w3.org/2001/XMLSchema}anyType">
<sequence>
<element name="length" type="{http://www.w3.org/2001/XMLSchema}integer" minOccurs="0"/>
<element name="mimeType" type="{http://www.w3.org/2001/XMLSchema}string" minOccurs="0"/>
<element name="filename" type="{http://www.w3.org/2001/XMLSchema}string" minOccurs="0"/>
<element name="stream" type="{http://www.w3.org/2001/XMLSchema}base64Binary"/>
<any processContents='lax' namespace='##other' maxOccurs="unbounded" minOccurs="0"/>
</sequence>
<attGroup ref="{http://docs.oasis-open.org/ns/cmis/core/200908/}cmisUndefinedAttribute"/>
<anyAttribute processContents='lax' namespace='##other'/>
</restriction>
</complexContent>
</complexType>
Als ik alle voorbeeldn en beschrijvingen goed interpreteer wordt de bestandsnaam gezet middels de methode contentStreamType.setFilename((). Er wordt geen attribuut cmis:contentStreamFilename gezet. Dit lijkt me meer een functionele verwijzing naar contentStreamType.filename
Het vullen van cmis:contentStreamFileName met de waarde van cmis:name is niet correct. Zowel volgens de CMIS specificaties (zowel CMIS 1.0 als CMIS 1.1) als volgens de mapping behorende bij de Zaak- Documentservices. Ik weet niet om welke CMIS implementaties het gaat maar deze implementaties lijken mij niet te voldoen aan de CMIS standaard. En daarmee niet aan de eisen van het forum standaardisatie en de compliancy eisen van Zaak- Documentservices.
Voorlopig trek ik de conclusie dat de mapping van cmis:contentStreamFileName op de bestandsnaam correct is en dat deze gezet kan worden middels een methode (analoog aan) contentStreamType.setFilename().