W3C home > Mailing lists > Public > www-tag@w3.org > April 2013

Re: New resource: Normative References to W3C Standards

From: Marcos Caceres <w3c@marcosc.com>
Date: Fri, 19 Apr 2013 10:17:26 +0100
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Cc: www-tag@w3.org, Larry Masinter <masinter@adobe.com>, "Henry S. Thompson" <ht@inf.ed.ac.uk>, "Ian B. Jacobs" <ij@w3.org>, Noah Mendelsohn <nrm@arcanedomain.com>, Philippe Le Hegaret <plh@w3.org>
Message-ID: <11B8AF2BC6EC41BB9076BF4189122D1A@marcosc.com>

On Friday, April 19, 2013 at 8:48 AM, Daniel Glazman wrote:

> Marcos Caceres wrote:
> > > The "standard" serves as a stable reference point for multiple parties to agree across the world, but it requires the implementors
> > > and independent asynchronous review of the SAME spec.
> >  
> >  
> >  
> > No it doesn't. The WHATWG's HTML specification trivially proves that.
> Trivially, eh?
> I read the thread containing the message above with great interest for
> multiple reasons. The one hat I'm wearing right now is an implementor's
> one, for our own products and the ones we write for customers. Let me
> summarize what Disruptive Innovations is:
> - an html5 editing tool vendor
> - an EPUB3 editing tool vendor, EPUB3 being based on xhtml5
> - a very small company, with very limited resources
> - a company relying on some other company's rendering engine (Gecko)
> - a contractor for large corporations and academia all around the world
> With respect to the above, we're unable to cope with the always changing
> state of the WHATWG html specification. 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.

You need to take that up with the HTMLWG, it seems. As they are the ones that chose to remove it.  
Besides, you are still bound to Gecko so in the end you will likely just need to do whatever the engine you are bound to decides to do (or maintain your own fork, which is expensive as you say below).  Additionally, if other EPUB content/engines is already using hgroup, then you are probably stuck supporting it to support legacy content. You would have had this problem regardless of what you do or what the standards bodies decide to do because you can't control where content comes from (and if they use hgroup or not based on an old WHATWG or W3C HTML draft).  
> 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.  

Yes, it's expensive to do a Web Browser. Providing access to the worlds knowledge doesn't come cheap or easy. Neither the W3C or WHATWG should apologize for that.   
> 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.

That's like complaining that you can't make chocolate at home because it requires an industrial process. Or that you can't buy crude oil and convert it to gasoline at home because it requires a refinery. Some things require industrial scale undertakings; browser technologies are such a thing.    
> 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.

I don't know what that means. Can't you just open up a bunch of browsers and test your app in those?  Like you said, they are updated regularly and follow the WHATWG spec closely.  
> 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.

Can you give an example of where this has happened and how it was "drastic" and for whom? Also, note that the W3C HTML spec would be subject to exactly the same "drastic" changes, they would just happen over a three month period (if they are still doing heart beat releases - or over a longer period with CR). There is no escape.   
> 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.

What feature in particular are you talking about?   
> 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.

So the problem for them is that browsers are fixing bugs and adding new capabilities to enhance the platform too quickly? So users, developers, and other industries should wait around because those dinosaur companies are not agile enough to keep up?… yeah, that makes sense and it's a great argument 0_o.  

Also, I think most browsers have more "customers" than any single power company (probably by orders of magnitude), so browsers have a bigger responsibility to their users to keep them safe and provide them with the best Web possible.  

So, if that's really the dinosaurs' thinking, sounds to me like they have bigger problems. The W3C has good beginner  courses they can take in Web development to teach them how to write Web apps properly (i.e., not bound to particular browser versions or proprietary technologies like ActiveX, Java, and IE6 specific features).   
> 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.

Wow, that sounds like a great way to keep the platform competitive! If those companies that allow us to "drive, use electricity, eat, or fly" want more stable specs, they are welcome to join the W3C and provide resources (or just more money) to throw at the problem. Could certainly use more help with writing tests. Otherwise, they are free to contribute to the open source browser engines and fix bugs there to achieve interoperability.      
> 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 ».

Well, I just talked to twenty even more famous dudes than your dude, and they were all like "hell yeah, Living Standards are awesome! that dude that Daniel talked to is a quack!".  

Argument from authority is pointless - specially when you don't disclose who you are talking about. My imaginary famous dudes trump your imaginary famous dude any day of the week.
> Browsers and the WHATWG html specification are the only things around us
> able to drastically change *every six weeks*.

Actually, the spec is updated almost daily. It's browsers that roll out new versions every six weeks (with bug fixes, security fixes, and other things that keep the Web moving forward and users safe). You want to slow that down?  
> 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.

Funny, I thought most web sites roll out new versions all the time. You just don't notice it because the Web is unversioned.  
> 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.

Calling me delusional is only going to polarize our positions. Please refrain from doing that.   
> 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.

The fact that they are already relying on the Web for "hyper-critical apps" (whatever that is) is already proof that it's working - and that governments are using it, is also a good indicator. Sounds to me that we have an education problem, not so much a platform problem. For example, many public admin sectors are using Java and they are confused that it's somehow "the Web".  
> 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).

Again, you are arguing from authority which is unhelpful. Please provide some concrete examples.  
> 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 already have a fast update process. And sections in the WHATWG are already marked with stability and interoperability indicators.  
> - they need these documents to normatively reference only
> similarly frozen, stable, testable documents.

Stability is orthogonal to referencing "dated" documents. It won't help.  
> - referencing Working Drafts, Editor's Draft or "Living Standards" is a
> deep matter of concern to them.

Yes, when they have people talking to them that don't understand Living Standards and spreading FUD, of course they are going to be confused and deeply concerned. Please stop talking to them about Living Standards.  
> - the WHATWG html spec fails to address the three items just above.

Somehow, I don't think so.  
Received on Friday, 19 April 2013 09:18:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:55 UTC