Re: New resource: Normative References to W3C Standards

On Fri, Apr 19, 2013 at 8:48 AM, Daniel Glazman
<daniel.glazman@disruptive-innovations.com> wrote:
> With respect to the above, we're unable to cope with the always changing
> state of the WHATWG html specification.

Web standards change over time. HTML has, DOM has, CSS has, JavaScript
has, HTTP has, encodings have, URLs have. Whether they were W3C REC,
IETF STD, or even an ISO standard did not affect this one bit.

A living standard embraces the concept of change over time. That does
not mean that everything can change over night. It still needs to be
discussed, ratified, etc. It does mean that as an implementer you are
actually looking at what you need to support. Rather than something
you need to merge errata into or possibly something that has changed
altogether.


> The fact it is a so-called
> "living standard" generates _extreme_ pressure on us. Let me give you
> a concrete example: the hgroup element was recently removed from the
> W3C html5 spec; it is still present in the WHATWG spec... So not only
> we have to possibly remove it from our implementation but we also have
> to make a choice about the html spec we want to follow. Adding an
> element and removing it afterwards while it was already considered
> a "standard" from WHATWG's point of view is suboptimal, to say the
> least. It is a clear indicator of a wrong process.

It seems your problem is not created by the living standard, but by
the snapshot?


> The "living standard" is, seen from here, a way of making standards that
> can be followed only by _major_ players having large teams able to cope
> with the crazy speed it imposes on implementors. We're not playing in
> that field, unfortunately, but it does not mean we're not implementors.
> It only means our industrial constraints are totally ignored, on
> purpose, by the WHATWG.

I don't think e.g. http://url.spec.whatwg.org/ is developed much
faster than any other standards document. It's maintained better, but
you still have to go through the same cycles.


> The fact the WHATWG spec is a "living standard" also makes it totally
> impossible for a third-party to validate a webapp against a given state
> of the art. Between one day and the next one, the spec can change so
> drastically with respect to a given feature some of my customers both
> in Europe and the US are complaining about it: they're writing critical
> applications, for instance for the automotive or bank industries. I
> heard from famous names in the recent past such companies are
> "dinosaurs of the past". Most probably, yes. But last time I checked,
> such dinosaurs were still allowing us to drive, use electricity,
> eat or fly. These companies represent millions of employees, and
> billions of customers.

A feature does not change overnight. The change might be checked in
overnight, but there is discussion and buildup leading up to that. And
in the case of the WHATWG HTML specification such a feature would
likely have already been flagged as unstable. This is no different
from when the CSS WG, five years after it released Media Queries as
Candidate Recommendation, clarified and changed parsing aspects
drastically.


> EVERY TIME I meet such companies, they reaffirm the fact the WHATWG html
> spec in not a Standard for them because they cannot freeze a given
> version of it, because the browser vendors follow it too closely. They
> desperately need the W3C version and they also report they need that one
> to reference only Standards of the same magnitude: frozen, *testable*,
> stable in time for at least 12 to 24 months. A very, very famous name
> in the computer industry recently told me two months ago « this Living
> Standard thing is out of control, we now see it as a deep mistake ».

You can take a snapshot, but it will not be stable. Whenever I hear
the concerns from Boeing et al raised it sounds to me more like they
just want to freeze a single browser engine for a while and code their
software to that. The problem for them is that the web is still
evolving, more rapidly now than before. I think we can safely assume
that the web rapidly evolving is not going to stop. So the problem
Boeing et al need to solve is how to deal build their software stack
on that unstable equilibrium. Which is not very different from what
web developers are already dealing with, but they did not come from a
slow-cycle OS upgrade path so do not even have the idea of change
being able to be slow.


> Browsers and the WHATWG html specification are the only things around us
> able to drastically change *every six weeks*. Even the mobile
> industry has a greater latency. There is not a single other industry
> working that way, and it is not going to change any time soon, in my
> humble opinion.

Yes, you need to deal with the web evolving. No standards process is
going to stop that.


> Larry was perfectly right. The fact you disagree only indicates you're
> trapped in the browser vendors' microcosm - someone could call it
> the browser vendors' reality distortion field. I suggest you reach out
> to the "real" industry out there, companies producing tangible goods
> outside of the computer/mobile domain, and relying on the Web for
> hyper-critical apps, or a public administration. You'll hear a very
> different message. (FWIW, yes, I know what I am talking about, I
> was many years the AC-Rep for Électricité de France, the largest
> electricity and nuclear power provider in the world, with such
> hyper-critical web-standards-based apps).
>
> With the background I highlighted at the beginning of this message, let
> me summarize:
>
>  - the majority of industries out there need a html spec that can
>    freeze and that's what they _all_ call a Standard; a fast update
>    process may also be needed, that's a different issue.
>  - they need these documents to normatively reference only
>    similarly frozen, stable, testable documents.
>  - referencing Working Drafts, Editor's Draft or "Living Standards" is a
>    deep matter of concern to them.
>  - the WHATWG html spec fails to address the three items just above.

They cannot have that. The W3C could continue to provide such fiction
in forms of RECs, but reality is that most of those RECs have glaring
holes and are not to be looked at.


--
http://annevankesteren.nl/

Received on Friday, 19 April 2013 11:23:53 UTC