
|
If you were logged in you would be able to see more operations.
|
|
|
| Proposal: |
Part I...
1) 2.7.2.1 Attributes common to all Object-Type Definitions
a) keep type name
b) remove baseType
c) add baseTypeName; whose value is one of Document, Folder, Relationship, Policy
d) remove baseTypeQueryName
e) rename parentId to parentTypeId
e) remove id from type
Part I...
1) 2.7.2.1 Attributes common to all Object-Type Definitions
a) keep type name
b) remove baseType
c) add baseTypeName; whose value is one of Document, Folder, Relationship, Policy
d) remove baseTypeQueryName
e) rename parentId to parentTypeId
e) remove id from type
|
|
The definition of type ids and query names is disjoint between part I and part II of the spec.
As I understand there are six concepts:
- ObjectTypeId (value is repo specific)
- ParentTypeId
- BaseObjectTypeId
- ObjectTypeQueryName (spec defines values for root types e.g. Document, Folder, ...)
- ParentTypeQueryName
- BaseTypeQueryName
However, part I of the spec does not define properties for all above even though part II defines a serialization mapping for them e.g. base type id.
I would like to see the spec (Part I) also define well known ObjectTypeId values for root types. This would then allow Object Type Definition to support following attributes:
- ObjectTypeId
- ParentTypeId
- BaseTypeId
- TypeQueryName
And Base Object Type to support the following properties
- ObjectTypeId
- BaseTypeId
Part 2 is then a direct serialization of above. This means Query Name must be retrieved via Type Definition (I think that's ok, as it's generally used to drive query builders). However cmis:object provides its actual type id and a known base type id that can be switched on by a client (e.g. split between item and container) without requiring retrieval of Type Definition (a common use case).
|
|
Description
|
The definition of type ids and query names is disjoint between part I and part II of the spec.
As I understand there are six concepts:
- ObjectTypeId (value is repo specific)
- ParentTypeId
- BaseObjectTypeId
- ObjectTypeQueryName (spec defines values for root types e.g. Document, Folder, ...)
- ParentTypeQueryName
- BaseTypeQueryName
However, part I of the spec does not define properties for all above even though part II defines a serialization mapping for them e.g. base type id.
I would like to see the spec (Part I) also define well known ObjectTypeId values for root types. This would then allow Object Type Definition to support following attributes:
- ObjectTypeId
- ParentTypeId
- BaseTypeId
- TypeQueryName
And Base Object Type to support the following properties
- ObjectTypeId
- BaseTypeId
Part 2 is then a direct serialization of above. This means Query Name must be retrieved via Type Definition (I think that's ok, as it's generally used to drive query builders). However cmis:object provides its actual type id and a known base type id that can be switched on by a client (e.g. split between item and container) without requiring retrieval of Type Definition (a common use case). |
Show » |
|
I'd like to propose the following changes...
Part I...
1) 2.7.2.1 Attributes common to all Object-Type Definitions
a) typeId value no longer repository specific. Instead is one of Document, Folder, Relationship, Policy
b) remove baseType
c) add baseTypeId; type ID whose value is one of Document, Folder, Relationship, Policy
d) remove baseTypeQueryName
e) rename parentId to parentTypeId
This gives us:
- three IDs for all Object Type Definitions; typeId, parentTypeId & baseTypeId
- one Query Name for all Object Type Definitions; queryName
2) 2.7.4.1.2, 2.7.4.2.2, 2.7.4.3.2, 2.7.4.4.2 Object-Type Property Definitions
a) add BaseTypeId; type ID whose value is the type id of base type i.e. one of Document, Folder, Relationship, Policy
This gives us:
- two type ID properties for all object instances; ObjectTypeId, BaseTypeId
Part II: AtomPub and SOAP bindings
a) No special treatment is given to base type. The ObjectTypeId and BaseTypeId properties are represented as any other property i.e. mapped to cmis:property/cmis:value.