[Bug 3220] Terminology: "must"

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3220


cmsmcq@w3.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |needsDrafting




------- Comment #1 from cmsmcq@w3.org  2007-10-14 20:05 -------
The WG discussed this issue ('must' and 'error') at the ftf of October
2007 in Redmond.

After some flailing around and mutual incomprehension, we converged on
the following propositions:

  - For processors, failure to obey a 'must' means the processor is
    non-conformant. (Not 'in error')

  - For data (schemas + schema documents), failure to obey a 'must'
    means error; this in turn is the same as meaning non-conformance.

  - The word 'error' denotes only things that can happen in data,
    never something that happens in processors.

Note that specs vary in their policy on what conforming processors
must do when presented with non-conforming data.  Some say, in effect,
"all bets are off" and impose no constraints on conforming processors
in this situation.  In a Venn diagram showing sets for conforming
processors, conforming data (schemas and schema documents), and valid
data (i.e. valid against the schema), these spec define required
behavior only for areas +++ and ++-.  Other specs require that
processors report or reject non-conforming data, thus also imposing
constraints on areas +-+ and +--.  

In some ways, XSDL 1.0 and 1.1 currently take the first view; in
others, they take the second.  

We achieved consensus on instructing the editors to rewrite to follow
the usages just described, and to specify that conforming processors
MUST detect and report errors in schemas and schema documents; they
MAY reject non-conforming data; they MAY recover.

On a side issue: it's clear that a schema document is in error only if
non-conformant.  Is it non-conformant only if it is in error?
Probable consensus around the answer "yes" (the two terms are
extensionally equivalent, and maybe intensionally equivalent).

Received on Sunday, 14 October 2007 20:05:24 UTC