DocumentFramework, DomFramework and CommunityFramework
specifications are broken as a result of the changes
introduced to the Task and Session specification
formal/2000-05-02 (refer detailed issues 1, 2 and 3 -
posted 15 OCT 2000) and proposed revisions under
EC/2000-10-01.

• To a large extend the interfaces defined under the
  SessionFramework are now redundant.

• Definition of links between resource types concerning
  community services must be redefined based on an
  extendable Link architecture (raised under issue 1).

• Issues 3461-3474 reflect a level of complexity of the
  original specification in terms of the management of
  control types relative to containing resource type.
  During assessment of issues, it has been identified
  that the specifications can be substantially simplified
  and clarified through the use of valuetypes when defining
  control structures. This approach will enable elimination
  of the module thereby simplifying significantly the overall
  scope of the specifications and should be addressed prior
  to finalisation.

see below

The definition of a Link (a relationship declaration) under
Task and Session formal/00-05-03 is in the form of a struct
containing an object reference and relationship type identifier.
These identifiers are declared as constants within the Session
module. This change to Task and Session between bom/98-07-05
and the current formal/00-05-03 specification effectively breaks
the Negotiation model of relationship extension. Restoration of
module independent extension of Links is possible if the current
Link declaration is replaced with an extendable valuetype
definition

see below

Negotiation FTF, CollaborationFramework module.
The definition of Encounter combines the notion of a
Membership and rules relating to member association
with rules relating to process execution (e.g. derived
Collaboration interface). In the case of Collaboration
the current inheritance model eliminates the possibility
for independent declaration of process focuses role
models as distinct from the roles attributed to different
members of a membership. While the object model
expressing roles from the two different perspectives
are equivalent at an interface level, the instance
values and lifecycles are independent. It is recommended
that the notion of Encounter be restricted to the
management of a set of members, sharing a common view
on a collaborative process execution. Moving the
collaboration process semantics out of the Encounter
inheritance hierarchy can be achieved by defining a
relationship between Encounter and the active process
that an Encounter is co-ordinating. Once the notion of
process is separated from the notion of membership, the
respective control models can coexist. Secondly, given
formal separation of Membership and process, the existing
usage relationships derived from the inherited
Task interface by Encounter can be used to manage the
subject of collaborative interaction - as such, the
subject relationship can be removed from Engagement,
Voting and Collaboration.

Resolution:

• introduced explicit definition of a processor as a
  base type for collaboration, associated to a Task by
  a declared relationship
• introduced explicit definition of a processor as a base
  type for Collaboration (as per Task Session notion of
  Task and processor)
• retract the association of a subject of a collaboration
  in favour of the existing usage relationships between
  a processor and a Task.

see below

MembershipKind combines both the policy of a Membership and
the policy of different business roles within a membership.
These notions should be separated into independent control
objects.

Resolution:

Resolution of this issue is proposed under EC/2000-10-02,
Part 2, involving the separation of membership and role
policy into distinct types.

see below

The Member type represents an association of a User to a
Membership, as such it should be re-defined as a type
of Link. The current specification is currently broken
and must be recast against an extendable Link model.

Resoliution:

Resolution of this issue is proposed under EC/2000-10-02,
Part 2, in conjunction with resolution of issues defined under
EC/2000-10-01.

see below

Membership is currently defined as a type of
AbstractResource. In addition two derived types (Community
and Encounter) also inherit from AbstractResource.
Elimination of this conflict can be achieved by declaring
Membership as an abstract interface.

No Data Available

The description of Membership, Member and MembershipKind
presented in 99-07-03 is overly complex and should be
re-written (simplification and clarification) taking into
account underlying revisions to the Task and Session
specification formal/2000-05-02.

No Data Available

There are several occurrences within the Negotiation and
Task and Session specification of exception, enumeration and
struct declarations that are defined with the scope of object
interfaces. This approach complicates access to these type
declarations from the Negotiation Community and Collaboration
modules. leading to potential type duplication.

see below

The revised Task and Session specification of BaseBusinessObject
includes inheritance of the CosNotifyComm StructuredPushConsumer
and StructuredPushSupplier interfaces. The semantics of
StructuredPushSupplier implies association to a single
StructuredProxyPushConsumer, however, the BaseBusinessObject
interface is intended to support multiple concurrent consumers from
potentially different business domains without mandating nor
excluding the use of Notification channels as an implementation
mechanisms. To enable the documented behaviour an explicit factory
operation is required through which a StructuredPushSupplier
reference can be exposed for a given consumer. This behaviour is
required to support association of multiple consumers under the
Community and Collaboration interfaces. Current inherited behaviour
restricts association of event channels to local implementations
which inconsistent with the stated semantics.

see below

Problem: Under the Community::Membership interface there are operations to add members to a membership under a specific business role. There are also operations supporting the removal of a business role of an existing member. The approach to the addition of a supplementary business roles is through the operation add_kind_of_member, however, this is ambiguous when the exclusivity policy is set to false (as the client may be adding a Member instance as a new member or adding a MemberKind to an existing Member). Propose elimination of the inconsistency by restricting the semantics of add_kind_of_member to new Member instance creation, and supplementing the Membership interface with an additional operation add_kind for attribution of MemberKind roles to an existing Member instance.

No Data Available