[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [icom-comment] comments from Jacques Durand
|
I opened the JIRA issues for the
following comments and proposals. Regards, From: Jacques Durand
[mailto:JDurand@us.fujitsu.com] comments from Jacques Durand
(as a review assignment from the OASIS TAB) on: Integrated
Collaboration Object Model (ICOM) for Interoperable Collaboration Services
Version 1.0 ----------------------------------------------------------------------------- Overall well structured
specification, but rather "dry" in terms of explanation text and
definitions. [Comment 1] : The Abstract
(unlike the rest of the specification) is a bit too verbose (not the right
place to use examples: would see these in
Introduction instead) [Proposal 1] http://tools.oasis-open.org/issues/browse/ICOM-9
Remove the sentence "For example, applications can
aggregate conversation threads in email with other conversations on the same
topic in instant message, over the phone or via real-time conferencing, by
discussion threads in community forum, weblog or micro blog, and activity
stream of participants from all channels." [Comment 2] : Section 2:
Modeling language: It would be good to refer to existing other modeling
languages,(CIM, MOF, fUML/UML...) and a bit of argumentation why ICOM needs its
own. [Proposal 2] http://tools.oasis-open.org/issues/browse/ICOM-10
We can elaborate that ICOM specification is following the
Content Management Interoperability Services (CMIS) grammar so that ICOM types
(aka. Concepts or classes) can be defined as domain specific type extensions in
CMIS. ICOM spaces, folders, and artifacts are extensions of CMIS base types for
folders and documents. ICOM integrates the actor, resource actor, group, and
role types (primarily from LDAP) with CMIS content types. By defining the
actor, resource actor, group, and role types in CMIS grammar, ICOM enables more
seamless association between actors and contents, and enhances the access
control model. [Comment 3] : Section 2: A
glossary of modeling terms would be useful, or at least a short definition at the beginning of each section (e.g. Section
2.3 could informally start by defining "Property") [Proposal 3] http://tools.oasis-open.org/issues/browse/ICOM-11
We may reference or include the glossary from CMIS
specification. (see proposal for issue
http://tools.oasis-open.org/issues/browse/ICOM-10) [Comment 4] : Section 3:
Again before diving into the "branches" of the Core Model, an overall general overview diagram would be
helpful, along with a short narrative explaining
the raational for these branches. [Proposal 4] http://tools.oasis-open.org/issues/browse/ICOM-12
An diagram that depicts all
three branches (like
http://www.oasis-open.org/committees/download.php/40066/ICOM%20High-Level%20Core%20Concepts.jpg)
can be included in Section 3. The three branches support the separation
of concerns for user administration and content management. i)
Subject branch includes
the actor, grouping of actors, and role assignment of actors that are typically
the “subjects” of (subject, privilege, object) triples in access
control policies. ii)
Artifact branch includes
the contents and metadata produced by the actors. iii)
Scope branch includes
the community and space that defines the scope of role assignments. The scopes join
the subjects and artifacts, providing a scheme for property chaining. The Subject and Artifact
branches separate the concerns for administration of users and contents. The subjects
and artifacts are joined together by the scopes from the Scope branch through
the axiom schemes as described in the following example. Let’s take a model of OASIS
TC’s in ICOM. In this model Eric is a subject from the Subject branch. The
specification documents icom-ics-v1.0-csprd01.doc and bpel4people-1.1-spec-cs-01.doc
are two instances from the Artifact branch. The ICOM-TC space is a scope from
the Scope branch. Martin has administrative privileges to authorize Eric to participate
in ICOM-TC space as a member. Patrick is a contributor of icom-ics-v1.0-csprd01.doc in ICOM-TC
space. Martin’s action to authorize Eric to participate ICOM-TC space and
Patrick’s action to contribute icom-ics-v1.0-csprd01.doc in
ICOM-TC space are joined by the an axiom scheme that entails “Eric has read
write privilege for icom-ics-v1.0-csprd01.doc”
from “Eric is a member of ICOM-TC space”, “a member of a TC
has read write privilege for artifacts in the TC space”, and “ICOM-TC
space contains icom-ics-v1.0-csprd01.doc.”
“Eric is a member of ICOM-TC” is in turn derived from “Eric is
assigned to a TC-Member role which is assigned to ICOM-TC space.” [Comment 5] : Section 4: At
beginning, a Short overview of all the extension modules, and short narrative
for each would be helpful. [Proposal 5] http://tools.oasis-open.org/issues/browse/ICOM-13
ICOM is defined in modular and extensible way, with core
concepts, metadata concepts, and their relations included in Section 3. In
Section 4, the specific concepts and relations for each area of collaboration
activities are defined in separate extension modules. The extension modules
include Content, Document, Message, Presence, Address Book, Calendar, FreeBusy,
TaskList, Forum, and Conference modules. Some of the extension modules
integrate models from existing standards, such as Content Management
Interoperability Services [CMIS], Java Content Repository API [JCR 2.0], Web
Distributed Authoring and Versioning (WebDAV) [RFC4918], Internet Message
Access Protocol (IMAP) [RFC2119], Simple Mail Transfer Protocol (SMTP)
[RFC5321], Extensible Messaging and Presence Protocol (XMPP) [RFC3920], XMPP
Instant Messaging and Presence [RFC3921], vCard MIME Directory Profile [RFC2426],
Internet Calendaring and Scheduling Core Object Specification (iCalendar)
[RFC5545], and Calendaring Extensions to WebDAV (CalDAV) [RFC4791]. Content module defines the data model for a document or
message. The content, multi-content , simple content, and online content form a
composite design pattern. Document module defines the document model and the
version control metadata model for documents. Message module defines the abstract message model, UnifiedMessage,
and InstantMessage. It also defines a mixed in class called MimeConvertible, which
includes UnifiedMessage and Document, that can be added as multi-part content
of a UnifiedMessage. AddressBook module defines address book as a folder that
contains contacts, which can include bookmarks to addressable entities in the
directories, addresses, and other personal entries. Calendar module defines calendar as a folder that
contains time management artifacts such as occurrences and occurrence series. TaskList module defines task list as a folder that
contains task management artifacts such as tasks and task assignments. Forum module defines forum as a folder that contains
sub-forums, topics, announcements, and discussions. Conference module defines conference as a folder for
visual, audio, and chat transcripts of the conference sessions. [Comment 6] : Section 5 Conformance:
These Roles should be briefly defined, intuitively in terms of user perspective
or context of utilization. In particular, (I assume) we
are talking of Roles here that have nothing to do with 3.5.4 section. (should
be made clearer) Assigned to Patrick for response: http://tools.oasis-open.org/issues/browse/ICOM-14
[Comment 7] : Section 5
Conformance: The first 2 points in the numbered list (1,2) look like a
cut-and-paste gone wrong: should really "Service provider
role" be repeated twice here? 1. Service provider role: An
ICOM service provider shall conform to all mandatory and optional ... Section 3 2. Service provider role: An
ICOM service provider shall conform to all mandatory and optional ... Section 4 I would advise to more
clearly separate the requirements for each type of role, into separate
Conformance Clauses. Assigned to Patrick for response: http://tools.oasis-open.org/issues/browse/ICOM-15
[Comment 8] : Section 5
Conformance: "Models" should be "Modules" in the sentence: "shall conform to all
mandatory and optional statements for one or more extension models as defined
in Section 4 " Assigned to Patrick for response: http://tools.oasis-open.org/issues/browse/ICOM-16
[Comment 9] : Section 5
Conformance: The rationale of "one or more extension modules" (at the
user's choice) in point #2 of conformance clause is hard to
understand. Sounds like a quantitative
requirements to fulfill about a number of discrete functional capabilities that
have nothing to do with each other (how will that help me
assess the level of ICOM compatibility of an implementation, or its functional
scope if the implementation implements a different module compared to mine or
to another?) In that case why not
define 2 levels of conformance: Core conformance level, then Extended
conformance level (which involves 1 or more ext Modules). Assigned to Patrick for response: http://tools.oasis-open.org/issues/browse/ICOM-17 Regards, Jacques D. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]