On 25 September 2017 at 19:50, Michael Kay <mike@s...> wrote:

Both these problems can be addressed by defining the restrictions using assertions. I think this is how I would normally do it in XSD 1.1.

Here's the syntax of complex type restrictions as specified by XSD 1.1 spec:

<complexContent

  id = ID

  mixed = boolean

  {any attributes with non-schema namespace . . .}>

  Content: (annotation?, (restriction | extension))

</complexContent>

<restriction

  base = QName

  id = ID

  {any attributes with non-schema namespace . . .}>

  Content: (annotation?, openContent?, (group | all | choice | sequence)?, ((attribute | attributeGroup)*, anyAttribute?), assert*)

</restriction>

The notion of this restriction concept, excluding the effect of <assert> is essentially same as defined in XSD 1.0. 

Although XSD 1.1 introduces new prose in this respect. In a nutshell, the complex type <restriction> defines that content model inside it

is subsumptive (i.e it has fewer options) of the base type's content model. But the use of <assert> here can choose to violate or

not violate this subsumptive notion. Therefore, using <assert> is a double edged sword at this place. May be the XSD 1.1 spec, could

have chosen to explain this behavior of <assert> in complex type restrictions. As of now, I cannot find this explanation in XSD 1.1 spec. 

--

Regards,

Mukul Gandhi