Re: definition of strict conformance

Since we're the ones defining it, we can say whatever we like.  Here is 
what I have just put into the (new) "Definitions" section of current SpecGL 
editors draft:

"conformance of an implementation that employs only the requirements and/or 
functionality defined in the specification and no more (i.e., no extensions 
to the specification are implemented)."

This comes from, [1], whence it migrated into [2] and the current SpecGL 
draft.  (Note that "i.e." became "e.g.", which I think is a mistake, and 
which I have fixed in SpecGL draft.)

Further comments...

At 11:04 AM 8/1/02 -0400, David Marston/Cambridge/IBM wrote:

>"Where all products of a class must be exactly alike, it should be clear
>that a "strict conformance" policy is in effect for that product class.
>Strict conformance is defined as conformance of an implementation that
>employs only the requirements of the specification and no more (e.g., no
>extensions)."

Changing "e.g." to "i.e." disambiguates it.  And I think that "exactly" 
ought to be replaces with "substantially".  Perhaps a third sentence to the 
effect of:  "Strict conformance does allow some variation, such as..."

Then we would mention the things below that we agree on...


>My answers to Lofton's questions:
>
> >Are discretionary choices allowed?
>Yes. I know, it mocks the word "strict", but I don't think a prohibition
>is feasible when added to all the other prohibitions attending "strict".

I don't mind this.  Every implementation must do one of the behaviors from 
an enumerated set of two or more well-defined alternatives.  It seems 
well-defined and constrained.


> >Are optional features allowed?
>No, but you can have strict conformance on a per-module basis. This is
>one of those fine points that I think should be saved for after the next
>WD is published.

So for example, in SVG Tiny, an implementation can choose whether to 
support embedded ECMAscript (within <script> tags), or not.  And this 
disqualifies Tiny as a "strict conformance" definition?  That seems fine to me.

(I agree to postpone the fine points.)


> >Can there be "implementation dependent" features or behaviors?
>If they fall under the guidelines for discretionary behaviors, which
>would be broader than discretionary *choices*, then yes.

This one I have more trouble with.  Perhaps because I consider 
"implementation dependent" to be the Ultimate Evil for interoperability. 
(Or, right up there with "extensions" in the Set of Ultimate Evils).  In 
fact, in some aspects, I think the line between extensions and 
implementation dependent can be fuzzy.

What do other people think?

-Lofton.

[1] 
http://www.oasis-open.org/committees/ioc/documents/conformance_requirements-v1.pdf
[2] http://www.w3.org/QA/WG/2002/framework-20020507/qaframe-spec

Received on Thursday, 1 August 2002 14:18:27 UTC