OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

icom message

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


Subject: RE: [icom] RE: Agenda for ICOM TC Meeting on August 18, 9:00 - 10:30AM PDT


I would like to propose two more agenda items 5 and 6:

 

5. Nominate a person to investigate the mappings from ICOM Forum to Jive ForumMessage:

 

http://www.jivesoftware.com/docs/jive_sbs/3.0.12/javadoc/api/com/jivesoftware/community/ForumMessage.html

 

http://www.jivesoftware.com/docs/jive_sbs/3.0.12/javadoc/api/com/jivesoftware/community/Attachment.html

 

The person should also investigate mappings of ICOM to other concepts in Jive (see the API docs below)

 

http://www.jivesoftware.com/docs/jive_sbs/3.0.12/javadoc/api/com/jivesoftware/community/package-summary.html

 

6. Discuss how to specify the mandatory and optional features of ICOM.

 

We design ICOM to accommodate emerging features in collaboration tools. For example, we may allow group or individual person as interchangeable in many “slots/roles” such that a group can be a member of a space, an owner of an object, and a watchable presentity. However, some collaboration tools may not support the capability to represent Group as an Owner. While we define the concept of Owner and specify that it is mandatory for Actor/User to subclass Owner, we can leave it as an option for an ICOM compliant implementation to include Group in Owner, i.e., optional for Group to subclass Owner.

 

Thanks,

Eric

 

From: Eric Chan
Sent: Tuesday, August 17, 2010 6:35 PM
To: icom@lists.oasis-open.org
Subject: [icom] RE: Agenda for ICOM TC Meeting on August 18, 9:00 - 10:30 AM PDT

 

The UML diagram below explains why it is necessary to introduce the UML interface Element. When we introduce the UML interface Discussion and define Discussion as the type of elements in DiscussionContainer, we get the warning that this attribute is incompatible with the inherited attribute in ArtifactContainer that has the type Artifact. We corrected the problem by introducing the interface Element as the type of the elements in ArtifactContainer.

 

Discussion.jpg

 

 

Regards,

Eric

 

From: Eric Chan
Sent: Tuesday, August 17, 2010 5:58 PM
To: icom@lists.oasis-open.org
Subject: Agenda for ICOM TC Meeting on August 18, 9:00 - 10:30 AM PDT

 

Agenda

 

1. Roll Call

2. Approve draft minutes from Aug 4 TC Meetings

                http://www.oasis-open.org/apps/org/workgroup/icom/email/archives/201008/msg00004.html

3. Status update of milestones

4. Review of discussion forum and mailing list model (Please see review notes below)

5. AOB

 

Please sign on to ICOM TC chat room   

http://webconf.soaphub.org/conf/room/ICOM-TC

 

ICOM TC Meeting Conference Call

 

Date:  Wednesday, 18 August, 2010

Time:  09:00am – 10:30am PDT

 

InterCall Conference id: 9128348

InterCall Password: ICOMTC (426682)

 

From the AMER region dial:

                +1 866-682-4770

                +1 408-774-4073

From the EMEA region dial:

                +44 (0) 2081181001 (UK)

                +44 (0) 8444936817 (UK)

                +353 (0) 1 247 5650 (Dublin)

                +33 (0) 176728936  (Paris)

From the APAC region dial:

                +61 2 8064 0613 (Australia)

 

For your local numbers, please check additional global access numbers listed at http://www.intercall.com/oracle/access_numbers.htm

 

Review Notes:

 

Based on

 

1.       Laura’s proposals http://www.oasis-open.org/apps/org/workgroup/icom/email/archives/201007/msg00021.html and

2.       Eric’s suggestion to define generic concepts to compose specialized concepts (see comments in http://www.oasis-open.org/apps/org/workgroup/icom/email/archives/201008/msg00000.html),

 

the following UML model was developed. Let’s review the model:

 

 

Forum.jpg

Figure 1. Model of Forum

 

MailingList.jpg

Figure 2. Model of Mailing List

 

In order to support the auxiliary class Discussion, it was necessary to introduce another auxiliary class Element as a superclass of Artifact. This was due to the UML and OO language issues.

 

ICOM High-Level Core Concepts 2.jpg

Figure 3 A new auxiliary class Element is introduced as superclass of Artifact

 

 



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