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: CMIS Help / Confusiion around namespaces


I have some questions on a few issues that are closed but I’m not clear on:  Can you please review and let me know your thoughts?  There may be an issue to file here, or re-open one of these:

 

CMIS-139 is the issue about adding namespaces to the property names, as in cmis:ObjectId, etc.  It is related to CMIS-105 to resolve confusion between a cmis property and a document property with the same name.  That issue was closed as being handled by the namespace proposal.

 

There is some discussion in the issue between Florian (who advocates some sort of concatenated string delimited with something (colons, periods) and Al (who wants either nothing or some separate field to "tag" cmis properties).

 

So, what has happened here?

 

CMIS-105 was closed as resolved by namespace proposal.  CMIS-139 is also closed, with apparently two resolutions:  Al wrote it is fixed in 0.61, but I don't see anything there that relates to either Florian's proposal or Al’s counter.  Then after that, it was closed as a duplicate with no indication of what it duplicates.  Also, I see no indication captured in the issue that this was discussed or resolved by the TC.

 

CMIS-273 adds a groupid attribute (mandatory, and must be a URI) to everything that currently contains an id.  However, IDs are opaque to the cmis client and have no specific required formatting, so what exactly does this do that could not be done by a server building in some format to their ids?  In fact, Martin says that "globally unique identifier can be composed by concatenating the group identifier plus the property name" (I think this means property id, as Martin has replaced the name with id earlier).  Why can't the server be given the responsibility to create GUIDs in whatever form they wish?

 

CMIS-273 also removes the property name and adds a property queryName, which has the exact same semantics (uniqueness, SQL92-ness, etc) that the current property name has.  So while 'queryName' might be more descriptive, it hasn't really changed any of the issues that prompted CMIS-139.

 

--

 

Oracle’s thoughts:

 

We still have the problem that was the basis of CMIS-105, and would like to see the namespaces solved as proposed in CMIS-139 (proposal section).  We also require the ability to set our own namespaces.  We need at a minimum Al's "marker" with the ability to put our own stuff in there (and a reserved marker word for cmis properties).  Also, this same scheme must extend to the query BNF so that we can tell which namespace/group/package/prefix whatever is referred to.  I think the original namespaces proposal was the best on this front.

 

It looks like "package" was added to the schema, but it is not described in the spec.  That is probably the closure on 139, but it doesn't work.

 

It appears you could create a property definition with:

 

        name:  Name

        package: cmis

    and

        name: Name

        package: ora

 

Note - the package is required (minOccurs=1) per the schema, but not used anywhere else in any way that I can see.  It was not added to the property (instance) or to the type definition, or to the Query syntax - just to the property definition.

 

This is not a comprehensive solution - it doesn't solve any issue.  You still need to have properties which have distinct names, so the above example must be invalid (since Name = Name) so the package attribute does not solve the original proposal (namespacing).

 

We need namespacing similar to the original namespaces proposal, and it needs to be applied to any name that would appear in a query (property names and type queryNames).

 

-Ryan

 



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