Re: [cmis] What you think the TC should do

["David Nuescheler" <david@day.com>]

Dear TC Members,

I think that the focused scope in terms of applications [1] that CMIS is
chartered bears certain limitations. Since I am not familiar
with the OASIS processes I would like to ask if the TC is even
allowed to revisit and potentially extend the charter and the use-cases
beyond the original submission.
This is more of process question for Mary or other people from
OASIS, I believe...
[I am not even sure if I really want to open that can of worms ;)...]

There are number of broader things that need to be addressed in the
"REST bindings" of specification and I think they come in the form of a list of
issues that I am happy to contribute. I had various conversations with
a number of people that have a lot of experience designing protocols
that support a REST-style interaction and I think there is a good consensus
on most of the things that need to be changed.
Some of the issues have been discussed in public already [2][3].

Knowing Julian, I tend to think that he may very well be aware of more
complete and detail oriented list of issues...

Since MashUps are defined as a goal in the charter I think we might want to
make it easier for people with a simple web-browser to interact with a
CMIS enabled system, possibly with as little javascript libraries as possible.

Personally, I am very much in favor of keeping the entry barrier as low
as possible,  which would mean essentially that we would allow simple
HTML form POSTs and simple GETs that can be produced in any browser
easily to interact with the system. I don't think that this would be too
much of a change at the current stage and adds tremendous value.

In addition to these topics I would like to raise the following points:

Does the TC plan to create a "reference implementation" and
a "test suite"?
I think this would greatly enhance interoperability of systems and
allows for much faster adoption.

Has the licensing of the Specification and the "test suite" been decided
up on (Sorry, if I missed that)? Generally I would suggest the most open
licensing possible, which is probably the Apache License [4] or
something compatible.
Personally, I think this may be a fairly important topic to cover as soon
as possible in the process.

Looking forward to talking to all of to you soon.

regards,
david

[1] http://lists.oasis-open.org/archives/tc-announce/200810/msg00003.html
[2] http://roy.gbiv.com/untangled/2008/no-rest-in-cmis
[3] http://intertwingly.net/blog/2008/10/01/CMIS
[4] http://www.apache.org/licenses/LICENSE-2.0

On Tue, Nov 18, 2008 at 5:46 PM, Al Brown <albertcbrown@us.ibm.com> wrote:
> David,
>
> Thank you for starting this discussion. I am interested in having a simple,
> easy to use and implement specification that addresses the common (80%) use
> cases required by the majority of ECM applications on a repository.
>
> I would like to be able to leverage CMIS for engineering efficiency when
> developing connectors to IBM repositories, namely FileNet P8 Content Manager
> and IBM Content Manager 8. I'd also like help customers protect their
> investments in applications they buy or develop to allow them to run those
> applications on repositories of their choice. I'd also like to encourage
> ISVs in this space to develop ECM applications that run across many
> different repositories.
>
> To keep it simple, I'd like the minimum number of optional features. I'd
> also like the features/functionality to be fully discoverable by the client
> if variations are allowed.
>
> In 0.5, the feature that comes up a lot as missing is Access Control Lists.
> E.g., the ability to set a simple list of users or groups who have access to
> an object. I am not sure it is required. It does come up frequently. Another
> item that may be relevant is hierarchical or complex properties. An example
> of this would be an address property that contains street, city, state and
> zip properties.
>
> I'd also like to get a core specification out as soon as possible that
> provides the ECM industry a base to start from for interoperability while we
> then add additional capabilities in the next release. This also allows us to
> learn and gain feedback from the marketplace.
>
> -Al
>
> Al Brown
> ECM CTO Staff, Information Managament
> Office 714 327 3453
> Mobile 714 263 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.
>
> Choy_David---11/17/2008 03:52:00 PM---In preparation for "TC objective"
> discussion next Monday, I encourage
>
>
> From:
> Choy_David@emc.com
> To:
> <cmis@lists.oasis-open.org>
> Date:
> 11/17/2008 03:52 PM
> Subject:
> [cmis] What you think the TC should do
> ________________________________
>
>
> In preparation for "TC objective" discussion next Monday, I encourage
> each member share his/her thoughts (if there is any) on what this TC
> should do towards the first release of CMIS spec (besides bug fixing and
> editorial enhancement). Sharing thoughts in advance can make our
> discussion more efficient. For example, tell us
> - Any aspect in v0.5 that you think needed more work
> - Any capability not in v0.5 that you think should be added to
> make 1.0 useful
> - Whether you think the "compliance model" in v0.5 is reasonable
> (i.e. there are a fixed number of optional features that are
> individually discoverable)
> - Whether you think v0.5 is more or less sufficient content-wise,
> and that the TC should get 1.0 out quickly once the quality of the spec
> is up to par
> Let us know what you think. This is a direction/scoping discussion, to
> give us some idea where we may be heading, and also to help us see if we
> need to take certain action proactively.
>
> For any specific issue that you may have on the spec, please submit it
> through the Issue Tracker instead.
>
> Thanks,
>
> david
>
> ---------------------------------------------------------------------
> 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
>
>
>
>
>



-- 
Visit: http://dev.day.com/