CMIS needs to support aspects

[jpotts]

Currently (CMIS 1.0cd04), you can query for properties defined in an aspect, which is good. But full support for aspects is going to be critical for Alfresco-based CMIS implementations. Without it, CMIS clients cannot discover properties defined in aspects by interrogating getType, which I would think would be a big problem. Additionally, relationships defined as part of an aspect are completely invisible to CMIS which means CRUD functions on such relationships are completely unavailable.

What is the proper forum for getting feedback to OASIS that some form of aspects need to be supported, at least as an optional capability? I mean, if something so crucial to a repository such as the ability to support queries can be treated as an optional capability, which seems unbelievable to me, surely aspects can merit the same designation?

I hope this is something that can get in before final approval. I don't want to see Alfresco add a proprietary extension to CMIS to support aspects. With aspects being used so prevalently, it will seriously hamper interoperability and our ability to create truly agnostic CMIS clients if the spec is not changed.

Jeff

[dennisnk]

If you want to be sure OASIS receives the feedback, submit a comment to the TC comment list: http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=cmis. The public review should be ongoing until December 22.

Dennis

[darryl_staflund]

Hi there,

My colleagues and I at work have been discussing this issue and it seems at the very least as though discussions are taking place on the support of aspects in CMIS.  Take a look at the following link:

    http://wiki.oasis-open.org/cmis/Mixin_Proposal

Important is the section that summarizes John Newton and David Caruana's discussions on possible CMIS mixin implementations:

1.  Pool of Properties
———————-
In this proposal, a mixin would be implemented as a list of properties associated with an object but not its type.  It's easy to implement, it maps to Sharepoint, and can map existing Aspects to optional properties.  However, these properties don't have any specific structure so aspects would be hard to detect.  As such, it would have limited use beyond a few aspects.

2.  Separate Object (Different Id?) Connected with Association
————————————————————–
In this proposal, a mixin would be modeled as a separate object with a different Id (?) that is connected to a base type with an association.  This would work well with existing models, and would not require an extension to the CMIS query language.  However, the queries used to join objects with aspects would be complex requiring a full join (hence performance would suffer), and constraints would be needed to avoid linking an aspect instance to more than one object at a time.  Filters would also be needed on Type discovery to separate them from core types.

3.  Aspects as Children of Objects
———————————-
In this proposal, aspects would be modeled as children, similar to items in a folder.  Patterns used to add and remove items to and from folders could be adopted to work with aspects, and no major changes to the CMIS content model would be needed.  However, queries could become quite complex, Id handling could be messy, and a new folder-like hierarchy would be introduced into the system.

4.  New Type with No Separate Id with Implicit Association
———————————————————-
In this proposal, aspects would be implemented as objects without IDs having foreign key relationships with the IDs of the objects that they depend on.  In this model, queries are simple, the model is simple, and properties are handled well.  However, a new Aspect type would need to be added to CMIS and ECM's that don't support aspects would need to find some way of supporting it.

My personal hope is that (4) is incorporated into the CMIS standard – but as an optional extension instead of a mandatory requirement.  Seems to me like this would be the best of both worlds.  We'll have to see what happens.

Darryl

[kbryd]

Does anyone know how to access attributes defined in aspects in current Alfresco version (3.2r2)? There is that query on some Wiki page but it does not work unfortunately (joins are not supported) and while I agree that full aspects support is not trivial to implement there are some aspects for which it would be nice to have at least read only access (cm:titled for example or any other custom aspect).

I was even thinking about branching CMIS code from Alfresco and implement the 1) option from above list so at least I could have access to aspects from my application now and not in 2011 🙂

Jeff, could you shed some light on that issue?

Thanks!
Karol

[darryl_staflund]

The Wiki page in question is:

    http://wiki.alfresco.com/wiki/CMIS

where a join example is provided in the 'Query Language' section.

However, on the following Wiki page:

    http://wiki.alfresco.com/wiki/Full_Text_Search_Query_Syntax

it appears as though aspect properties can be accessed by attaching the 'aspect:' prefix to an Alfresco FTS expression embedded inside of the CMIS 'contains()' predicate.  I might be wrong on this last point though, for where the following row entry is found:

Description:  ASPECT
Type:  Special
Example:  ASPECT:"qname"
FTS:  Yes
CMIS contains():  No

I am not sure if 'No' in the 'CMIS contains()' columns means that this particular FTS expression won't work in the CMIS 'contains()' prefix, or whether the CMIS 'contains()' prefix doesn't offer similar native CMIS functionality.  I am guessing the former, but I haven't sat down to give it a try yet.
Darryl

[kbryd]

Problem with queries and CMIS is that by default joins are not supported. In the CMISQueryServiceImpl class there is following code fragment:

        public CMISJoinEnum getJoinSupport()
        {
            return CMISJoinEnum.NO_JOIN_SUPPORT;
        }

=============

        CMISJoinEnum joinSupport = getJoinSupport();
        if(options.getQueryMode() == CMISQueryOptions.CMISQueryMode.CMS_WITH_ALFRESCO_EXTENSIONS)
        {
            joinSupport = CMISJoinEnum.INNER_JOIN_SUPPORT;
        }‍‍‍‍‍‍‍‍‍‍‍‍‍

So, to enable joins you have to pass CMISQueryOptions.CMISQueryMode.CMS_WITH_ALFRESCO_EXTENSIONS to the method, BUT, there is no way to do it from the CMIS client 😞
What's worse there is no way to enable it from Spring configuration files, the only way to do it is by changing the class and recompiling it. I will try it tomorrow.

Karol

[kbryd]

Small update. I have enabled joins in HEAD and recompiled it but unfortunately queries like:

SELECT D.*, O.* FROM CMIS:DOCUMENT AS D JOIN CM:OWNABLE AS O ON D.cmis:objectId = O.cmis:objectId‍

return 0 rows…So it looks like this is not the right path. At least with that Alfresco version.

So, instead I have modified remote api module and implemented 1) option from the list above and it seems that it works. I have modified getProperties() in ObjectServicePort so it adds one more 'internal' property named
cmis:attached_aspects which contains  IDs of those aspects (like cm:titled, cmwnable etc.), getProperties() also  retrieves properties from those aspects and adds them to the properties list which is returned to the client.

From the client perspective I can query for aspect details because they are present in the dictionary as Policy objects. Property updates are also working correctly.

Even though this is a hacky solution it seems to work and until a real solution is implemented can be used without any major problems (I hope so 🙂

[a_evagelopoulos]

Hello.
I use Alfresco 3.3 Community and i am facing that problem(CMIS getTypeDefinition service doesn't work for custom aspects). i call the following cmis service 'http://localhost:8080/alfresco/service/cmis/type/D:myContentType'
First of all that works fine in Alfresco 3.0 labs and when i call the service 'http://localhost:8080/alfresco/service/api/type/D/myContentType' i do get my custom aspects. I can't understand why something that works in draft edition doesn't work in final release?
1. Is there any other way to get my custom aspects for my custom content-type in the Alfresco 3.3 Community edition?
2. Is this "problem" solved in 3.3 Enterprise edition?
3. Is there any way to get the typedefinition right from the PHP SDK?


Below i send you the xml code of my custom model

<?xml version="1.0" encoding="UTF-8"?>
<!– Definition of new Model –>
<model name="exaeAnakoinoseis:exaeAnakoinoseismodel" xmlns="http://www.alfresco.org/model/dictionary/1.0">

   <!– Optional meta-data about the model –>
   <description>Exae Anakoinoseis Model</description>
   <author>Stolis</author>
   <version>1.0</version>

   <!– Imports are required to allow references to definitions in other models –>
   <imports>
      <!– Import Alfresco Dictionary Definitions –>
      <import uri="http://www.alfresco.org/model/dictionary/1.0" prefix="d" />
      <!– Import Alfresco Content Domain Model Definitions –>
      <import uri="http://www.alfresco.org/model/content/1.0" prefix="cm" />
      <import uri="http://www.alfresco.org/model/system/1.0" prefix="sys" />
   </imports>

   <!– Introduction of new namespaces defined by this model –>
   <namespaces>
      <namespace uri="http://www.exae.gr/ermhs2/modelAnakoinoseis/content/1.0" prefix="exaeAnakoinoseis" />
   </namespaces>
   
   <constraints>
      <constraint name="exaeAnakoinoseis:agora-eisagoghs-list" type="LIST">
         <parameter name="allowedValues">
            <list>
               <value>Χ.Α.</value>
               <value>ΕΝ.Α</value>
            </list>
         </parameter>
      </constraint>
   </constraints>
   
   <!– TYPES –>
   
   <types>
      <!– Enterprise-wide generic document type –>
      <type name="exaeAnakoinoseis:doc">
         <parent>cm:content</parent>
         
         <associations>
               <child-association name="exaeAnakoinoseis:attachment">
                  <title>attachment</title>
                  <source>
                     <mandatory>true</mandatory>
                     <many>false</many>
                  </source>
                  <target>
                     <class>exaeAnakoinoseis:doc</class>
                     <mandatory>false</mandatory>
                     <many>true</many>
                  </target>
                  <duplicate>false</duplicate>
               </child-association>
            </associations>
            
      </type>      
      
      <type name="exaeAnakoinoseis:k1-03-001">
         <title>Ανακοινωση για εισαγωγή Μετόχων στο Χ.Α/ΕΝ.Α για πρώτη φορά με δημόσια Προσφορά</title>
         <parent>exaeAnakoinoseis:doc</parent>
         <mandatory-aspects>
            <aspect>exaeAnakoinoseis:hmnia-eisagogis-metoxon-aspect</aspect>
            <aspect>exaeAnakoinoseis:arithmos-metoxon-aspect</aspect>
            <aspect>exaeAnakoinoseis:kodikos-metoxhs-oasis-aspect</aspect>
            <aspect>exaeAnakoinoseis:kodikos-isin-aspect</aspect>
            <aspect>exaeAnakoinoseis:drasthriothta-aspect</aspect>
         </mandatory-aspects>
      </type>   
      <type name="exaeAnakoinoseis:k1-03-003">
         <title>Ανακοινωση για εισαγωγή Μετόχων στο Χ.Α/ΕΝ.Α για πρώτη φορά χωρίς δημόσια Προσφορά</title>
         <parent>exaeAnakoinoseis:doc</parent>
         <mandatory-aspects>
            <aspect>exaeAnakoinoseis:hmnia-eisagogis-metoxon-aspect</aspect>
            <aspect>exaeAnakoinoseis:arithmos-metoxon-aspect</aspect>
            <aspect>exaeAnakoinoseis:kodikos-metoxhs-oasis-aspect</aspect>
            <aspect>exaeAnakoinoseis:kodikos-isin-aspect</aspect>
            <aspect>exaeAnakoinoseis:drasthriothta-aspect</aspect>
         </mandatory-aspects>
      </type>      
   </types>
   
   
   <!– ASPECTS –>
   
   <aspects>
      <aspect name="exaeAnakoinoseis:hmnia-eisagogis-metoxon-aspect">
         <title></title>
         <properties>
            <property name="exaeAnakoinoseis:agora-eisagoghs">
               <type>d:text</type>
               <multiple>true</multiple>
               <constraints>
                  <constraint ref="exaeAnakoinoseis:agora-eisagoghs-list"></constraint>
               </constraints>
            </property>
            <property name="exaeAnakoinoseis:hmnia-eisagoghs-metoxon">
               <type>d:date</type>
            </property>
         </properties>
      </aspect>
      <aspect name="exaeAnakoinoseis:arithmos-metoxon-aspect">
         <title>Αριθμός Μετοχών</title>
         <properties>
            <property name="exaeAnakoinoseis:arithmos-metoxon">
               <type>d:long</type>
            </property>
         </properties>
      </aspect>
      <aspect name="exaeAnakoinoseis:kodikos-metoxhs-oasis-aspect">
         <title>Κωδικός Μετοχών στο Όασης</title>
         <properties>
            <property name="exaeAnakoinoseis:kodikos-metoxhs-oasis">
               <type>d:text</type>
            </property>
         </properties>
      </aspect>
      <aspect name="exaeAnakoinoseis:kodikos-isin-aspect">
         <title>Κωδικός ISIN</title>
         <properties>
            <property name="exaeAnakoinoseis:kodikos-isin">
               <type>d:text</type>
            </property>
         </properties>
      </aspect>
      <aspect name="exaeAnakoinoseis:drasthriothta-aspect">
         <title>Δραστηριότητα</title>
         <properties>
            <property name="exaeAnakoinoseis:drasthriothta">
               <type>d:text</type>
            </property>
         </properties>
      </aspect>
   </aspects>
</model>‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

[gclaussn]

Aspects are Alfresco specific. They are not defined within the CMIS specification!

best regards, gclaussn

[mrogers]

Alfresco has proposed extending the CMIS specification to include Aspects since its clear that there is a need for them, however they are not part of CMIS 1.0.   Which is why the Alfresco CMIS interface not longer shows them.

I think Alfresco can be switched to a "less strict" CMIS mode that does have some non standard extensions such as aspects.