[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cmis] CMIS Help / Confusiion around namespaces
We have a concern here – but perhaps
we’re missing something. The sql92 name restrictions cause a
challenge to build an encoding scheme between repository’s property names
and query names. This challenge seems a bit extreme. We need a way to
differentiate our querynames from the cmis properties as well – e.g. the
CMIS system property “name” and a property name “name”
need unique query names. What about encoding special characters found in the
name on the repository’s property name? We’re looking for a way to
get something unique that can be usable by a human for query generation. It
seemed like the namespace proposal solved this and I’m not sure how
adding a group id helps with query names, since those must be unique and sql92
compliant. We need namespaces in query names and an easy way to map those to
repository’s property names. Perhaps the sql92 restriction on query
names is overdoing it? Why do we need that restriction? Another concern: If we use groupId as a
URI, then what happens when that groupId ends up on a URI for a resource? Does
that mean we have to escape that id to fit into the resource’s URI? -Ryan From: Jens Hübel
[mailto:jhuebel@opentext.com] Hi Ryan, you are right. We
need some clarification around these topics. CMIS-139 was about
namespaces to differentiate between cmis and repository specific properties
(and to offer some possibilities for handling advanced properties). The
proposal included to separate property from namespaces by a colon. Then there was
confusion around property name vs id. vs query name vs. package and their
syntax restrictions in CMIS-87 There was a decision
on this, but this so far never made it to the spec. In addition we came
up with CMIS-167, an issue that property names have a syntax restriction on SQL
92 and may require a mapping. This mapping makes problem in certain
scenarios. Here the current proposal is (accepted in one of the last calls) to
allow arbitrary names in property names and restrict the syntax only on the
query name. Unfortunately this breaks the namespace proposal, because the ':'
as separator is no longer unique. So we came up with a modification of the namespace
proposal (introducing the group-id) and CMIS-273 is the issue to address all
this. CMIS-273 reintroduces the id on a property name (which was discarded in
CMIS-87). The proposal in 273 should go into the next spec version but has not
yet been discussed/accepted by the TC. I hope this
clarifies a bit. Feedback is welcome Jens From: 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]