W3C home > Mailing lists > Public > www-talk@w3.org > March to April 1997

Re: FW: IE4.0 and W3C Standards

From: Chris Lilley <Chris.Lilley@sophia.inria.fr>
Date: Wed, 5 Mar 1997 19:06:35 +0100 (MET)
Message-Id: <9703051906.ZM8493@grommit.inria.fr>
To: Benjamin Franz <snowhare@netimages.com>, "'www-talk@w3.org '" <www-talk@w3.org>, www-style@w3.org
On Mar 5,  7:24am, Benjamin Franz wrote:

> Ummm...While on first read this seems to say that MS is just following the
> lead of the W3C, I think a closer read will reveal that this is just a
> (somewhat wordy) denial of the extensions being proprietary. While it is a
> good thing that MS is working for a formal public definition of these
> extensions - I do not believe that this changes the public perception that
> the W3C standards process is just a rubber stamp for what MS and NS plan
> to do *anyway*.

That may be the public perception but the reality is that W3C specifications
represent an interoperable consensus among our members. We have 160, by
the way, and you only named two. By no means are all suggestions rubber
stamped. Some experiments fail, and sometimes W3C members have to leave
these behind and move to new ways on which there is consenus.

The test of how committed any company is to an open and interoperable
Web is how readily they leave these failed experiments behind or modify
the behaviour of their software to conform more closely. So if you want
to evaluate the open-ness of any company, give them credit for moves
toward W3C specifications and bug reports for failures to move.

> And for any set of extension to be viable, they would have
> to be well defined anyway or no one could use them, so backwards
> engineering them would be comparatively trivial whether or not MS works
> with W3C to produce an 'official' standard.

A fine piece of circular logic. Many extensions are 'viable' in the sense
that they may be taken up rapidly but are often poorly documented if at
all and the definition may change from week to week. A definition which
depends on backwards engineering is fragile; plus backwards engineering
is hard if you want interoperability and are aiming towards 100% bugwards
compatibility with some proprietary feature. The first 75% is often easy ;-)

Chris Lilley, W3C                          [ http://www.w3.org/ ]
Graphics and Fonts Guy            The World Wide Web Consortium
http://www.w3.org/people/chris/              INRIA,  Projet W3C
chris@w3.org                       2004 Rt des Lucioles / BP 93
+33 (0)4 93 65 79 87       06902 Sophia Antipolis Cedex, France
Received on Wednesday, 5 March 1997 13:08:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:26 UTC