- From: Henry S. Thompson <ht@inf.ed.ac.uk>
- Date: Wed, 16 Jun 2010 17:17:05 +0100
- To: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>
- Cc: public-xml-schema-testsuite@w3.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 C. M. Sperberg-McQueen writes: > The test suite schema seems to have several attributes for dealing > with different versions of the schema language: > > - the schemaVersion attribute on ts:testSuite > - the version and edition attributes on schemaTest and instanceTest > - the version and edition attributes on expected > > Q1 What do they mean, and what is the relation among them? > > The documentation in the test suite schema describes the > version attribute on schemaTest and instanceTest as indicating > that a particular test "applies to" particular versions > only. I think I see what it means for an instance test to > be applicable only to a particular version of XSD -- if the > relevant schema is not legal in 1.0, the instance test is > meaningless for a 1.0 processor. But what does it mean for > a schema test to be applicable only to certain versions of > the language? It means that the expected result is only correct per that/those stated version/edition(s). For example, <testGroup name="particlesZ026"> <schemaTest version="1.0" implDe="true" name="particlesZ026"> <schemaDocument xlink:href="../msData/particles/particlesZ026a.xsd"/> <schemaDocument xlink:href="../msData/particles/particlesZ026b.xsd"/> <expected validity="valid"/> . . . <testGroup name="particlesZ026a"> <schemaTest version="1.1" name="particlesZ026"> <schemaDocument xlink:href="../msData/particles/particlesZ026a.xsd"/> <schemaDocument xlink:href="../msData/particles/particlesZ026b.xsd"/> <expected validity="invalid"/> means that the WG decided that per 1.0, the author's stated 'validity="valid"' was implementation-dependent (because of a lack of clarity in the spec.), but that per 1.1 the expectation of 'validity="invalid"' was unequivocal. I think this example (or see the resolution of bug 4078, testGroups addB156 and addB156a in msMeta/Additional_w3c.xml for a parallel instanceTest example) illustrates my answer to your larger "Why did you do it this way" question -- since the resolution of many bugs seemed to be going to be "label this one 1.0, and make a copy and label it 1.1, with changes as follows", that putting the version and edition attr. on the {schema,instance}Test element would support that straightforwardly. It was also then straightforward to update my test harness to run only e.g. 1.0 non-implDe tests, or to find all implDe 1.1 tests. Hope this helps, ht - -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFMGPkBkjnJixAXWBoRAjxEAJ4iNWY5EBIBQIbRnLbp/9BI+/NqbQCfVWhC gLQwlwkS8P62MS/ZfPqBGPI= =qoCR -----END PGP SIGNATURE-----
Received on Wednesday, 16 June 2010 16:17:36 UTC