Re: [xml-dev] XML Schema complex type restriction
I think assertions are always subsumptive in your terminology. Even if they appear to allow otherwise.
For example, if you have an element of type Integer and the assertion constrains the element to be either the text "54" or the number 32, the type is constrained to be the number 32. The constraint of having text "54" would never be exercised.On Thu, Sep 28, 2017 at 10:37 PM, Mukul Gandhi <[email protected]> wrote:
On 25 September 2017 at 19:50, Michael Kay <[email protected]> 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:<complexContentid = IDmixed = boolean{any attributes with non-schema namespace . . .}>Content: (annotation?, (restriction | extension))</complexContent><restrictionbase = QNameid = 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 itis subsumptive (i.e it has fewer options) of the base type's content model. But the use of <assert> here can choose to violate ornot violate this subsumptive notion. Therefore, using <assert> is a double edged sword at this place. May be the XSD 1.1 spec, couldhave 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