Page 106, 1st table, first row: I would think that the type needs to be
more specific, i.e. it should be EncounterModel rather than Model, because
EncounterFactory::create_with_model requires an EncounterModel as input.

Page 87, 6th paragraph, 2nd sentence reads: "These relationships include
the subject and model." Should point out that the subject relationship is
inherited from Encounter.

Page 76: Not clear what is implied by the fact that one Encounter composes
another.

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

Page 108, 1st table: An Initialization is not a trigger so it doesn't have
a priority, so why is there a priority column?

Page 107, last paragraph, 2nd sentence reads: "An offer signifies a state
in which the subject of collaboration may be agreed to but not be
changed..." Then why is active TRUE?

Page 106, 1st table, first row: I would think that the type needs to be
more specific, i.e. it should be EncounterModel rather than Model, because
EncounterFactory::create_with_model requires an EncounterModel as input.

Page 105, 1st paragraph, last sentence reads: "The determination of the
action to invoke is resolved through evaluation of a ResultState raised by
an Encounter defined by the model attribute." Is the Encounter retrieved
by Model's list_simulators operation? If so, what if there is more than
one simulator?

Page 104, last paragraph, last sentence reads: "Referral is created by an
ElementFactory using the element name "referral". The specification of the
element name for factories is uneven in this spec. For some types it is
specified and for some it is not. It should be done uniformly, and a
summary table of these values for the various types would be helpful.

Page 87, 5th paragraph, third sentence reads: "Each instance of
Collaboration references an EncounterModel through which user's (sic!) can
access a root CollaborationElement." This should point out that the
reference to an EncounterModel is inherited from Simulator.

Page 87, 5th paragraph, second sentence reads: "An instance of
Collaboration exposes the operations through which a user may join,
interact and leave the process." This should point out that these
operations are inherited from Membership.

Page 82, IDL for Engagement: Is the manifest property null before engage is
called? Also, how do we know if engage succeeded, since there are no
exceptions raised? Do we know by virtue of the out param 'proof' being null?
Page 83, UML diagram: Should VoteModel be VoteElement?

Page 82, 1st table, properites row, purpose column: What security
technology adoption processes is this referring to?

Page 81: The pattern seems to be that types whose name ends with Element,
such as MembershipElement and EngagementElement, encapsulate policies.
Thus, why are these named xxElement rather than xxPolicy? If find it
confusing.

Page 80, 1st paragraph, last sentence reads: "The determination of the type
of Encounter to create shall be based on the type of root element exposed
by the model." Is the root element obtained via the list_simulators
operation?

Page 87, 4th paragraph: The paragraph starts with "The features exposed by
the inherited interface MembershipElement...". Inherted by what? In fact,
the paragraph as a whole is not clear.

Page 86, sec 4.5.1: This Overview section should come at the end of section
4.5, i.e. after the basics have been defined. Otherwise it is not
comprehensible. Also, I cannot parse item (b) in the 1st paragraph.

Page 88, 1st full sentence reads: "An EncounterModel accessible through the
simulates association..." Is this the simulator association on p. 33 or
the simulates LinkKind on p. 38?

Page 87, 6th paragraph, 2nd sentence reads: "These relationships include
the subject and model." Should point out that the subject relationship is
inherited from Encounter.

Page 88 and 89: The text refers to a "root CollaborationElement". What is
a root CollaborationElement? Root of what?
Page 88, 4th full paragraph, 1st sentence reads: "On invocation of the
apply operation, the implementation of Collaboration executes the
verification of the principal as a registered Member of the
Collaboration..." How does the Collaboration implementation determine the
MemberKind of the caller of the apply operation and whether it is an
initiator or responder with respect to the active state? Via
CORBA::Current? This must be explained in detail.

Page 76: Not clear what is implied by the fact that one Encounter composes
another.

Page 75, UML diagram: Based on this diagram I would conclude that a Model
associated with an Encounter must be an EncounterModel. Is this correct?

Page 85, sec 4.4.3, first paragraph: Shouldn't VoteModel be VoteElement?

Page 84, first table: Shouldn't the title of the table say VoteElement
rather than VoteTemplate?

Page 79, IDL for EncounterFactory: What happens to the inherited create_xx
operations? Are they deprecated for the subtype (not good if so)?

Page 36, sec 2.5.1: the terminilogy for containment does not align with
UML, which would be a good idea to do and to explicitly say that you are
doing. Weak aggregationi in UML is "shared" aggregation, which doesn't
simply mean that there is no lifecycle dependency. Weak aggregation is not
the same as no aggregation. Weak aggregation means that an aggregee
instance can be aggregated by more than one aggregate at the same time, and
that the aggregee doesn't go away until the last owning aggregate goes
away. That's why it's called "shared" aggregation. Containment is not a
formally specified notion in UML, and composition is strong aggregation.
So the three possibilities for aggregation semantics are:
1) no aggregation
2) shared (weak) aggregation
3) composite (strong) aggregation

Page 34, sec 2.4.2: Is an implementation of add_simulator responsible for
calling set_model? Can you dissociate a model from a simulator?

Page 44, table at the top of page: Re Membership: the description says
that the rules are exposed by MembershipElement but I can't find anything
in the object model or IDL that allows me to navigate to the
MembershipElement, i.e. to navigate to an instance of MembershipElement in
order to extract these rule properties.

Page 43, sec 3.1.1: It is odd to entitle this section Model Abstraction,
since the Model type is defined in the previous chapter.

Page 71, processed_by and processes relationships: There should be a note
that these relationships are defined in the Task & Session specification.

Page 60, IDL for interface Member: In the inheritance list there is a
comment after the listing of the inherited Session::User interface that
says "// by delegation". This does not make sense. This is interface
inheritance, so the User is not a separate instance.

Page 55, first full paragraph, last sentence reads: "This operation is
equivalent to the add_member operation except that it takes the name of a
MemberKind as a qualifying argument." Is this name the 'identifier'
inherited from BaseElement or the 'label' inherited from Control?

Page 47, UML diagram: MemberKind is a strange name for this collection of
properties.

Page 45, last full paragraph: I just can't see where a MembershipElement is
associated with a Membership or vice versa.

Page 44 sec 3.1.4, 3rd sentence: Are these model elements something other
than instances of the type ModelElement?

Page 33: The UML diagram shows that Model has a model_element property, but
I don't see that in the IDL.

Page 27, sec 2.2.6: I would have expected mention that AbstractResource
pulls in the CosNotifycomm interfaces and the identifiableobject interface.

Page 34, sec 2.4.2., first paragraph: "set_simulator" should be
"add_simulator".

Page 34, first paragraph, second sentence. Please provide an example of this.

Page 27, control attribute table, label row, purpose column: The label is
described as the unique identifier, yet Control inherits from BaseElement,
whose identifier attribute seems to do this already.

Page 25: Return type on lookup operation should be BaseElement (this is
correct in the complete IDL).

Page 93, IDL for Collaboration: The attribute timeout_list is actually not
a list but, rather, a single instance of the struct TimeoutSequence. The
text on page 94 refers to this as a sequence of TimeoutStructure values,
but it's not. Furthermore, the struct TimeoutSequence IDL is repeated at
the bottom of page 94 and it is different there, and has a member of type
ControlKey which is not a defined type!

Page 90, 3rd pagragraph, 1st sentence reads: "It is important to note that
the bilateral negotiation state transition model is simply an example of a
collaborative process model." I doubt it is your intention, but this could
be interpreted as backing away from requiring, as a conformance point,
support of the bilateral model.
Page 90 and others: The state charts are somewhat non-standard. The box
with the triangular end for a state transition is not standard UML as far
as I know.

Page 100, 1st paragraph, last sentence reads: "In such a case, the invoking
user must be a Member holding the MemberKind referenced by the constraint."
I presume its MemberKind could be one of the subsidiary MemberKinds of the
MemberKind referenced by the constraint.

Page 97, table at top of page, title reads: "The following table summarizes
the types contained by the CollaborationModel Type. Does this include the
state seq inherited from state?

Page 89, 1st paragraph, 4th sentence reads: "Implications are associations
that reference other EncounterTemplate instances..." I believe this should
be "that reference other EncounterModels" shouldn't it?

Page 89, 1st paragraph, 3rd sentence reads: "Prior to completion of the
process the Collaboration evaluates any implication associations declared
under a launching template." Does this mean an EncounterModel with
implications? If so, this would be a model, not a template.

Page 90, 1st paragraph, 2nd sentence reads: "Assuming the purchase
transition initialization argument referenced the requested transition..."
Referenced it by what means? Via what attributes in the IDL?

Page 89, 3rd paragraph references CollaborationModel, but there is no such
type defined in the IDL. In fact, this type is referenced many places in
the text, but never in the IDL.

Page 96, sec 4.5.4: I don't see how the CollaborationElement and
Collaboration are associated. What's the traversal path?

Page 94, IDL for the active_state attribute: The type of this attribute is
not StateSequence. It should be, I believe, Document::KeywordSequence.

Page 104: A local Transition with reset = false and active = false would
seem to be a corner case that should be ruled out.