Issues for Negotiation Facility FTF mailing list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 3461: Page 25: Return type on lookup operation should be BaseElement
Issue 3462: Page 27, control attribute table, label row, purpose column
Issue 3463: Page 27, sec 2.2.6
Issue 3464: model_element property not shown in IDL
Issue 3465: Page 34, first paragraph, second sentence. Please provide an example of th
Issue 3466: Page 34, sec 2.4.2., first paragraph: "set_simulator
Issue 3467: Page 34, sec 2.4.2
Issue 3468: Page 36, sec 2.5.1: the terminilogy for containment does not align with UML
Issue 3469: Page 43, sec 3.1.1
Issue 3470: Page 44, table at the top of page
Issue 3471: Page 44 sec 3.1.4, 3rd sentence
Issue 3472: Page 45, last full paragraph
Issue 3473: Page 47, UML diagram
Issue 3474: Page 55, first full paragraph, last sentence
Issue 3475: Page 60, IDL for interface Member
Issue 3476: Page 71, processed_by and processes relationships
Issue 3477: Page 75, UML diagram
Issue 3478: Page 76: Not clear what is implied
Issue 3479: Page 76: Not clear what is implied
Issue 3480: Page 79, IDL for EncounterFactory
Issue 3481: Page 80, 1st paragraph, last sentence
Issue 3482: Page 81
Issue 3483: Page 82, 1st table, properites row, purpose column
Issue 3484: Page 82, IDL for Engagement
Issue 3485: Page 84, first table
Issue 3486: Page 85, sec 4.4.3, first paragraph: Shouldn't VoteModel be VoteElement?
Issue 3487: Page 86, sec 4.5.1
Issue 3488: Page 87, 4th paragraph
Issue 3489: Page 87, 5th paragraph, second sentence
Issue 3490: Page 87, 5th paragraph, third sentence
Issue 3491: Page 87, 6th paragraph, 2nd sentence
Issue 3492: Page 87, 6th paragraph, 2nd sentence
Issue 3493: Page 88, 1st full sentence
Issue 3494: Wha tis a root CollaborationElement?
Issue 3495: Page 89, 1st paragraph, 3rd sentence
Issue 3496: Page 89, 1st paragraph, 4th sentence
Issue 3497: Page 89, 3rd paragraph references CollaborationModel
Issue 3498: Page 90, 1st paragraph, 2nd sentence
Issue 3499: Page 90, 3rd pagragraph, 1st sentence
Issue 3500: Page 93, IDL for Collaboration
Issue 3501: Page 94, IDL for the active_state attribute
Issue 3502: Page 96, sec 4.5.4
Issue 3503: Page 97, table at top of page
Issue 3504: Page 100, 1st paragraph, last sentence
Issue 3505: Page 104
Issue 3506: Page 104, last paragraph, last sentence
Issue 3507: Page 105, 1st paragraph, last sentence
Issue 3508: Page 106, 1st table, first row
Issue 3509: Page 106, 1st table, first row
Issue 3510: Page 107, last paragraph, 2nd sentence
Issue 3511: Page 108, 1st table
Issue 3580: Cannot attribute an additional MemberKind to an exiting Member
Issue 3950: Multiple Consumer association to Community and Collaboration types
Issue 3951: Accessibility of external definitions
Issue 3952: Link definition is broken
Issue 3956: Community and Collaboration models severely broken.
Issue 3957: Improvement needed on Membership textual description.
Issue 3958: Duplicate inheritance in Membership interface
Issue 3959: Improvement needed on Membership textual description.
Issue 3960: Separation of Membership versus Role policy required.
Issue 3980: Separation of Collaboration from Encounter inheritance.

Issue 3461: Page 25: Return type on lookup operation should be BaseElement (negotiation-ftf)

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

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 27, sec 2.2.6: I would have expected mention that AbstractResource
pulls in the CosNotifycomm interfaces and the identifiableobject interface.

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

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

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

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 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 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 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 44 sec 3.1.4, 3rd sentence: Are these model elements something other
than instances of the type ModelElement?

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

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

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

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 76: Not clear what is implied by the fact that one Encounter composes
another.

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

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

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 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 82, 1st table, properites row, purpose column: What security
technology adoption processes is this referring to?

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 84, first table: Shouldn't the title of the table say VoteElement
rather than VoteTemplate?

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

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 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 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, 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, 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, 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, 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 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 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 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, 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 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 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 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 94, IDL for the active_state attribute: The type of this attribute is
not StateSequence.  It should be, I believe, Document::KeywordSequence.

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

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

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 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 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 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 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 108, 1st table: An Initialization is not a trigger so it doesn't have
a priority, so why is there a priority column?

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.

Additional operations provided to support association and retraction of business roles.
Existing operations renamed to improve clarity. Specification of Membership operations
have been substantially updated – refer section 3 and 4 of CommunityFramework,
EC/2000-11-14.

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.

Resolution:

	Revise the definition of BaseBusienssObject such that an
	identifiable structured push consumer is passed as an argument,
	returning a structured push supplier as opposed to the current
	inheritance based exposure a structured event management.

	The following IDL is recommended as a replacement to the definition of
	BaseBusienssObject:

	interface IdentifiableDomainConsumer :
		Session::IdentifiableDomainObject,
		CosNotifyComm::StructuredPushConsumer
		{
	};

	valuetype Timestamp TimeBase::UtcT ;

	interface BaseBusinessObject :
		Session::IdentifiableDomainObject,
		CosLifeCycle::LifeCycleObject
		{
		CosNotifyComm::StructuredPushSupplier add_consumer(
			in IdentifiableDomainConsumer consumer
		);
		Timestamp creation( );
		Timestamp modification( );
		Timestamp access( );
	};
Revised Text:

        Refer to http://www.osm.net/upload/omg-2000-10-15.pdf, section
        1.2 "BaseBusienssObject Revision".
CommunityFramework specification has been updated to include the required
modification of the Task and Session specification of the definition of BaseBusinessObject to
the following IDL:

 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.

Resolution:

	  Resolution of the problem can be achieved by moving
	  the respective declarations from interface to module level in
	  the Session module and Negotiation modules for Community and
	  Collaboration.

Revised Text:

        Refer to http://www.osm.net/upload/omg-2000-10-15.pdf, section
        1.4 "Declaration in Module versus Interface scope".

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

Resolution:

        Retract constant LinkKind declarations and replace Link struct
        with a valuetype and set of derived valuetypes. Proposed IDL
        replacement detailed below:

        valuetype BooleanValue boolean;

        valuetype Link
              {
              public AbstractResource resource;
              public BooleanValue primary;
        };

        valuetype Usage : truncatable Link
              {
              public CORBA::StringValue tag;
        };

        valuetype Consumption : truncatable Usage { };
        valuetype Production : truncatable Usage { };
        valuetype Collection : truncatable Link { };
        valuetype Containment : truncatable Collection { };
        valuetype Rights : truncatable Link { };
        valuetype Access : truncatable Rights { };
        valuetype Administration : truncatable Access { };
        valuetype Execution : truncatable Rights { };
        valuetype Ownership : truncatable Rights { };
Revised Text:

        Refer to http://www.osm.net/upload/omg-2000-10-15.pdf, section
        1.3 "Link Revision".Detailed editorial and IDL changes are included under section 9 “Changes to the adopted
Task and Session Specification” of the finalized CommunityFramework specification under
document number EC/2000-11-14.

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.

Resolution:

	A recommended revision incorporating rationalisation of all 
	CommunityFramerwork interfaces, incorporating rationalisation
	of underlying Task and Session specification is proposed under 
	document number EC/2000-10-02 (supporting UML under 
	EC/2000-10-03.

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.

Resolution:

	A recommended revision to the textual description of Membership 
	and related interfaces is proposed under EC/2000-10-02, Part 2.

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.

Resolution:

	A recommended revision to the Membership interface is 
	proposed under EC/2000-10-02, Part 2. The revision involves
	retraction of inheritance of AbstractResource and declaration of 
	the interface as abstract.

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.

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.

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.