This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In the Microsoft Particles test set, test particlesZ036 appears to be testing the ability of the processor to handle very large values of minOccurs and maxOccurs, and the published results rely on the fallback strategy used by one particular processor. See the comment in the metadata: "Schema validation engine validates as xs:any if maxOccurs greater than 4096(13)". This affects all tests in this group.
Agreed that the test may not be valid to be published in a compliance suite. We are following up with the WG to determine the process of updating the test suite.
Z036a: although an implementation could legitimately blow its limits here, the test appears to be correct in that (a) the schema is valid, and (b) the instance is invalid. Z036b: the schema is valid and both instances (b1 and b2) appear to be valid (as far as we can tell from inspection). The metadata therefore seems to be wrong to describe the instances as invalid. Z036c: it appears that the schema and the instance are correctly described in the metadata as valid. Conclusions: (a) instances b1 and b2 should be marked as valid (b) we need a mechanism to allow implementations to report that they have blown their limits on these tests.
I've updated the metadata as agreed by the TSTF and recorded in the previous comment, but I'm unclear about 1) the remarks about z036a, as the maxOccurs in the relevant schema doc't is only 100; 2) where in the spec. we allow implementations to "legitimately blow" their limits on min/maxOccurs. . . so I'm not closing the issue
I think the comment about "could legitimately blow its limits" was just noting a theoretical possibility, and can be ignored. I think I assumed that XSD 1.0 had a clause allowing conformant processors to fail to process valid schemas/instances if they ran out of resources, analogous to the rules in Part 2, for example "However, ·minimally conforming· processors ·may· set an application-defined limit on the maximum number of decimal digits they are prepared to support". It seems there are no such rules in Part 1. Perhaps there should be.
I read MK's comment of 17/01/09 as saying we don't need to look at the test or the spec again, so I've closed this one