cancel
Showing results for 
Search instead for 
Did you mean: 

Issues with REST-Atom Binding

peebles
Champ in-the-making
Champ in-the-making
Is there someone, or some group that would be interested in specific issues found in the REST/Atom implementation?  I am coding a perl client lib for CMIS REST/Atom binding and have encountered some issues.  Specifically:

1.  In type definitions returned by getTypes()
    1.  'typeId' element should be 'objectId' according to CMIS Part II, pg. 73 (schema)
    2.  However, in getTypes() service definition in pg. 23, reference is made to 'typeId'
        in optional arguments.
    3.  If typeId = 'document' is passed as argument, all types with baseType = 'document' are
        returned

2. In object properties (as returned in entry docs), BaseType is not described in CMIS Part I

3. In query results, ContentStreamUri is NULL.  It seems to take another fetch using 'self'
   link to get the complete information.  This fetch of self's entry document contains
   ContentStreamURI, not "ContentStreamUri" as expected.  There's a bug here somewhere.

4. in getChildren(), orderBy input seems to be ignored.

5. SELECT * FROM Folder WHERE Name = 'Company Home' (any folder query)

   org.alfresco.service.cmr.repository.TemplateException - Error during processing of the template 'Expression node.mimetype is undefined on line 212, column 18 in org/alfresco/cmis/atomentry.lib.atom.ftl.'. Please contact your system administrator.

6. getFolderParent() doesn't seem to work for Documents, as it uses cmis-folderparent, which is
   not a tag that documents seem to have.
   getObjectParents() doesn't work for Folders, as it uses cmis-parents.  Folders return
   cmis-parent (w/out the "s"), which is not defined in the standard.
1 REPLY 1

mrogers
Star Contributor
Star Contributor
These certainly look like issues that need looking at.

Please ensure that they are not already in JIRA and if not then raise them so they don't get lost.