[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cmis] CMIS Help / Confusiion around namespaces
|
Hi Ryan, I didn’t got why proposal 273 wouldn’t solve your
problem. According to this proposal a property is uniquely identified by the
combination of id and group id. The group id an URI (formally known as namespace).
A specific namespace for CMIS properties is defined. The difference to the current spec is beside adding the group id
(or namespace) that the id is not required to be SQL compliant. This is
required to enable a client application to “find” its properties
via CMIS. For usage in a query an additional attribute queryName was added.
The repository can assure that the query name is unique and SQL compliant. Anything
missing from your side? Best regards, Martin From: Ryan Mcveigh
[mailto:ryan.mcveigh@oracle.com] 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]