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.

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 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 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 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 71, processed_by and processes relationships: There should be a note
that these relationships are defined in the Task & Session specification.

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 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 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 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 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 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 79, IDL for EncounterFactory: What happens to the inherited create_xx
operations? Are they deprecated for the subtype (not good if so)?

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 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 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 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 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 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 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 34, sec 2.4.2., first paragraph: "set_simulator" should be
"add_simulator".

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

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

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

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 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 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 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 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 104: A local Transition with reset = false and active = false would
seem to be a corner case that should be ruled out.

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 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 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 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 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.