The easiest change to the XSD would be make both optional via minOccurs="0"
:
<xs:element name="scheduled_times">
<xs:complexType>
<xs:sequence>
<xs:element ref="arrival_time" minOccurs="0"/>
<xs:element ref="departure_time" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
Note, though, that this will also allow neither to be present. The either, both, but not neither, case is a bit tricky because of the Unique Particle Attribution constraint.
Wrong - violates Unique Particle Attribution
Trying the straightforward approach of listing the desired possibilities via xs:choice
:
<xs:element name="scheduled_times">
<xs:complexType>
<xs:choice>
<xs:sequence>
<xs:element ref="arrival_time"/>
</xs:sequence>
<xs:sequence>
<xs:element ref="departure_time"/>
</xs:sequence>
<xs:sequence>
<xs:element ref="arrival_time"/>
<xs:element ref="departure_time"/>
</xs:sequence>
</xs:choice>
</xs:complexType>
</xs:element>
will run afoul of the Unique Particle Attribution constraint:
cos-nonambig: arrival_time and arrival_time (or elements from their
substitution group) violate "Unique Particle Attribution". During
validation against this schema, ambiguity would be created for those
two particles.
Correct - does not violate Unique Particle Attribution
To resolve the ambiguity, re-work the choice so that the possibilities are unambiguous:
<xs:element name="scheduled_times">
<xs:complexType>
<xs:choice>
<xs:sequence>
<xs:element ref="arrival_time"/>
<xs:element ref="departure_time" minOccurs="0"/>
</xs:sequence>
<xs:element ref="departure_time"/>
</xs:choice>
</xs:complexType>
</xs:element>