XML Validation against XSD : cvc-complex-type.2.4.a

Question

Currently I am using javax.xml.validation.Validator to validate xml against given xsd. I have set custom error handler to get all exceptions instead of exiting at the first exception.

Sample xsd:
        <xs:element type="xs:string" name="att1"/>
        <xs:element type="xs:string" name="att2"/>
        <xs:element type="xs:string" name="att3"/>
        <xs:element type="xs:string" name="att4"/>

In xml if att2 and att3 values are not there, I am getting below exception.
cvc-complex-type.2.4.a: Invalid content was found starting with element 'att4'. One of '{"https://******":att2}' is expected.

But I need exception to be like this i.e. both att2 and att3 should be shown in expected list.
cvc-complex-type.2.4.a: Invalid content was found starting with element 'att4'. One of '{"https://******":att2, "https://******":att3}' is expected.

How can I achieve this?

Answer 1

As a second element, the xsd specifies att2 , put you provided att4 .
As a third element, the xsd specifies att3 but you didn't provide any element.
You can try to set the elements att2 and/or att3 as optional with :

minOccurs="0" maxOccurs="1"

If it doesn't work, you can try :

<xs:element type="xs:string" name="att1"/>
<xs:choice minOccurs="0" maxOccurs="2">
        <xs:sequence>
            <xs:element maxOccurs="1" name="att2" type="xs:string" />
            <xs:element maxOccurs="1" name="att3" type="xs:string" />
        </xs:sequence>
</xs:choice>
 <xs:element type="xs:string" name="att4"/>

Answer 2

The validator is implemented as a finite state machine. It computes the permitted transitions from one state to another. After reading an att1 element, the only permitted transition is to an att2 , and that's what it's telling you. It's not smart enough to explore the entire finite state machine and work out that at att4 would be valid if there was an att2 and then an att3 .

The Saxon validator does a little better than this, but only a little: it won't give you what you're looking for here.

If it's any consolation, XSD validators generally do a lot better than regex engines (which is essentially what they are); regex engines generally just tell you that the input isn't matched by the regex, and give you no clue why.