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)
Click here for this issue's archive.
Source: SAP AG (Mr. David Frankel, david.frankel@sap.com)
Nature: Uncategorized Issue
Severity:
Summary:
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
definitionResolution:
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.