From: Al Brown
[mailto:albertcbrown@us.ibm.com]
Sent: Tuesday, November 18, 2008 1:00 PM
To: David Nuescheler
Cc: cmis@lists.oasis-open.org
Subject: Re: [cmis] What you think the TC should do
David,
Good topics. We should also discuss the relation to JCR and level of
interoperability desired if any.
1. Charter
Charter can be redone, but all companies would have to rejoin and it is a long
process. Does the subsequent version (after 1.0) remove those limitations, or
more specifically, which ones do you see? It is generally better to not re-open
that can of worms especially as we are getting started. Typically the charter
review process at OASIS is the right time for those comments.
[mpm] Charter clarification is easy since
it “clarifies” the intent of the TC or reduces scope. Scope
expansion (a/k/a Rechartering) is a different matter entirely.
2. REST Binding issues
Please submit those issues to JIRA (http://tools.oasis-open.org/issues/browse/CMIS).
Mary, is this active for the TC as a whole?
[mpm] It should be; that said, I need to
add people manually so if I missed someone – or if someone joined the TC
since this past weekend, please let me know. I hope to receive auto-notification
of joins shortly. All TC Members (that is anyone on the roster in any role
other than Observer) should have received a message with their login and be
able to create new issues.
3. RI and TCK
OASIS, I believe, typically does not provide RI's or TCKs. These are of course
very interesting to effort. I think we should discuss this topic at the next
meeting.
[mpm] We do have TCs involved in creating
Test Suites. That said, we do not conduct actual testing or testing
harnesses/frameworks and leave that to third-parties.
4. IPR / Licensing terms
The charter states RF on RAND terms which is defined by OASIS (http://www.oasis-open.org/who/intellectualproperty-2008-05-02.php)
section 10.2.2
-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.
"David Nuescheler" ---11/18/2008 09:39:08
AM---Dear TC Members,
From:
|
"David Nuescheler"
<david@day.com>
|
To:
|
Al Brown/Costa Mesa/IBM@IBMUS
|
Cc:
|
cmis@lists.oasis-open.org
|
Date:
|
11/18/2008 09:39 AM
|
Subject:
|
Re: [cmis] What you think the TC should do
|
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/
---------------------------------------------------------------------
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