[Bug 4811] Clarify section 6.1 regarding Schematron phases


------- Comment #9 from kumarp@microsoft.com  2007-11-10 07:05 -------
adding Sandy's comments for easy reference:

From: public-sml-request@w3.org [mailto:public-sml-request@w3.org] On Behalf Of
Sandy Gao
Sent: Monday, November 05, 2007 8:25 AM
To: Smith, Virginia (HP Software)
Cc: public-sml@w3.org
Subject: [w3c sml] About Conforming Processor (was [Bug 4675] ...)


About "conformance", here's my theory. There are actually 3 levels we could be
talking about conformance. 

1. A particular invocation 

This is the easiest to understand. If this invocation procures expected result,
it's conformant; otherwise it's not. 

2. A particular configuration 

To know things statically, "invocation" level isn't always useful. If
invocations under a certain configuration (parameters, environment, etc.)
always produce expected results, then this configuration is conformant. 

3. A particular piece of software 

Software may want to provide multiple modes/configurations. Some of them may be
conformant; and some not. We often say the software is conformant if a subset
of its configurations are conformant. 

When a spec talks about conformance, it's about behavior, so it's really about
a particular invocation, which can be reasonably extended to configurations.
But it's not about software. 

Using the above definition, 

> Can a conforming process that
> supports all specification requirements/features all of a sudden not be
> a conforming process (momentarily) because it is behaving in a manner
> not covered in the spec when **specifically requested to do so**? 

That momentarily non-conformance is about a particular
invocation/configuration. This does not make the validator non-conformant, as
long as it can run in a mode that has conformant invocations. 

> This
> ties in with Sandy's comments in the last meeting regarding schematron
> phases. SML specifies that an IF document is 'valid' if valid in the
> #ALL phase and that conforming producers must support Schematron (which
> means phases). I don't see how a conforming validator can be classified
> as non-conforming just because it also allows some non-SML features to
> be invoked by a user (such as a non-ALL phase validation). 

In the above case, I don't think the validator should be classified as
non-conforming. Just like if my SML validator has a mode for "don't check sml
key/keyref constraints", it should still be conforming, as long as it has a
mode that does check that. 

On the other hand, I do believe the spec should be consistent in terms of
conformance. Allowing conforming invocations/configurations to accept
non-conforming models makes me uncomfortable. Also it's not the spec's
responsibility to explicitly allow all different useful non-conforming ways
people may want to invoke the validator. 

But I can live with the change if other people agree (see my other mail), in
the spirit of "let's make things go faster". :-) 

Sandy Gao

Received on Saturday, 10 November 2007 07:05:30 UTC