- From: C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>
- Date: Mon, 21 Jun 2010 21:38:55 -0600
- To: public-xml-schema-testsuite@w3.org
- Cc: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>, Mary Holstege <holstege@mathling.com>
The 'proposal Q' sketched in my earlier reply to Michael Kay's proposal P has now been turned into slightly more formal terms in the relevant parts of http://www.w3.org/XML/2008/xsdl-exx/ancillary/xsts-schema.sketch.xml In particular see the description of the version-info type http://www.w3.org/XML/2008/xsdl-exx/ancillary/xsts-schema.sketch.xml#version-info Some more examples would probably be useful, but I have attempted to make the documentation attached to each element and type declaration as explicit as I could about how things are expected to work. This version of the schema document defines four sets of mutually exclusive version tokens: 1.0 and 1.1 for XSD versions 1.0-1e and 1.0-2e for XSD 1.0 editions CTR-all-compile, CTR-all-runtime, CTR-all-idep for behaviors regarding schema errors in complex type restrictions involving all-groups XML-1.0 and XML-1.1 for the two sets of XML-based datatypes The values in each set are mutually exclusive in the sense that it is logically contradictory for more than one value in a set to appear in a single expected/@version value. On testGroup, testSet, etc., the semantics are different and it's perfectly legal for a test set to have multiple values from the same set, e.g. version="1.0 1.1" to indicate that the test set is applicable to any processor which supports either 1.0 or 1.1. The opposition between the disjunctive meaning of the version attributes on testSet etc. (test set should be executed if ANY of these are supported), and the conjunctive meaning on expected/@version (result is prescribed when ALL of these are active) may prove unnecessarily confusing; it seems likely that it may be useful in complex cases, but at the moment I don't have any examples. I can neither prove that it's necessary, nor that it's unnecessary and can safely be removed. Since the XSLT test suite has a lot more optional features and probably cases where they interact in more complex ways, I'd be particularly glad of input from those who have used it a lot. Michael? Mary? -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************
Received on Tuesday, 22 June 2010 03:39:26 UTC