Re: union of complex types

On Fri, Jul 16, 2021 at 2:11 PM Michael Kay <mike@saxonica.com> wrote:

> Provide some rationale / justification / use cases.


I wanted to have xs:choice, worked like following,

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

    <xs:element name="X">
       <xs:complexType>
          <xs:choice>
              <xs:element name="a" type="Type1"/>
              <xs:element name="a" type="Type2"/>
          </xs:choice>
       </xs:complexType>
    </xs:element>

    <xs:complexType name="Type1">
       <xs:sequence>
          <xs:element name="b" type="xs:string"/>
       </xs:sequence>
    </xs:complexType>

    <xs:complexType name="Type2">
       <xs:sequence>
          <xs:element name="q" type="xs:string"/>
       </xs:sequence>
    </xs:complexType>

</xs:schema>

As per the above mentioned XSD document, I want an element "X" to contain
element "a", and "a" can contain either "b" or "q". But the above XSD
document is not acceptable, since there's a UPA violation.

My new proposal is following, that must/should not suffer from UPA
constraint,

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

    <xs:element name="X">
       <xs:complexType>
          <xs:union memberTypes="Type1 Type2" />
       </xs:complexType>
    </xs:element>

    <xs:complexType name="Type1">
       <xs:sequence>
          <xs:element name="a">
             <xs:complexType>
                <xs:sequence>
                  <xs:element name="b" type="xs:string"/>
                </xs:sequence>
             </xs:complexType>
          </xs:element>
       </xs:sequence>
    </xs:complexType>

    <xs:complexType name="Type2">
      <xs:sequence>
        <xs:element name="a">
           <xs:complexType>
              <xs:sequence>
                <xs:element name="q" type="xs:string"/>
              </xs:sequence>
           </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>

</xs:schema>

With xs:assert (meaning, with only the existing XSD facilities), we can
solve this problem to some extent (its not scalable, when XML structure
within element "a" is much complex).


> Of course you will be aware that there is no active work on XSD - and I
> would think that further developments are highly unlikely.
>

I agree. And, that's a different aspect to think about.



-- 
Regards,
Mukul Gandhi