If I understand correctly, you are asking for the addition of two
exceptions to CosGraphs::Node::add_role().
1. The exception DuplicateRole shall be thrown when add_role() is
invoked to add a Role of the "same type" as an existing Role of the same
Node, WHERE the Role is constrained to be uniquely assumed by that Node
by constraints provided to the CosGraphs implementation. "same type"
means:
- a Role with the same interface type,
- a Role whose interface type is a supertype of the given role, or
- a Role whose interface type is a subtype of the given Role.
(Technically that would have to be stated in terms of the CORBA::is_a
operation.)
2. The exception InappropriateRole shall be thrown when add_role() is
invoked to add a Role to a Node that is not an admissible Role for that
Node per some constraints provided to the CosGraphs implementation.
And you are asking for the further statements in the PDM Enablers that
3. All PDM Enablers Roles shall be uniquely assumed.
4. The PDM Enablers relationship definitions shall be interpreted as
specifying the complete set of Role types that may be assumed by a PDM
Enablers interface that inherits from Node.
Is this the correct interpretation of your issues? If not, can you make
clear exactly what you want to change in CosGraphs and PDM Enablers?
Notes:
1. Making these changes to Node::add_role() would require changing
CosGraphs first, and then the PDM Enablers. These are separate OMG
standards (maintained by different Task Forces and TCs) and two separate
"revision activities" would be required. At the moment, there is no
active RTF for CosRelationships (including CosGraphs), and we would have
to create such an activity first. (There is an active RTF for PDM
Enablers, and Lutz Lämmer and I chair it.)
2. CosGraphs itself does not require either of these "constrained
interpretations", and it is not clear that it provides any means of
stating the constraints that would be used to throw the exceptions. I
don't think that one necessarily has to provide the means in order to
provide the exception. Things like PDME that inherit from CosGraphs
interfaces can provide the means.
3. We do have to distinguish between the "cardinality of Role
assumption" and the "cardinality of Relationship participation". That
is, if a PartMaster can have many PartRevisions and thus many
PartMasterComposition relationships, does the PartMaster as Node have
- one PartMastertoPartRevision Role for each PartMasterComposition
relationship in which it participates (so that the Role object is unique
to the Relationship object), or
- one PartMastertoPartRevision Role for all PartMasterComposition
relationships in which it participates (so that the Role object is
unique to the Node object)?
In the general case, where a Role object may have its own attributes and
operations, either of these is possible, but they reflect different
semantics for the attributes/operations of the Role. So CosGraphs
itself should not require either behavior exclusively. In the
particular case of the PDM Enablers, no Role object is defined to have
additional attributes and operations, so the choice is arbitrary, and we
may want to impose a standard convention. However, a PDM Enablers
implementation may need to impose additional internal attributes and
operations on its internal representation of the Role objects, and for
that implementation the choice is no longer arbitrary. Thus it is
necessary for all implementors to agree on a particular standard
convention. I take it that UG would like to standardize the second
convention above. Does anyone take issue with this?
