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: Re: [cmis] What you think the TC should do


hi mary, al & david,

thanks a lot for your responses ...and...

> "In the month of October,  I scanned
> approximately 2500 emails (excluding spam); of which approximately 600 were
> addressed directly to me and required some action or response."

... wow, very impressive.

regards,
david


On Tue, Nov 18, 2008 at 7:13 PM, Mary McRae <mary.mcrae@oasis-open.org> wrote:
> Some responses inline. In general, while I monitor all TC lists and scan the
> messages to see if there's something I need to take action or respond to,
> it's best practice to actually include me in the To or CC line if you want
> to ensure that I pay attention J I posted this "Interesting Factoid" in a
> recent report to the Board: "In the month of October,  I scanned
> approximately 2500 emails (excluding spam); of which approximately 600 were
> addressed directly to me and required some action or response." That's just
> to say I sometimes miss stuff if my name isn't explicitly called out.
>
>
>
> Mary
>
>
>
> 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
>
>
>
>



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


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