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.

This is because an assertion is essentially ANDed with the grammar or datatype or keyref etc constraints. Like a Bloom filter.

Regards

Rick

On Thu, Sep 28, 2017 at 10:37 PM, Mukul Gandhi <gandhi.mukul@gmail.com> wrote:

On 25 September 2017 at 19:50, Michael Kay <mike@saxonica.com> 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