Three Buckets of Thoughts

Part of Corporate

Author(s) and publish date

Skip to 2 comments

Kevin Lawer has written a great blog post Web Standards' Three Buckets of Pain explaining cultural differences between communities.

Opening up the W3C

Justin Thorp commented (emphasis is mine):

Karl, I'm really excited by your efforts with opening the W3C. The only thing is I hope its more then just "opening up." We can make our mailing lists and our documents publicly available... we can make more primers... but I'm not sure that's enough. It's about engaging the development and design community in a genuine conversation... its as you said it "being in liaison with the developers, designers and the Web pro communities." I'm here to be a servant to your efforts however i can be.

I'm pretty sure we can work out something. Seen from the inside, the door has always been opened, but people didn't know about it, or know that they could interact. The efforts of W3C staff to publicize it might not have been enough. There is also a question of scalability. More on that a bit later.

There is a perception problem on both sides. And I'm pretty sure there will be frictions and unknown issues by the mixing of communities, but that's more exciting than worrying. smile

Learning the vocabulary, the way people think or interpret is always challenging and wonderful at the same time. I emphasized the "we" because we will be able to achieve this if Web designers, Web developers, implementers, hackers are working together, which reminds me I have an action item for the HTML working group about HTML 5 for authors.

Waterfall model

Then Dan Bradley said:

First, you have to have a spec, then you implement against that spec, then you test the implementation against the spec. The W3C has created several specs, and Browser developers developed code against those specs. Sadly it's the third part that falls down. The W3C did a great job providing tools to validate HTML, CSS, and other specs for the web development community at large, but they haven't done anything to validate there specs for the browser developers that I know of.

This model of development is usually called the waterfall model. Not all W3C working groups are using this model. Some have introduced a test driven development for their specifications, some have chosen to be very practical and to carefully specify what has been already deployed.

Life of W3C specifications

It starts with implementers (from companies often) who have a product in development or an idea of a future product. These developers create a specification around their requirements for their own products, plus things they think would be cool to have. Sometimes the passionate discussions create heavy specification. It's a difficult exercise of knowing what should be inside or not. To find the right balance.

Personally, I'm much in favor of a specification which starts small and can evolve, adding a new set of features at the next version.

When the specification reaches Candidate Recommendation stage, the Working Group is officially asking for implementation experience. It doesn't mean that they don't have them already. It really depends on the working groups. It is the time where some groups start to think about test suite and how to prove what is implemented in an interoperable way. The group is producing an implementation report. It is far to be perfect and shows its own issues. I should write a separate article about it.

Personally again, I prefer when the group is working on test cases at the very beginning of the specification life. So that there is an iterative process between specification/test/implementation. But here I just show my QA hat.

To enter the next step, Proposed Recommendation, the WG has to show that each feature is implemented twice in an interoperable way. Really challenging. Features will be removed from the specification if there are no dual implementations of each feature.

Then it becomes a W3C Recommendation. Implementations are often already available on the market by this time and are in the process of being finalized. Software bugs related to ambiguities in the specification, to early implementations are part of the software life cycle. The working group will fix minor bugs in errata, and bigger issues in a next release (which takes time.)

This is another opportunity for an article about products and specifications ecosystem after publication.

Related RSS feed

Comments (2)

Comments for this post are closed.