- 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