More realistically, imagine you have a complex type whose content model is <element name="para" minOccurs="0" maxOccurs="unbounded"/>, and the assertion says test="exists(para)", then the assertion on its own would allow

<para/>

<fig/>

<fig/>

which the complex type's grammar does not allow.

Requiring the assertion to be true ONLY for content that satisfies the grammar would be a ridiculous burden on schema authors.

Michael Kay

Saxonica

On 29 Sep 2017, at 07:39, Rick Jelliffe <rjelliffe@a...> wrote:

Oops, my example made no sense. Here is a better stab:

For example, if you have an element of XSD type Integer and the assertion constrains the element to be either the text "MentalSpasm" or the number 32 (XSD assertion tests are on the typed document), the type is constrained to be the number 32.  The constraint of having text "MentalSpasm" would never be exercised.

Rick

On Fri, Sep 29, 2017 at 3:48 PM, Mukul Gandhi <gandhi.mukul@g...> wrote:

On 28 September 2017 at 21:07, Rick Jelliffe <rjelliffe@a...> wrote:

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.

Thanks for your perspective. Its nice to think like this.

 

--

Regards,

Mukul Gandhi