cmis-tc discussions
Advanced search
[cmis] Re: [cmis-comment] Property ID uniqueness
5 messages
expand all |
collapse all
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.
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
One use case where you get property definitions not tied to a type and
where for me uniqueness of property definitions is important is the
result set returned from a query.
If you get a query result that comes from a JOIN that has two SIZE columns:
SELECT Y.CLAIM_NUM, X.PROPERTY_ADDRESS, Y.DAMAGE_ESTIMATES, X.SIZE, Y.SIZE
FROM POLICY AS X JOIN CLAIMS AS Y
ON X.POLICY_NUM = Y.POLICY_NUM
WHERE (100000 = ANY Y.DAMAGE_ESTIMATES)
you may get a result sets containing:
<cmis:propertyInteger localName="foo"
propertyDefinitionId="SIZE" queryName="SIZE">
<cmis:value>1234</cmis:value>
</cmis:propertyInteger>
Anyway my point is that if the two SIZE columns can refer to two
different property definitions, then I cannot completely type the
returned value and associate it to a unique property definition.
One way to make the ambiguity disappear is to clarify whether we
actually get queryName="SIZE" or queryName="X.SIZE" (or Y.SIZE)? – We
probably need also an examples/QueryResult.xml in the zip to be
explicit.
I'm not sure this exactly the point that was raised, but it's related
to property definitions uniqueness...
Florent
On Mon, Jan 18, 2010 at 6:52 PM, Al Brown <albertcbrown@us.ibm.com> wrote:
>
> 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
>
>
--
Florent Guillaume, Director of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
I believe there is a need to express semantic equality of properties across object types, which is currently handled by prop id. For repository-defined properties, this is not a problem - in which case the repository has full control over the scope of uniqueness for each property defined. Categorically making all property definitions unique only within an object-type hierarchy would be an over-kill - it would remove CMIS’s ability to express semantic equality. On the other hand, if we use localName/localNamespace instead of prop id to express semantic equality, we would then need yet another attribute to capture the native property name whose uniqueness is repository-specific. And then, in that case, do we still need prop id?
IMHO, prop id is not the problem. The challenge is on CMIS-defined properties. Should they be unique only within a type hierarchy or unique across all object types?
One solution is to define cmis:document-name, cmis:folder-name, cmis:relationship-name, and cmis:policy-name instead of a common cmis:name. A repository then has a choice to map them either to separate native properties or to a single native property. In other words, CMIS would not mandate semantic equality of object name across object types. (I wonder if there is a need for CMIS to impose such a requirement.)
However, this approach will require a fair amount of spec changes. If the problem described by Raphael is not a wide-spread one, perhaps we can take this up in v2.
BTW, if we do want to make some of the CMIS-defined properties unique across all object types, then we should define them only once instead of 4 times - something to consider for v2.
dave
From: Al Brown [mailto:albertcbrown@us.ibm.com]
Sent: Monday, January 18, 2010 9:52 AM
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
The queryName's in the result list should correspond to the SELECT list in the query statement. In Florent's example, queryName may be "X.SIZE" or "Y.SIZE", but not "SIZE". Otherwise there can be ambiguity.
In general, a column in a SQL query result table may contain value computed by a SQL value expression, which may not necessarily correspond to a column in a source table. A simple example is "SELECT 'Hello' FROM foo", which returns a single column of a literal string 'Hello', one row for each row in table foo. Not very useful, but a legitimate query nevertheless. However, the only value expression allowed for v1 is the SCORE() function. So, a queryName in query result may be "SCORE()".
In the case of "SELECT X.SIZE AS C1, SCORE() AS C2 ...", the queryName can/should be C1, C2, ...
david
-----Original Message-----
From: Florent Guillaume [mailto:fg@nuxeo.com]
Sent: Monday, January 18, 2010 4:18 PM
To: Al Brown
Cc: cmis@lists.oasis-open.org; raphael.jean@entropysoft.net
Subject: Re: [cmis] Re: [cmis-comment] Property ID uniqueness
One use case where you get property definitions not tied to a type and
where for me uniqueness of property definitions is important is the
result set returned from a query.
If you get a query result that comes from a JOIN that has two SIZE columns:
SELECT Y.CLAIM_NUM, X.PROPERTY_ADDRESS, Y.DAMAGE_ESTIMATES, X.SIZE, Y.SIZE
FROM POLICY AS X JOIN CLAIMS AS Y
ON X.POLICY_NUM = Y.POLICY_NUM
WHERE (100000 = ANY Y.DAMAGE_ESTIMATES)
you may get a result sets containing:
<cmis:propertyInteger localName="foo"
propertyDefinitionId="SIZE" queryName="SIZE">
<cmis:value>1234</cmis:value>
</cmis:propertyInteger>
Anyway my point is that if the two SIZE columns can refer to two
different property definitions, then I cannot completely type the
returned value and associate it to a unique property definition.
One way to make the ambiguity disappear is to clarify whether we
actually get queryName="SIZE" or queryName="X.SIZE" (or Y.SIZE)? - We
probably need also an examples/QueryResult.xml in the zip to be
explicit.
I'm not sure this exactly the point that was raised, but it's related
to property definitions uniqueness...
Florent
On Mon, Jan 18, 2010 at 6:52 PM, Al Brown <albertcbrown@us.ibm.com> wrote:
>
> 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
>
>
--
Florent Guillaume, Director of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
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
Running on CRX and Apache Sling
Copyright © 2012 Day Software, Inc.
Copyright © 2012 Day Software, Inc.