XSD 1.1: wild-cards in xs:all compositor, and assertions

I was reading through the latest XSD 1.1 language draft, and one of the things that has changed between XSD 1.0 and 1.1, are some of the details of, xs:all compositor instruction.

XSD 1.1 defines <xs:all ..> compositor as follows:

  <all
    id = ID
    maxOccurs = 1 : 1
    minOccurs = (0 | 1) : 1
    {any attributes with non-schema namespace . . .}>
    Content: (annotation?, (element | any)*)
  </all>

Whereas, XSD 1.0 defined xs:all instruction as following:

  <all
    id = ID
    maxOccurs = 1 : 1
    minOccurs = (0 | 1) : 1
    {any attributes with non-schema namespace . . .}>
    Content: (annotation?, element*)
  </all>

XSD 1.1 allows xs:any wild-card to be part of xs:all (whereas, XSD 1.0 didn't allow this), which makes xs:all instruction to be more useful (because, with xs:any we could make the Schema type more open). We could also have certain Schema constraints present as assertions (as illustrated in the example below), restricting the degree of Schema openness (achieved by xs:any wild-card) to an extent we would want.

Here's an example I came up with, illustrating the use of xs:any wild-card within xs:all compositor, and having some assertions, for imposing some constraints on the ordering of elements (which means, that we are restricting the degree of openness achieved by xs:any using assertions) in the instance document:

XML document [1]:

  <Person>
    <fname>Mukul</fname>
    <lname>Gandhi</lname>
    <sex>M</sex>
    <address>
      <street1>xyz</street1>
      <street2>street</street2>
      <street2>gurgaon</street2>
    </address>
  </Person>

XSD 1.1 Schema [2]:

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

    <xs:element name="Person">
      <xs:complexType>
        <xs:all>
          <xs:element name="fname" type="xs:string" />
          <xs:element name="lname" type="xs:string" />
          <xs:element name="sex" type="xs:string" />
          <xs:any processContents="lax" />
        </xs:all>
        <xs:assert test="(*[1]/local-name() = ('fname', 'lname')) and 
                         (*[2]/local-name() = ('fname', 'lname'))" />
      </xs:complexType>
    </xs:element>
  
  </xs:schema>

In the above Schema [2], if the assertions are not present, then xs:all compositor would mean, that it's contents can be present in any order (including the xs:any wild-card, which is newly introduced in XSD 1.1 within xs:all).

The assertion in the Schema above [2], constrains the first two child elements of, "Person" element to be "fname" or "lname".

Xerces-J's XSD 1.1 processor, seems to implement these syntax fine.

I hope that this post is useful.