Re: some questions about version information in the test suite

On 21 Jun 2010, at 18:39 , C. M. Sperberg-McQueen wrote:

>
> On 21 Jun 2010, at 15:16 , Michael Kay wrote:
>
> > (c) Change the value of <expected> to be a list of permitted
> > outcomes, where any of the listed outcomes is considered to pass the
> > test. For example
>
> >  <expected version="1.0">invalid notKnown</expected>
> >  <expected version="1.1">invalid</expected>
>
> > indicates that acceptable results for 1.0 are "invalid" and
> > "notKnown", whereas for 1.1 the only acceptable result is "invalid"
> > This replaces the impDe attribute.
>
> This is orthogonal to the differences between what I've been calling
> proposal P and proposal Q and I'd like to decide it separately.
>
> I support eliminating the implDe attribute but believe I would prefer
> an alternative like that given in the 'expected-outcome' type of
>
> http://www.w3.org/XML/2008/xsdl-exx/ancillary/xsts-schema.sketch.xml#type_expected-outcome
>
> namely: allow the expected outcomes 'valid', 'invalid', 'notKnown',
> 'implementation-defined', 'implementation-dependent', 'indeterminate',
> 'invalid-latent', and 'runtime-schema-error'.
>
> The reasons I'm conscious of are:
>
>  - It's helpful for the WG and for users of the spec (also
>    implementors) to distinguish implementation-defined or
>    -dependent behavior from cases where the spec is just
>    vague or unclear or contradictory.
>  - Allowing some non-empty subset of 'valid', 'invalid', and
>    'notKnown' suggests that all combinations are possible
>    and distinct.  If there can really be cases where
>    'valid' and 'notKnown' are possible but not 'invalid',
>    or 'valid' and 'invalid' but not 'nowKnown', then maybe
>    this is a better approach.  But my immediate guess is
>    that all such values are errors for 'valid invalid
>    notKnown'.


A counter-example has occurred to me.  In the case of
complex type restriction involving an all-group in the
restriction, if the restriction is faulty the processor
may implement any of three behaviors:  it may undertake
always to detect the schema error in isolation (at
schema compilation time, if I may put it that way),
always to detect it only if an instance illustrates the
fault (at run-time), or sometimes one and sometimes
the other.

Given such a schema, processors of these three types
should have expected results as follows:

   <expected version="CTR-all-compile" validity="invalid"/>
   <expected version="CTR-all-runtime" validity="valid"/>
   <expected version="CTR-all-idep" validity="valid invalid"/>

The third case is not an error for "valid invalid notKnown" --
notKnown is not really an option here.

As I type this, another thought occurs to me:  maybe this
counter-example is no good after all:  notKnown is *never*
a legitimate outcome for a schema test, so for a schema
test, 'implementation-defined', 'implementation-dependent',
and 'indeterminate' all are compatible with observed
outcomes of both 'valid' and 'invalid', but not 'notKnown'.
In schema tests, 'valid' and 'invalid' are just arbitrary
keywords meaning not valid and invalid but 'conforming'
and 'non-conforming'. Not all valid schema documents
produce conforming schemas, and if I remember our rules
about annotation and documentation elements, a schema
document including invalid HTML segments in a documentation
element can map to a perfectly conformant schema.

But if we can construct a similar example for an instance
test, where two of the three values are possible and the
third is not possible, then that would count as a reason
to allow multiple tokens in the 'validity' attribute of
'expected'.

--cmsmcq

-- 
****************************************************************
* 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 02:43:02 UTC