XSD validation of XML node that could be simple or could be complex

Question

Given an XML node that can be either

<Uninstall id="Text">{GUID}</Uninstall>

or

<Uninstall id="Text">
    <File>PATH TO EXECUTABLE</File>
    <Arguments>ARGUMENTS</Arguments>
</Uninstall>

I am trying to validate this with XSD. I have this

<xs:complexType name = 'Uninstall'>
    <xs:choice>
        <xs:simpleContent>
            <xs:extension base='xs:string'>
                <xs:attributeGroup ref='Task_Attributes'/>
                <xs:attributeGroup ref='Directive_Attributes'/>
            </xs:extension>
        </xs:simpleContent>
        <xs:complexContent>
            <xs:sequence>
                <xs:element name = 'File' type='xs:string' minOccurs = '1' maxOccurs='1' />
                <xs:element name = 'Arguments' type='xs:string' minOccurs = '0' maxOccurs='1' />
            </xs:sequence>
            <xs:attributeGroup ref='Task_Attributes'/>
            <xs:attributeGroup ref='Directive_Attributes'/>
        </xs:complexContent>
    </xs:choice>
</xs:complexType>

But that errors with Exception calling "Add" with "2" argument(s): "The 'http://www.w3.org/2001/XMLSchema:simpleContent' element is not supported in this context." when I add the schema file to the [xml.xmlReaderSettings]. Note that the two attributeGroups reference the possible attributes, which are the same for both the simple and complex form. So I am pretty sure the issue I am having is with doing a choice between simple and complex. But maybe I can also simplify the XSD to only reference the attributes once, since that's common?

I know the XML is pretty ugly, and I am moving to a more consistent XML structure. But I need to validate the current inconsistent XML to automate migration to the new, more consistent XML.

Answer 1

XSD is not capable of expressing every conceivable constraint on your data, and that's especially true with XSD 1.0 - assertions in XSD 1.1 give you a lot more flexibility. But this one is awkward even in XSD 1.1.

One option that's sometimes overlooked is to define your schema against a cleaned up version of the structure, and then transform the actual instance to this structure prior to validation. For example if one form of the Uninstall element is deprecated and retained only for compatibility, you could transform the input to convert deprecated forms to their target form prior before doing XSD validation on the result.