Re: Conformance and Implementations

At 11:11 AM 10/9/01 -0600, Alex Rousskov wrote:
>[...]
>This is exactly the path I am afraid of:

Opinion.  It is an unnecessarily dark picture of how this might play out -- 
break 1 or 2 (or 3 or ...) of the steps, and the outcome can be pretty 
different.  Some specific comments are embedded.

>     0.  W3C publishes cool specs
>     1.  People start using (and abusing) them
>     2.  W3C decides it needs more control on what
>         people can say about their support of the W3C specs
>     3.  Formal conformance/compliance guidelines are introduced

Many of the specs already have well-stated conformance sections (see, e.g., 
SVG conformance specifications, http://www.w3.org/TR/SVG/conform.html).  In 
my view, their first value is to disambiguate such statements as 
"conforming XYZ viewer" -- there are objective criteria to measure the 
statement.

This says nothing about enforcement or verification -- whether it be 
demanding users, trade groups, fora like WASP, W3C, or ...

>     4.  Guidelines are ignored by the majority of developers
>         (see this thread on several reasons why)
>     5.  W3C decides guidelines are ignored because it is difficult
>         to express and test them and because many developers
>         interpret them differently
>     6.  We need EARL!
>     7.  EARL, a parser-friendly RDF-based language, is developed
>         and guidelines are converted to use it
>     8.  Guidelines are still ignored by the majority of developers;
>         necessity to master a yet another human-unfriendly and
>         domain-ignorant language is yet another reason why
>         many small developers would have to ignore the EARL-based
>         guidelines

(See my comments below about small developers.)

EARL is a tool (or maybe more rightly should be viewed as a potential 
technology behind future useful tools).  Hopefully we can figure out how to 
use such technologies as EARL, without forcing every user or beneficiary to 
have to learn arcane languages.  By analogy, I've talked with some others 
about the possibility of form-driven interfaces to lead people painlessly 
through the process of making a conditional-conformance declaration, or a 
product-feature spread sheet.  This does not require that every user learn 
scripting languages, HTML4, and forms!

>     9.  W3C realizes that it needs to apply legal pressure on
>         developers to follow the guidelines: If you want to say
>         "I am XYZ compliant", you must pass a EARL/TPDL test suite!
>     10. Big companies start arguing that their competitors are
>         abusing test suites. They also realize the opportunity
>         to narrow down the competition using legal barriers.
>     11. W3C designates an independent 3rd party to administer the
>         tests. Now the testing is fair and impartial.
>     12. An independent 3rd party charges $$$ to verify conformance,
>         blocking the way for small developers to make any legal
>         conformance claims

Anecdote.  For many years, I ran a small (5-person) technology company.  A 
trade associate (ATA) said they wanted their suppliers certified (a 
certification service was available from a 3rd party).  We were the first 
company to get certified, thinking of it as a competitive advantage.  I 
actually think that peoples' willingness to get certified was in inverse 
proportion to the company size.

>     13. W3C becomes a trademark of a few big players and, slowly,
>         fewer and fewer folks, including those big players, care
>         about W3C and what it used to stand for.

Once we got off the fence and got certified, a number of others 
followed.  As I said, the larger companies were the most resistant.  But my 
point is:  conformance and certification programs don't necessarily 
segregate the world into big-company winners and small-company losers.


>Humans are born with desire to act when something is wrong.
>Unfortunately, ability to predict the consequences of our actions is
>rare. We have to be careful not to make the situation worse when we
>try to fix things.

Yes.

>Especially, when things that seem to be
>more-or-less working already.

Some might dispute the characterization "things seem to be more or less 
working already".  The earlier "bugwards compatibility" thread is one 
example, and the WASP pointer (http://webstandards.org/) is another, 
indicating that there are those who think something more is needed.

So ... I'm sure that we could make a mess of things if we implemented a 
13-step program with bad choices all the way down the path.

What would you suggest that we do to avoid this?  What *should* a W3C QA 
activity focus on?

-Lofton.

Received on Tuesday, 9 October 2001 16:31:02 UTC