RE: [cmis] Re: [cmis-comment] Property ID uniqueness

[<Choy_David@emc.com>]

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