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: Draft Minutes of ICOM TC Meeting, January 5, 2011

Minutes of ICOM TC Meeting, January 5, taken by Eric S. Chan

1. Roll Call 
2. Status of java.net article and incubation project for ICOM JPA framework 
3. AOB

1. The following eligible members were present


Laura Dragan

Patrick Durusau

Peter Yim

Eric Chan

PeterYim: suggest we each document the key points of our own remarks, so that, at the end of the meeting, the transcript from this chat-session can be used as the "minutes" of our meeting in the future
2. Status of java.net article and incubation project for ICOM JPA framework 
The TC is expecting to initiate a java.net project in about 2 weeks.
Eric S. Chan: The ICOM JPA provides a unified programming model as a frontend for a set of existing protocols/services, including LDAP, JCR, IMAP, SMTP, XMPP, Jive, iCalendar, CalDAV, WebDAV, vCard, BPEL,  BPEL4People, etc. In addition to unifying the API, the JPA offers a coherent programming model for lazy loading, change tracking, attach/detach/merge, cascade persist, etc, operations that are disjointed or non-existent in the existing services.
Laura Dragan: not sure how some of these features can be done in rdf
Laura Dragan: but as a selling point for the java part, and for the article is a good idea
Eric S. Chan:  For compatibility with JPA, we may have to introduce UnifiedMessageAttchment and DocumentAttachment classes to ICOM to keep JPA Entity and Embeddable categories disjoint. ICOM JPA prototype currently reuses UnifiedMessage class as Entity or Embedded object. The embedded UnifiedMessage objects are not entities but are objects that exist only as dependents of the containing UnifiedMessage entity. The identifier field of the embedded UnifiedMessage is nulled out so that the embedded UnifiedMessage objects are not sharable among entities (nor among more than one attribute or level of MIME hierarchy in the containing UnifiedMessage entity). The following scenario is where we find it natural to reuse the UnifiedMessage class as either Entity or Embedded, through an intervening cloning operation so that the same object does not simultaneously behave as an Entity and Embedded object.

It is a common scenario for ICOM applications to let a user forward email messages from her INBOX as attachments in a new email message. It seems natural to reuse the UnifiedMessage class to represent the attached messages which are derived from the UnifiedMessage entities in the INBOX. These attached messages are semantically compatible with the embedded objects in JPA, i.e. the attached messages don’t have object id, version id, and are not sharable. The following code snippet shows how the application can take a collection of UnifiedMessage entities, clone each entity, and add the clones as embedded objects in the MultiContent MIME structure. The UnifiedMessage entities being cloned can contain nested structures of embedded UnifiedMessage objects (representing long message threads).


public UnifiedMessage forwardMessages(HeterogeneousFolder draftFolder,

                              Collection<UnifiedMessage> attachments) {

Date dt = new Date();

      UnifiedMessage newMsg = new UnifiedMessage(draftFolder, dt, dt);



MultiContent forwards = new MultiContent();


for (UnifiedMessage message : attachments) {

message.getContent();                 // make sure to load the content before cloning (analogous to detaching)

UnifiedMessage msg = message.clone();    // clone the message

forwards.addPart(msg);                // the clone is attached or embedded as a MIME part

message.addFlag(UnifiedMessageFlag.Forwarded);  // the original message is flagged as “Forwarded”





Eric S. Chan: Similarly, we reuse Document and other types of MIME convertible entities to represent the embedded or attached objects in a message. The following code snippet shows the application saving the document attachments in a message to a folder.

MultiContent content = message.getContent();

if (content instanceof MultiContent) {

for (MimeConvertible mime: content.getParts()) {

            if (mime instanceof Document) {

Document doc = document.clone();


                  doc.setName(doc.getName() + " from " + message.getSubject());

                                icomManager.persist(doc);     // this explicit persist operation is not needed with use of Cascade Persist


These scenarios may represent the drag and drop activities in a user interface. It seems natural to interpret the dragging of a document attachment from a message into a folder as a copy and paste (or clone) operation that preserves the type of the artifact being copied. However, using the same class for Entity or Embeddable is causing compatibility problem with the JPA specification. 
PeterYim: (ref. earlier Eric/Laura exchange ...) the gap between tools available for mainstream software engineering (OO, java, etc.) and that for OnST (Ontology and Semantic Technology) is huge ... this conversation is both interesting and important, especially in terms of rolling out our Reference Implementations
PeterYim: Eric: we will make the OO and RDF representations isomorphic


3. AOB


The TC Meeting was adjourned.

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