The operation get_diamonds/0, CosEventDomainAdmin::EventDomain, seems to
be incorrectly described (page 2-10):

"The get_diamonds operation is invoked to retrieve a list of diamonds
that exist within any topology of channels formed by connections that were
established between these channels by the target domain. The operation
accepts no input parameters, and returns as a result a sequence of
diamonds, whereas each diamond is itself a sequence of member identifiers
of channels within the domain that are involved in the diamond."

The IDL-file contains the following the typedefs:
... CUT ...
typedef MemberIDSeq Route;
typedef sequence<Route> RouteSeq;

typedef Route Cycle;
typedef sequence<Cycle> CycleSeq;

typedef RouteSeq Diamond;
typedef sequence<Diamond> DiamondSeq;
.. CUT ..

The problem is:

"... each diamond is itself a sequence of member identifiers ..."

which contradicts:
...
typedef RouteSeq Diamond;
...

To solve this problem it should be sufficient to change the last sentence
to something like:

"The operation accepts no input parameters, and returns as a result a
sequence of diamonds, whereas each diamond is itself a sequence of paths,
each path being a sequence of channel member identifiers, that are
involved in the diamond

The idl for the DiamondCreationForbidden is as follows:

exception DiamondCreationForbidden

;

It should be

exception DiamondCreationForbidden

;

It seems to be a difference between the Management of Event Domains
spec and the module CosEventDomainAdmin IDL
http://www.omg.org/cgi-bin/doc?formal/2001-06-03

The interface CosEventDomainAdmin::EventDomain contains the operation
'add_connection', which raises, among others, the DiamondCreationForbidden
exception:
... CUT ...
ConnectionID add_connection (in Connection connection)
raises (CosNotifyChannelAdmin::ChannelNotFound,
CosEventChannelAdmin::TypeError,
AlreadyExists,
CycleCreationForbidden,
DiamondCreationForbidden);
... CUT ...

On page 2-9 it's described as follows:

"Likewise, if the DiamondDetection QoS property of the target event
domain is set to the value of ForbidDiamond, and the creation of the
requested connection would result in a diamond being created within the
topology of channels to which the connection is being added, then the
DiamondCreationForbidden exception is raised. This exception contains as
data a sequence of conflicting paths, each path being a sequence of
channel member identifiers."

The CosEventDomainAdmin::EventDomain interface also contains the operation
'get_diamonds':

... CUT ...
DiamondSeq get_diamonds();:
... CUT ..

On page 2-10:
"The get_diamonds operation is invoked to retrieve a list of diamonds
that exist within any topology of channels formed by connections that were
established between these channels by the target domain. The operation
accepts no input parameters, and returns as a result a sequence of
diamonds, whereas each diamond is itself a sequence of member identifiers
of channels within the domain that are involved in the diamond."

IMHO, the specification states that the return value from get_diamonds and
the in the DiamondCreationForbidden should be the same (i.e. a sequence of
diamonds, where each diamond is a sequence of Id:s).

But the IDL-file contains:

... CUT ...
typedef MemberIDSeq Route;
typedef sequence<Route> RouteSeq;

typedef Route Cycle;
typedef sequence<Cycle> CycleSeq;

typedef RouteSeq Diamond;
typedef sequence<Diamond> DiamondSeq;

exception CycleCreationForbidden

;

exception DiamondCreationForbidden

;
... CUT ...

In the above, a DiamondSeq is defined as a sequence of sequences of
Diamonds, which in turn is a sequence of ID:s.

The best solution would probably be to change parts of the above to:

... CUT ...
typedef Route Diamond;
... CUT ...
exception DiamondCreationForbidden

;
... CUT ...

This change makes the defintion of a CycleSeq and DiamondSeq to be
equivalent.