Negotiation Facility Avatar
  1. OMG Specification

Negotiation Facility — Open Issues

  • Acronym: NEG
  • Issues Count: 51
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
NEG-61 Page 106, 1st table, first row NEG 1.0b1 open
NEG-60 Page 87, 6th paragraph, 2nd sentence NEG 1.0b1 open
NEG-59 Page 76: Not clear what is implied NEG 1.0b1 open
NEG-48 Page 108, 1st table NEG 1.0b1 open
NEG-47 Page 107, last paragraph, 2nd sentence NEG 1.0b1 open
NEG-46 Page 106, 1st table, first row NEG 1.0b1 open
NEG-45 Page 105, 1st paragraph, last sentence NEG 1.0b1 open
NEG-44 Page 104, last paragraph, last sentence NEG 1.0b1 open
NEG-43 Page 104 NEG 1.0b1 open
NEG-42 Page 100, 1st paragraph, last sentence NEG 1.0b1 open
NEG-41 Page 97, table at top of page NEG 1.0b1 open
NEG-40 Page 96, sec 4.5.4 NEG 1.0b1 open
NEG-39 Page 94, IDL for the active_state attribute NEG 1.0b1 open
NEG-38 Page 93, IDL for Collaboration NEG 1.0b1 open
NEG-37 Page 90, 3rd pagragraph, 1st sentence NEG 1.0b1 open
NEG-36 Page 90, 1st paragraph, 2nd sentence NEG 1.0b1 open
NEG-35 Page 89, 3rd paragraph references CollaborationModel NEG 1.0b1 open
NEG-34 Page 89, 1st paragraph, 4th sentence NEG 1.0b1 open
NEG-33 Page 89, 1st paragraph, 3rd sentence NEG 1.0b1 open
NEG-32 Wha tis a root CollaborationElement? NEG 1.0b1 open
NEG-31 Page 88, 1st full sentence NEG 1.0b1 open
NEG-30 Page 87, 6th paragraph, 2nd sentence NEG 1.0b1 open
NEG-29 Page 87, 5th paragraph, third sentence NEG 1.0b1 open
NEG-28 Page 87, 5th paragraph, second sentence NEG 1.0b1 open
NEG-27 Page 87, 4th paragraph NEG 1.0b1 open
NEG-26 Page 86, sec 4.5.1 NEG 1.0b1 open
NEG-25 Page 85, sec 4.4.3, first paragraph: Shouldn't VoteModel be VoteElement? NEG 1.0b1 open
NEG-24 Page 84, first table NEG 1.0b1 open
NEG-23 Page 82, IDL for Engagement NEG 1.0b1 open
NEG-22 Page 82, 1st table, properites row, purpose column NEG 1.0b1 open
NEG-21 Page 81 NEG 1.0b1 open
NEG-20 Page 80, 1st paragraph, last sentence NEG 1.0b1 open
NEG-19 Page 79, IDL for EncounterFactory NEG 1.0b1 open
NEG-18 Page 76: Not clear what is implied NEG 1.0b1 open
NEG-17 Page 75, UML diagram NEG 1.0b1 open
NEG-16 Page 71, processed_by and processes relationships NEG 1.0b1 open
NEG-15 Page 60, IDL for interface Member NEG 1.0b1 open
NEG-14 Page 55, first full paragraph, last sentence NEG 1.0b1 open
NEG-13 Page 47, UML diagram NEG 1.0b1 open
NEG-12 Page 45, last full paragraph NEG 1.0b1 open
NEG-11 Page 44 sec 3.1.4, 3rd sentence NEG 1.0b1 open
NEG-10 Page 44, table at the top of page NEG 1.0b1 open
NEG-9 Page 43, sec 3.1.1 NEG 1.0b1 open
NEG-8 Page 36, sec 2.5.1: the terminilogy for containment does not align with UML NEG 1.0b1 open
NEG-7 Page 34, sec 2.4.2 NEG 1.0b1 open
NEG-6 Page 34, sec 2.4.2., first paragraph: "set_simulator NEG 1.0b1 open
NEG-5 Page 34, first paragraph, second sentence. Please provide an example of th NEG 1.0b1 open
NEG-4 model_element property not shown in IDL NEG 1.0b1 open
NEG-3 Page 27, sec 2.2.6 NEG 1.0b1 open
NEG-2 Page 27, control attribute table, label row, purpose column NEG 1.0b1 open
NEG-1 Page 25: Return type on lookup operation should be BaseElement NEG 1.0b1 open

Issues Descriptions

Page 106, 1st table, first row

  • Key: NEG-61
  • Legacy Issue Number: 3509
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Page 87, 6th paragraph, 2nd sentence

  • Key: NEG-60
  • Legacy Issue Number: 3492
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Page 76: Not clear what is implied

  • Key: NEG-59
  • Legacy Issue Number: 3479
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

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

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Page 108, 1st table

  • Key: NEG-48
  • Legacy Issue Number: 3511
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

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

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 107, last paragraph, 2nd sentence

  • Key: NEG-47
  • Legacy Issue Number: 3510
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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?

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 106, 1st table, first row

  • Key: NEG-46
  • Legacy Issue Number: 3508
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 105, 1st paragraph, last sentence

  • Key: NEG-45
  • Legacy Issue Number: 3507
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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?

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 104, last paragraph, last sentence

  • Key: NEG-44
  • Legacy Issue Number: 3506
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 104

  • Key: NEG-43
  • Legacy Issue Number: 3505
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

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

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 100, 1st paragraph, last sentence

  • Key: NEG-42
  • Legacy Issue Number: 3504
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 97, table at top of page

  • Key: NEG-41
  • Legacy Issue Number: 3503
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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?

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 96, sec 4.5.4

  • Key: NEG-40
  • Legacy Issue Number: 3502
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

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

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 94, IDL for the active_state attribute

  • Key: NEG-39
  • Legacy Issue Number: 3501
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

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

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 93, IDL for Collaboration

  • Key: NEG-38
  • Legacy Issue Number: 3500
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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!

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 90, 3rd pagragraph, 1st sentence

  • Key: NEG-37
  • Legacy Issue Number: 3499
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 90, 1st paragraph, 2nd sentence

  • Key: NEG-36
  • Legacy Issue Number: 3498
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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?

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 89, 3rd paragraph references CollaborationModel

  • Key: NEG-35
  • Legacy Issue Number: 3497
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 89, 1st paragraph, 4th sentence

  • Key: NEG-34
  • Legacy Issue Number: 3496
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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?

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 89, 1st paragraph, 3rd sentence

  • Key: NEG-33
  • Legacy Issue Number: 3495
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wha tis a root CollaborationElement?

  • Key: NEG-32
  • Legacy Issue Number: 3494
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 88, 1st full sentence

  • Key: NEG-31
  • Legacy Issue Number: 3493
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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?

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 87, 6th paragraph, 2nd sentence

  • Key: NEG-30
  • Legacy Issue Number: 3491
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 87, 5th paragraph, third sentence

  • Key: NEG-29
  • Legacy Issue Number: 3490
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 87, 5th paragraph, second sentence

  • Key: NEG-28
  • Legacy Issue Number: 3489
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 87, 4th paragraph

  • Key: NEG-27
  • Legacy Issue Number: 3488
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 86, sec 4.5.1

  • Key: NEG-26
  • Legacy Issue Number: 3487
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

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

  • Key: NEG-25
  • Legacy Issue Number: 3486
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

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

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 84, first table

  • Key: NEG-24
  • Legacy Issue Number: 3485
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

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

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 82, IDL for Engagement

  • Key: NEG-23
  • Legacy Issue Number: 3484
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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?

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 82, 1st table, properites row, purpose column

  • Key: NEG-22
  • Legacy Issue Number: 3483
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

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

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 81

  • Key: NEG-21
  • Legacy Issue Number: 3482
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 80, 1st paragraph, last sentence

  • Key: NEG-20
  • Legacy Issue Number: 3481
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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?

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 79, IDL for EncounterFactory

  • Key: NEG-19
  • Legacy Issue Number: 3480
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

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

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 76: Not clear what is implied

  • Key: NEG-18
  • Legacy Issue Number: 3478
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

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

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 75, UML diagram

  • Key: NEG-17
  • Legacy Issue Number: 3477
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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?

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 71, processed_by and processes relationships

  • Key: NEG-16
  • Legacy Issue Number: 3476
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

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

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 60, IDL for interface Member

  • Key: NEG-15
  • Legacy Issue Number: 3475
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 55, first full paragraph, last sentence

  • Key: NEG-14
  • Legacy Issue Number: 3474
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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?

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 47, UML diagram

  • Key: NEG-13
  • Legacy Issue Number: 3473
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

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

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 45, last full paragraph

  • Key: NEG-12
  • Legacy Issue Number: 3472
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

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

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 44 sec 3.1.4, 3rd sentence

  • Key: NEG-11
  • Legacy Issue Number: 3471
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

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

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 44, table at the top of page

  • Key: NEG-10
  • Legacy Issue Number: 3470
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 43, sec 3.1.1

  • Key: NEG-9
  • Legacy Issue Number: 3469
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 36, sec 2.5.1: the terminilogy for containment does not align with UML

  • Key: NEG-8
  • Legacy Issue Number: 3468
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 34, sec 2.4.2

  • Key: NEG-7
  • Legacy Issue Number: 3467
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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?

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 34, sec 2.4.2., first paragraph: "set_simulator

  • Key: NEG-6
  • Legacy Issue Number: 3466
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

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

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

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

  • Key: NEG-5
  • Legacy Issue Number: 3465
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

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

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

model_element property not shown in IDL

  • Key: NEG-4
  • Legacy Issue Number: 3464
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

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

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 27, sec 2.2.6

  • Key: NEG-3
  • Legacy Issue Number: 3463
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

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

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 27, control attribute table, label row, purpose column

  • Key: NEG-2
  • Legacy Issue Number: 3462
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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.

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 25: Return type on lookup operation should be BaseElement

  • Key: NEG-1
  • Legacy Issue Number: 3461
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

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

  • Reported: NEG 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT