Re: [cmis] joining the TC, introduction, HTTP thoughts

This is a good discussion. On the point below, I personally would like to understand the issues however I don't want to impose constraints on CMIS or set the perception that the CMIS specification should follow a particular JCR constraint without discussion by the TC especially if that constraint is not already followed by existing repositories.

>While mapping to a proprietary API is of course a perfectly good solution

>for any particular vendors implementation it does not really help us find the

>mapping and differences between JCR and CMIS which I think would be

>desirable, as mentioned above.

>I do not think that it is something that this TC would have to attend

>to but it is something that is going to be developed eventually as an open

>community effort in the Apache Software Foundation anyway, so I will keep

>the group posted on any potentially relevant findings.

-Al

Al Brown

ECM CTO Staff, Information Managament

Office     714 327 3453

Mobile   714 263 6441

Email     

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" ---12/06/2008 09:15:57 AM---Hi Al,

From:

"David Nuescheler" <>

To:

Al Brown/Costa Mesa/IBM@IBMUS

Cc:

"Julian Reschke" <>, 

Date:

12/06/2008 09:15 AM

Subject:

Re: [cmis] joining the TC, introduction, HTTP thoughts

Hi Al,

Thanks a lot for your mail.

Let me comment on a couple of points.

> I also believe that CMIS is (or can be mapped) to a subset of JCR. So it

> would be interesting for the JCR EG to define a profile/level that can exist

> directly on top of a CMIS-compliant repository. That would give Java

> developers alternatives to Abdera or JAX-WS APIs. I am all for that.

That's great to hear.

While I agree that a JCR mapping would give Java developers

more options, I would really like to stress that I do not see

that at the same level as the Apache Abdera Project.

JCR is already an integral part of Abdera since v0.4 (see release

notes [1]) and

since Abdera and Jackrabbit are sister projects at Apache the two

communities interact well based on the fact that they operate under

the same licensing and intellectual property framework within the ASF.

The additional value that the JCR / CMIS mapping would bring to the

table is that helps us understand where the models are different and

why the decision that we took in JCR are now different in CMIS.

While of course it is perfectly fine to differ from any existing standards

(not just JCR) I think the TC should do that consciously rather

than "by accident".

In my mind this perfectly aligns with the charter of creating liaisons

to other respective standards like HTTP, WebDAV, JCR and hopefully

AtomPub.

There are a number of things that in hindsight we would have done

differently in all of these specification and there is definitely no need

to make the same mistakes twice, but for a large part the experts that

defined the respective specifications at the time, had good reasons

to do things a certain way, which means that the rationale at the time

may also apply to CMIS.

> I have also had interesting discussions with David N about Jackrabbit

> exposing CMIS. As Jackrabbit is a repository, it makes sense to encourage

> that group to expose a CMIS interface as well. I think that will be very

> beneficial for the effort. We already have a repository that supports the

> current CMIS model and JCR - Alfresco.

I would assume that the Alfresco implementation maps CMIS to its internal

proprietary interface not to JCR (maybe Dave or John could comment on

that, I may be wrong since I try to look at GPL'd code as little as possible

for obvious reasons).

While mapping to a proprietary API is of course a perfectly good solution

for any particular vendors implementation it does not really help us find the

mapping and differences between JCR and CMIS which I think would be

desirable, as mentioned above.

I do not think that it is something that this TC would have to attend

to but it is something that is going to be developed eventually as an open

community effort in the Apache Software Foundation anyway, so I will keep

the group posted on any potentially relevant findings.

regards,

david

[1] http://abdera.apache.org/

---------------------------------------------------------------------

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