I think that there are many repositories out there that only
enforce to the uniqueness constraint on an property within the type. As we de
not enforce any naming restrictions on the type id it should be possible to
generate a unique id (e.g. like TypeDefId.PropId) for every implementation. However
personally I would prefer to make the mapping from the widely used property id back
to whatever the repository needs internally as simple as possible and avoid
additional parsing here if possible). Therefore moving uniqueness to the pair localName/localNamespace
seems to be more appropriate to me.
If a repository has the need to express uniqueness then imho it
also should be able to express this with the local namespace/name and I think
it was introduced for this purpose.
Should the spec make a statement about the scope of uniqueness of
the queryName?
Jens
From: Al Brown [mailto:albertcbrown@us.ibm.com]
Sent: Montag, 18. Januar 2010 18:52
To: cmis@lists.oasis-open.org
Cc: raphael.jean@entropysoft.net
Subject: [cmis] Re: [cmis-comment] Property ID uniqueness
Raphael brings up an interesting point that I feel requires discussion
before responding.
There are two use cases on the property definitions that are important:
1. Property Definitions are stored separately from type definitions and then
applied/added to type definitions. In that scenario those fields would not be
different if the same backing property is used.
2. Property ID conveys semantic equality such that a client can determine if
property x (title) is the same as property y (name) on different type
definitions.
Since CMIS dictates the object id for the base properties, in particular
cmis:name, cmis:objectId, cmis:objectTypeId, cmis:baseTypeId, cmis:createdBy,
cmis:creationDate, cmis:lastModifiedBy, cmis:lastModififcationDate, and
cmis:changeToken. Out of those, I would expect cmis:name to be the most likely
one to use different backing properties. With FileNet, we map two different
properties to cmis:name - one for folder and one for documents. I believe the
lengths are the same in the FileNet case though.
We have gone through the various proposals on property definitions and now have
id, localName/localNamespace, displayName, and queryName. Out of those, only is
used for references and is mandated by CMIS specification.
I would propose that use case #2 (semantic equality) be moved from property ID
to localName/localNamespace. I would also state that a property definition can
change (max length, etc as described below) between type definitions. That
seems in line with the original intent of the statement highlighted.
Thoughts?
-Al
Al Brown
Office 714 327 3453
Mobile 714 251 6441
Email albertcbrown@us.ibm.com
CONFIDENTIAL NOTICE: The contents of this message, including any attachments,
are confidential and are intended solely for the use of the person or entity to
whom the message was addressed. If you are not the intended recipient of this
message, please be advised that any dissemination, distribution, or use of the
contents of this message is strictly prohibited. If you received this message
in error, please notify the sender. Please also permanently delete all copies
of the original message and any attached documentation.
Raphaël Jean ---01/16/2010 03:24:00 AM---Section
2.1.3.3.2 of the spec states that the Property ID "uniquely identifies the
property in the r
From: Raphaël Jean <raphael.jean@entropysoft.net>
To: <cmis-comment@lists.oasis-open.org>
Date: 01/16/2010 03:24 AM
Subject: [cmis-comment] Property ID uniqueness
Section 2.1.3.3.2 of the spec
states that the Property ID “uniquely identifies the property in the
repository. If two Object-Types each contain property definitions with
the same ID, those property definitions are the same.”
But some standard CMIS
properties, such as cmis:name, are defined on all Object-Type hierarchies
(document, folder, policy, relationship). Now, on many systems, the property
definition of cmis:name for example, will differ for folder, document and other
types: localName/localNamespace, maxLength, etc. will be different.
Shouldn’t the uniqueness scope
of a Property ID be a single Object-Type hierarchy instead?
Thanks,
Raphael Jean
CTO
EntropySoft