RE: levels/options considered harmful

I agree with Dan's original statement, that flavors hurt interoperability 
-- they almost always lead to the fragmentation of implementations into 
different "cliques" corresponding to different flavors, and typically the 
cliques don't interoperate well.  (The "Best viewed with ..." effect).

However, in some cases, for example UAAG [2], it is hard to see how to say 
anything at all about conformance of User Agents without introducing 
conditionality, applicability, etc.  The alternative is something like, 
"all browsers must support all media types, all functionalities, all 
user-interface types... (visual, voice, braille, etc)"

For a core standard like XML, I fully agree that flavors should be 
absolutely minimized.  As I look at Guideline 3 [3], I realize that the 
scope of "flavors" is not very clear.  I tried to trace its history in the 
minutes [1], going back 2-3 meetings and couldn't find clarification.

So we (QAWG) have an issue to resolve, and that is to clarify and enumerate 
the scope and variations that we mean by "flavors" (i.e., the flavors of 
flavors).  It should be easier then to argue about the degree of evil of 
various cases.  My own bias is to also (at least) strongly discourage use 
of flavors, and possibly to add lower-priority checkpoints restricting 
flavors (in which case, to achieve a higher level of conformance, e.g., AA, 
you have to satisfy the lower-priority checkpoint.)

A couple of specific comments...

At 10:53 AM 5/22/02 -0700, Kirill Gavrylyuk wrote:
>In some cases they are evil for interop, in some cases they actually
>help interop.

For the latter, the phrase "necessary evil" comes to mind.  The 
fragmentation of implementations is almost unavoidable, and this in itself 
creates interoperability problems.  That may be unavoidable, as in the case 
of UAAG, but I think in too many cases it is avoidable.

>Optional features are only one particular case of conformance flavors.
>Conformance flavors also include:
>- Alternative sets of choices (XSLT is an example)
>- Adjuncts that are not part of the core functionality (binding to lower
>layer protocols)
>
>In any case, they are a requirement for most of the specs, so we have to
>deal with them in the guidelines.

I disagree with "requirement for most".  They may be unavoidable for some 
(after considering a careful tradeoff of conflicting requirements), but in 
many cases they result from failing to make hard choices (optionality often 
results that way).


>XML is a special case, since it is the base spec for a wide range of
>industry standards.

IMO, strict conformance could be a feature of a much wider set of the 
"middle" standards than is currently the case.


>We could add a note:
>"Having multiple flavors of conformance may impact interoperability."

I think we should try for something stronger -- a mild advisory note is not 
likely to have much impact.

Regards,
-Lofton.

[1] http://lists.w3.org/Archives/Public/www-qa-wg/2002May/0013.html
[2] http://www.w3.org/TR/UAAG10/conformance.html#conformance
[3] http://www.w3.org/TR/2002/WD-qaframe-spec-20020515/#b2ab3d133




>-----Original Message-----
>From: Dan Connolly [mailto:connolly@w3.org]
>Sent: Thursday, May 16, 2002 7:18 PM
>To: www-qa@w3.org
>Cc: Dan Connolly; Jim Hendler
>Subject: levels/options considered harmful
>
>regarding:
>
>"Guideline 3. Specify flavors of conformance.  "
>         -- http://www.w3.org/TR/2002/WD-qaframe-spec-20020515/
>
>That guideline is presented as if different
>flavors of conformance have no downside whatsoever.
>
>I don't think that's the case.
>
>"flavors of conformance" are evil. They're
>the antithesis of interoperability.
>
>Note design goal 5 of XML:
>
>"The number of optional features in XML is to be kept to the absolute
>minimum, ideally zero."
>
>  -- http://www.w3.org/TR/REC-xml#sec-origin-goals
>
>I suggest that should be a design goal of
>all W3C specs. Please update qaframe accordingly.
>
>--
>Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Thursday, 23 May 2002 13:44:58 UTC