OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cmis message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cmis] [CMIS 1.1 Draft Review] CMIS 1.1 Working Draft 01b: discussion of section 2.1.4.3.3 and Secondary Types


Same subject - more background info:

Because of the potential promise of Secondary types, I had withdrawn my suggestion (CMIS-723) that in 1.1 (or 2.0) we either add a new (5th) base object type cmis:custom or allow the root cmis:object to be subclassed by repositories like we do for the base types in 1.0.

http://tools.oasis-open.org/issues/browse/CMIS-723

In the process of reviewing the spec, I am now not certain that Secondary types can address this problem, and if not I may need to re-vive CMIS-723. Before doing that I would like to have a brief discussion about this in Monday's call. Mainly to see if anyone has any ideas on how Secondary types could be interpreted to solve this somewhat different requirement.


Jay Brown
Senior Engineer, ECM Development
IBM Software Group
jay.brown@us.ibm.com

Inactive hide details for Jay Brown---01/05/2012 03:59:52 PM---This might be the tip of a bigger issue with Secondary types butJay Brown---01/05/2012 03:59:52 PM---This might be the tip of a bigger issue with Secondary types but I will start it out this way and we


From:

Jay Brown/Costa Mesa/IBM@IBMUS

To:

cmis@lists.oasis-open.org

Date:

01/05/2012 03:59 PM

Subject:

[cmis] [CMIS 1.1 Draft Review] CMIS 1.1 Working Draft 01b: discussion of section 2.1.4.3.3 and Secondary Types

Sent by:

<cmis@lists.oasis-open.org>





This might be the tip of a bigger issue with Secondary types but I will start it out this way and we can make it a Jira issue if necessary.

Section 2.1.4.3.3 says of Property Definitions:
Then the document proceeds to list all of the property definitions that we know and love for CMIS 1.0 documents. However I think this is no longer the case that documents MUST have all of these.

For example say that in my repository I need to expose a type of cmis:Document that does not have content. So I define a secondary type called hasContent. This secondary type has the properties related to content that were formerly in Document. Specifically
cmisContentStreamFilename
cmisContentStreamLength
cmisContentStreamMimeType
cmisContentStreamID

I have two subclasses of cmis:Document one with this secondary type applied and one without. My basetype must no longer have these formerly mandatory document properties. This applies to all of the document properties. I.e. Added to the definition for cmis:Object in the domain model.

This also applies to verbs that are applicable to Document, like set/get/delete content stream. (though verbs related to secondary types may also need to be a separate subject/ issue)


Jay Brown
Senior Engineer, ECM Development
IBM Software Group
jay.brown@us.ibm.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]