Issue 3465: Page 34, first paragraph, second sentence. Please provide an example of th (negotiation-ftf) Source: (Mr. David Frankel, dsfrankel(at)yahoo.com) Nature: Uncategorized Issue Severity: Summary: Page 34, first paragraph, second sentence. Please provide an example of this. Resolution: Revised Text: Actions taken: March 15, 2000: receive dissue Discussion: End of Annotations:===== Date: Wed, 15 Mar 2000 10:43:53 -0800 From: David Frankel Subject: Issues for latest version of negotiation facility X-Sender: dfrankel@gendev.vwh.net To: negotiation@omg.org, mcconnell@osm.net Message-id: Message-id: MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: @UUd9HQ7e9Y;9e9\Ljd9 All-- The revised Negotiation Facility document dtc/2000-02-06 that the FTF created is quite a bit more understandable than the original one. Here are issues with that document I would like to post as FTF issues. Please keep in mind that, where my comments take the form of a question, it is an indication that something wasn't evident or clear in the document and that the document should be ammended to provide the necessary clarification: == PROOFREAD IT. There are too many blatant grammatical errors, missing words, etc. and other errors that suggest that the document wasn't really proofread. 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 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 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 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? ============================= David S. Frankel Chief Scientist Genesis Development Corporation 741 Santiago Court Chico, CA 95973-8781 U.S.A. http://www.gendev.com dfrankel@gendev.com +1-530-893-1100 phone +1-530-893-1153 fax =============================