Re: [Bug 11354] Mentions of "override" outside of the override section

On Mar 10, 2011, at 5:16 AM, bugzilla@jessica.w3.org wrote:

> http://www.w3.org/Bugs/Public/show_bug.cgi?id=11354
> 
> --- Comment #7 from Michael Kay <mike@saxonica.com> 2011-03-10 12:16:15 UTC ---
>> I think it depends on what you mean by "report an error".
> 
> Sorry if I'm using vernacular language. It's my lifelong habit, which persists
> despite several years in the Schema WG. What I mean by "reports an error" is
> that the schema processor says it can't use this so-called schema to validate
> anything.

I'm sorry if my inquiry struck you as pedantic hair-splitting.  The history
of the term 'error' in the XSD spec has made the term a loaded one,
and it happens to be one for which the spec defines a specific meaning,
over which the WG spent some little time.

Your description above means, if I have understood it, that you're using 
the word 'error' as defined in the spec, to mean the schema documents 
provided are not conformant (and not in the broader sense of writing 
some data to stderr, or exiting with a non-zero return code).  With that
clarification, it ought to be possible to answer your question:  if a processor
says that a particular set of inputs cannot be made into a conforming schema
when in fact it can, then I think the processor is telling a falsehood.  If it
reports that the input does not conform to the spec when the input does
in fact conform, then I think the processor is non-conforming on that
input.

In the case before us, the spec in its current state appears to be 
inconsistent.

On the one hand, we have an explicit normative statement in the prose 
that it is the output, not the input, of the transformation that is checked 
for conformance to the spec.  If we take that as a binding statement (which
I think is how the WG meant it when we discussed the design and adopted
the words in question), reports of non-conformance in the transformation 
input may be helpful to the user.  Since conformance in the transformation 
input is not a condition of building a schema from the transformation output, 
hoiwever, it is false to say the error in the input prevented the creation of 
a conforming schema.  A processor that makes such a statement would
then be failing to distinguish correctly between conforming inputs and
non-conforming inputs.

On the other hand, we have the fact that the transformation normatively
defined in the appendix is written as a schema-aware transformation.
If we take that as a normative part of the description of the transform, 
then (if I understand schema-aware XSLT 2.0 processing correctly, which
is not a given) any implementation of the override transformation is 
required to fail if the input does not conform to the schema for schema
documents.  On that analysis, your error message is correct and required.

If my memory is correct, the WG did not discuss whether the transformation
should be schema-aware or not; it asked you and the editors to see to it
that an XSLT version of the transformation was prepared, and in the process
you suggested that we ought to make it schema-aware, just because it
would look odd if a transformation specified in the definition of a schema
language were not schema-aware.  I agreed, and we made it so.  I 
dont' recall either of us remarking on the fact that giving schema-awareness
to the transformation might be interpreted as having normative
consequences; if we had done our work perfectly this would not have
escaped our notice, but it is my life-long habit to be fallible and I find
it a hard habit to break.

So all things considered I think that if there is an obvious quick solution to
the current contradiction, it is to make all the pre-processing transforms
be schema-oblivious, not schema-aware, and stand by the words which 
were agreed by the WG rather than those which were not reviewed.

But it's clear that some implications of the status-quo wording are just now
becoming clear to some in the WG.  So I'm not sure that any obvious quick
solution exists.  If we  have lost our consensus over override, or lost the
comforting illusion that wording adopted without dissent had consensus 
in the WG, then there is nothing else to be done but to discuss the design
issues afresh.  

Although I like discussing the design of schema languages and validators
with smart people, I confess that the prospect of rediscussing the design of
override does not fill me with pleasure.  There seems to be every risk that 
in such a discussion the house of cards we have laboriously constructed 
as our compromise on issues of schema composition story will collapse, 
and what the consequences of such a collapse would be I do not like to
think.

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

Received on Thursday, 10 March 2011 16:29:24 UTC