In section 5.2.3 of the ebMS 3 specification the following constraint is formulated:

eb:Messaging/eb:SignalMessage/eb:[SignalName]
This REQUIRED element defines the nature of the ebMS signal. There is only one
eb:[SignalName] child element when [SignalName]=PullRequest or [SignalName]=Receipt. There
may be several children elements when SignalName=Error.

Our schema for the SignalMessage type is currently

<xsd:complexType name="SignalMessage">
<xsd:sequence>
<xsd:element name="MessageInfo" type="MessageInfo"/>
<xsd:element name="PullRequest" type="PullRequest" minOccurs="0" />
<xsd:element name="Receipt" type="Receipt" minOccurs="0"/>
<xsd:element name="Error" type="Error" minOccurs="0" maxOccurs="unbounded"/>
<xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>

Development has asked whether the schema can enforce the constraint " There is only one
eb:[SignalName] child element when [SignalName]=PullRequest or [SignalName]=Receipt. " by adding a choice

<xsd:choice minOccurs="0" maxOccurs="1">
<xsd:element name="PullRequest" type="PullRequest" minOccurs="0" />
<xsd:element name="Receipt" type="Receipt" minOccurs="0"/>
</xsd:choice>

Then violations of the constraint could be reported by ebMS error code 0004, which is a failure code applying to content problems that can be used in cases of schema invalidity.