Relationship Service Avatar
  1. OMG Specification

Relationship Service — Open Issues

  • Acronym: REL
  • Issues Count: 7
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

OMG Document formal/00-06-24

  • Key: REL-7
  • Legacy Issue Number: 6288
  • Status: open  
  • Source: Anonymous
  • Summary:

    I have found that a major flaw with the Relationship Service Spec is that it doesn't recognize the semantics of the relationships
    and therefore, doesn't enable the management of the relationship data, which cannot exist independently of the object data.

    Please forward my proposed remedy, available at the following link, to the contributors
    http://www.geocities.com/unifiedmodel/ManagingRelationships.htm

  • Reported: REL 1.0b1 — Tue, 30 Sep 2003 04:00 GMT
  • Updated: Sat, 7 Mar 2015 05:58 GMT

Purpose of Relationship Handle

  • Key: REL-6
  • Legacy Issue Number: 15
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: RelationshipHandle seems to have no purpose, unless it is being used for lazy instantiation of the Relationship.

  • Reported: REL 1.0b1 — Tue, 21 May 1996 04:00 GMT
  • Updated: Sat, 7 Mar 2015 05:57 GMT

OMG Document formal/98-10-35 (CosRelationships::RelationshipFactory::create

  • Key: REL-5
  • Legacy Issue Number: 5335
  • Status: open  
  • Source: Anonymous
  • Summary:

    The declaration of CosRelationships::RelationshipFactory::create does not
    mention the DuplicateRoleName exception in its raises clause. The
    specification (formal/00-06-24) states that Role names must be unique within
    each relationship type. Is this an error in the IDL?

  • Reported: REL 1.0b1 — Thu, 6 Jun 2002 04:00 GMT
  • Updated: Sat, 7 Mar 2015 05:56 GMT

9/Relationship Service specification

  • Key: REL-4
  • Legacy Issue Number: 2972
  • Status: open  
  • Source: Anonymous
  • Summary:

    CosGraphs::Node interface provides a function add_role() which helps in adding a new role to the related
    object the Node is representing. The specifications suggests to raise an exception DuplicateRoleType
    if the new role is same, subtype, supertype of one of the role of the Node object.

    What if the user of function calls add_role() with a role for an object which is not represented by this node.
    Definitely we cannot add the new role to the Node. Only thing we can do here is return out of function.
    But user will not be aware that the function has failed, since the return type is void.

  • Reported: REL 1.0b1 — Fri, 29 Oct 1999 04:00 GMT
  • Updated: Sat, 7 Mar 2015 05:56 GMT

DuplicateRoleName in CosRelationships (formal/97-11-02)

  • Key: REL-3
  • Legacy Issue Number: 887
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: DuplicateRoleName exception is defined in CosRelationships but is left out in the declaration of the create()
    method of the RelationshipFactory interface !!!!
    In the spec for the Relationships Services, DuplicateRoleName is thrown in the create() method of the
    relationships factory.
    Is this a typo, an error, a modification or what ????
    Where do we report these things?

  • Reported: REL 1.0b1 — Thu, 8 Jan 1998 05:00 GMT
  • Updated: Sat, 7 Mar 2015 05:56 GMT

Definition (9-35) CosGraphs

  • Key: REL-2
  • Legacy Issue Number: 467
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: If Role requires the Related Object to be a Node (e.g. CocContainment), must Node return itself as related_object attribute or can there be a different related Object

  • Reported: REL 1.0b1 — Fri, 3 Jan 1997 05:00 GMT
  • Updated: Sat, 7 Mar 2015 05:56 GMT

CosGraphs interfaces and immutable objects

  • Key: REL-1
  • Legacy Issue Number: 49
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: CosGraphs::Role cannot obtain a knowledge of its node. Therefore, CosGraphs::Role::get_edges() cannot be fully supported, nor can the Traversal interface.

  • Reported: REL 1.0b1 — Sun, 7 Jul 1996 04:00 GMT
  • Updated: Sat, 7 Mar 2015 05:56 GMT