We have some redundant uses of xs:choice in some types of the Network Packet Object, where it has only a single child element. This has no effect on the actual use of the object, but we should still clean it up.
E.g.,
<xs:complexType name="ICMPv6EchoRequestType">
<xs:annotation>
<xs:documentation>Echo request informational ICMP v6 message; type=128.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:choice minOccurs="0">
<xs:element name="Echo_Request" type="xs:boolean" minOccurs="0">
<xs:annotation>
<xs:documentation>Every node must implement an ICMP v6 Echo responder function that receives Echo Requests (ICMP v6 code=0).</xs:documentation>
</xs:annotation>
</xs:element>
</xs:choice>
<xs:element name="Data" type="cyboxCommon:HexBinaryObjectPropertyType" minOccurs="0">
<xs:annotation>
<xs:documentation>Zero or more octets of arbitrary data.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
We have some redundant uses of
xs:choice
in some types of the Network Packet Object, where it has only a single child element. This has no effect on the actual use of the object, but we should still clean it up.E.g.,